random master mode freeze at high traffic

It just freezes? No oops/panic? Try to enable nmi watchdog - it sometimes detect lockup and throw panic/reboot box even when sysrq and stuff doesn't work and box seems to be dead to that extend that only hw reset or power button works ...

the following crash could be related - i have got it reproducibly - on non-SMP machine, with latest trunk in the time of test - 2433

i am observing it at machine with 4 atheros cards, two in master mode, two in sta mode, two of sta-ones are connected to one in master, flooding it with help of send2self loopback patch, the last ap mode one has only one station - one of these RB532 mentioned in other tickets - associated. When first 3 cards are flooding themselves and traffic on the last one is high - many tcp connections, high but variable throughtput - this bug occure within 2-20 minutes timeframe. With 0.9.3.1 the same configuration and the same type of load box is rock solid, so i guess problem is introduced or amplified by some changes in development branch - will test pre-locking changes 2380 here too, to see if it will help. Crash dump follows. I know previous poster tried 0.9.3.1 too, and had lockups too, but it could be timing/other hw stuff.

BUG: NMI Watchdog detected LOCKUP on CPU0, eip c037de30, registers:
Modules linked in: wlan_scan_ap wlan_scan_sta snd_pcm_oss snd_mixer_oss nfsd exportfs ipv6 ohci_hcd rtc_cmos rtc_core rtc_lib amd64_agp agpgart shpchp pci_hotplug e1000 uhci_hcd ehci_hcd usbcore i2c_viapro snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_rhine k8temp ath_rate_sample ath_pci ath_hal(P) wlan_acl wlan eeprom w83781d hwmon_vid i2c_isa i2c_amd756 i2c_core ide_scsi
CPU:    0
EIP:    0060:[<c037de30>]    Tainted: P       VLI
EFLAGS: 00000086   (2.6.21.3-ng-ring3-s2s-sqsh-l7-swan-imq-esfq-smp-kvm-amd-dnd #3)
EIP is at _spin_lock_irqsave+0x40/0x50
eax: 00000082   ebx: f5150000   ecx: 00000082   edx: f514b8d0
esi: f5167380   edi: 00000000   ebp: f514a480   esp: c0473c20
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0472000 task=c043cd00 task.ti=c0472000)
Stack: f8af96d0 f5150000 f5167380 00000600 00000001 00000001 f5167380 0000000c 
       00000002 00000004 00000000 00000001 00000000 00000000 00000000 00000000 
       00000003 f4ed4bc0 00000000 f514b8d0 00000000 f5167380 00000000 00000000 
Call Trace:
 [<f8af96d0>] ath_tx_start+0x870/0x11a0 [ath_pci]
 [<f8af2ecd>] ath_hardstart+0x87d/0xaf0 [ath_pci]
 [<c0342e2a>] icmp_reply+0x21a/0x280
 [<c0118f12>] try_to_wake_up+0x252/0x2b0
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c030c602>] __qdisc_run+0x72/0x1b0
 [<c02fc791>] dev_queue_xmit+0x221/0x2a0
 [<f8b197b7>] ieee80211_hardstart+0x1c7/0x2f0 [wlan]
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c02fc700>] dev_queue_xmit+0x190/0x2a0
 [<c03205c2>] ip_output+0x172/0x290
 [<c02f70de>] pskb_expand_head+0xde/0x130
 [<c031eaa0>] ip_forward+0x1a0/0x2a0
 [<c031d236>] ip_rcv+0x236/0x4c0
 [<c02fce5e>] netif_receive_skb+0x2be/0x3c0
 [<c0130008>] cleanup_workqueue_thread+0x28/0x50
 [<f8adfede>] rhine_rx+0x2de/0x440 [via_rhine]
 [<c0136349>] enqueue_hrtimer+0xb9/0x130
 [<f8ade364>] rhine_napipoll+0x24/0xb0 [via_rhine]
 [<c02fd116>] net_rx_action+0x96/0x1e0
 [<c012481d>] __do_softirq+0xcd/0xf0
 [<c0124891>] do_softirq+0x51/0x60
 [<c012493d>] irq_exit+0x6d/0x70
 [<c010682e>] do_IRQ+0x3e/0x80
 [<c0104b9b>] common_interrupt+0x23/0x28
 [<c0116222>] native_safe_halt+0x2/0x10
 [<c010206b>] default_idle+0x3b/0x60
 [<c0102119>] cpu_idle+0x79/0x90
 [<c0478d4c>] start_kernel+0x1dc/0x250
 [<c0478640>] unknown_bootoption+0x0/0x1a0
 =======================
Code: c1 90 fe 0a 79 2e f7 c1 00 02 00 00 74 1d fb 66 66 66 90 66 66 66 90 90 f3 90 80 3a 00 7e f9 fa 66 66 66 90 66 66 66 90 90 eb d6 <f3> 90 80 3a 00 7f cf eb f7 89 c8 c3 8d 74 26 00 89 c2 fa 66 66 

Hi, so i enabled nmi watchdog, and here is the kernel panic output:

i801 intel_agp agpgart parport_pc parport psmouse serio_raw floppy gameport pcspkr rtc shpchp pci_hotplug i2c_core evdev reiserf
s raid10 raid456 xor raid1 raid0 multipath linear md_mod dm_mirror dm_mod ide_cd cdrom ide_disk hpt366 piix aic7xxx scsi_transpo
rt_spi scsi_mod 3c59x mii generic ide_core uhci_hcd usbcore thermal processor fan vga16fb vgastate
CPU:    0
EIP:    0060:[<e0e65d49>]    Tainted: P       VLI
EFLAGS: 00210202   (2.6.18-4-686 #1)
EIP is at ath_tx_start+0x74a/0x10c6 [ath_pci]
eax: 00000b94   ebx: cde3ea3c   ecx: e0ea9460   edx: df82f2c0
esi: c158d71c   edi: c745e000   ebp: c158c2c0   esp: de79db50
ds: 007b   es: 007b   ss: 0068
Process openvpn (pid: 4366, ti=de79c000 task=c1637aa0 task.ti=de79c000)
Stack: 00000000 00000000 dfb483c0 c158c000 c745e000 e0eb76b1 00000003 ffffffff 
       de79dbe2 00000000 dca8b280 c745e000 000000a1 c02c7860 df82f2c0 c158c2c0 
       df82f2c0 df400000 00000000 00000000 0000001c ff000000 00000000 cde3ea3c 
Call Trace:
 [<e0eb76b1>] ieee80211_encap+0x27c/0x1093 [wlan]
 [<e0e6b171>] ath_hardstart+0xcee/0xdea [ath_pci]
 [<c012da87>] remove_wait_queue+0xf/0x34
 [<c0125491>] __mod_timer+0x99/0xa3
 [<c0281447>] _spin_lock_bh+0x8/0x18
 [<c0124657>] do_gettimeofday+0x31/0xce
 [<c022926a>] dev_hard_start_xmit+0x19a/0x1f0
 [<c0236985>] __qdisc_run+0xdd/0x188
 [<c022aa92>] dev_queue_xmit+0x142/0x24c
 [<e0eb7122>] ieee80211_hardstart+0x2b0/0x2e6 [wlan]
 [<c022926a>] dev_hard_start_xmit+0x19a/0x1f0
 [<c022aafe>] dev_queue_xmit+0x1ae/0x24c
 [<c0247f52>] ip_output+0x1c3/0x1fd
 [<c0245a48>] ip_push_pending_frames+0x2de/0x391
 [<c025e1de>] udp_push_pending_frames+0x1e3/0x204
 [<c025ead5>] udp_sendmsg+0x404/0x4c9
 [<c0263e77>] inet_sendmsg+0x35/0x3f
 [<c021fed7>] sock_sendmsg+0xce/0xe8
 [<c012d92d>] autoremove_wake_function+0x0/0x2d
 [<e1012661>] ipt_do_table+0x1ac/0x2cb [ip_tables]
 [<e1019418>] ip_nat_fn+0x170/0x184 [iptable_nat]
 [<c0220434>] sys_sendto+0x116/0x140
 [<c0226305>] memcpy_toiovec+0x27/0x4a
 [<c0226749>] skb_copy_datagram_iovec+0x53/0x1c8
 [<c012da87>] remove_wait_queue+0xf/0x34
 [<e1086534>] tun_chr_readv+0x29b/0x2a5 [tun]
 [<c0221765>] sys_socketcall+0xeb/0x181
 [<c0102c11>] sysenter_past_esp+0x56/0x79
 =======================
Code: 7c 24 6c 00 74 16 0f b6 84 24 97 00 00 00 8b 54 24 68 6b c0 0c 0f b7 5c 10 2e eb 14 0f b6 84 24 97 00 00 00 8b 4c 24 68 6b
 c0 0c <0f> b7 5c 08 2c 8b 44 24 5c f6 40 01 04 74 2a ff 74 24 6c 0f b6 
EIP: [<e0e65d49>] ath_tx_start+0x74a/0x10c6 [ath_pci]   SS: ESP   0068: de79db50
 <0>Kernel panic - not syncing: Fatal exception in interrupt

It seems, that the freeze is really caused by madwifi. One more info: I have openvpn, which redirects the internet traffic through the WLAN to the clients and use the tun device (and therefore NAT is used).

I've seen a similar problem a few days ago too. Can you try with the latest svn revision? Someone updated the locking mechanisms that (hopefully) fixed this problem.

I've use now r2468, lets see if this helps.

Well, it just freezed 5 minutes after the boot :(.

rt_spi scsi_mod generic ide_core 3c59x mii uhci_hcd usbcore thermal processor fan vga16fb vgastate
CPU:    0
EIP:    0060:[<c0281425>]    Tainted: P       VLI
EFLAGS: 00200086   (2.6.18-4-686 #1)
EIP is at _spin_lock_irqsave+0x1d/0x27
eax: df24f704   ebx: df8712c0   ecx: df6587e8   edx: 00200046
esi: df24e2c0   edi: dfee0000   ebp: df24f6f4   esp: df755b34
ds: 007b   es: 007b   ss: 0068
Process openvpn (pid: 4347, ti=df754000 task=dfaecaa0 task.ti=df754000)
Stack: e0f07677 00000000 00000000 00000000 df6587e8 ced22000 e0edfc00 df755bc6 
       df755c60 dbada780 1cd22000 000005b9 df8712c0 df24e2c0 df24e2c0 df8712c0 
       dfee0000 00000000 00000000 0000001c 00000000 ff000000 dfef1140 de69403c 
Call Trace:
 [<e0f07677>] ath_tx_start+0x1033/0x12d4 [ath_pci]
 [<e0edfc00>] ieee80211_encap+0x238/0x1130 [wlan]
 [<e0f0e4b1>] ath_hardstart+0xaf3/0xf77 [ath_pci]
 [<c0125380>] lock_timer_base+0x15/0x2f
 [<c0125491>] __mod_timer+0x99/0xa3
 [<c0281447>] _spin_lock_bh+0x8/0x18
 [<e1008102>] ipt_limit_match+0x5f/0x65 [xt_limit]
 [<c0124657>] do_gettimeofday+0x31/0xce
 [<c022926a>] dev_hard_start_xmit+0x19a/0x1f0
 [<c0236985>] __qdisc_run+0xdd/0x188
 [<c022aa92>] dev_queue_xmit+0x142/0x24c
 [<e0edf76f>] ieee80211_hardstart+0x2d7/0x373 [wlan]
 [<c022926a>] dev_hard_start_xmit+0x19a/0x1f0
 [<c022aafe>] dev_queue_xmit+0x1ae/0x24c
 [<c0247f52>] ip_output+0x1c3/0x1fd
 [<c0245a48>] ip_push_pending_frames+0x2de/0x391
 [<c025e1de>] udp_push_pending_frames+0x1e3/0x204
 [<c025ead5>] udp_sendmsg+0x404/0x4c9
 [<c0263e77>] inet_sendmsg+0x35/0x3f
 [<c021fed7>] sock_sendmsg+0xce/0xe8
 [<c012d92d>] autoremove_wake_function+0x0/0x2d
 [<c022926a>] dev_hard_start_xmit+0x19a/0x1f0
 [<c02368d6>] __qdisc_run+0x2e/0x188
 [<c0247f60>] ip_output+0x1d1/0x1fd
 [<c0220434>] sys_sendto+0x116/0x140
 [<c0226305>] memcpy_toiovec+0x27/0x4a
 [<c0226749>] skb_copy_datagram_iovec+0x53/0x1c8
 [<c012da87>] remove_wait_queue+0xf/0x34
 [<e1095534>] tun_chr_readv+0x29b/0x2a5 [tun]
 [<c02217b5>] sys_socketcall+0xeb/0x181
 [<c0102c11>] sysenter_past_esp+0x56/0x79
 =======================
Code: ea ff b2 01 86 10 8b 04 24 e9 33 06 ea ff 9c 5a fa 90 fe 08 79 1c f7 c2 00 02 00 00 74 0b fb f3 90 80 38 00 7e f9 fa eb e8
 f3 90 <80> 38 00 7f e1 eb f7 89 d0 c3 fa 90 fe 08 79 09 f3 90 80 38 00
console shuts up ...

This comes up with the r2468 right a few minutes (less the 5) after the boot. This is very similar to the one from strasak@bubakov.net in the second comment.

But this is not the same freeze as with 0.9.3.1, right?

I don't think the the second comment's freeze is the same one you're getting reviczky.

I noticed the code in svn has been changed again. Can you try things with the very latest svn ? Can you also describe what type of traffic/how much you're sending to cause the panics? Also, any specific setting, parameters, etc you used?

I'm trying to duplicate the freeze. Thanks.

Hi dyqith!

Thank you for your answer, i hope we can find the problem. I will try the latest svn right away and post the results afterwards.

About the settings, i don't think i have something special (i've already posted my /etc/network/interfaces settings. Do you need anything else?)

I guess there are two problems here right now, i try to exlain (from my point of view):

first problem: affects madwifi 0.9.2+r1842 0.9.3 and 0.9.3.1 i can reproduce the freeze with high traffic and got the kernel panic (first that i posted) my step to reproduce the freeze are: downloading a >500MB file from ftp or with 250-500Kbps internet streams (mostly videostreams, tv-shows). The freeze is within 1 hour after the download starts. note: i do this not on the pc with the master modes madwifi, but on the pcs that are connected to the master modes madwifi. Kernel panic is of course on the master modes madwifi pc.

second problem: affects madwifi svn (latest try was r2468) got the freeze (output is the second that i posted) right after the boot, within 5 minutes. i not must do anything, it freeze also without traffic.

And only a notice, that the problems has come - i think - with the kernel upgrade to 2.6.18 (modules are compiled for that of course).

It's hard to say how much traffic goes before the panic. Sometimes it freezed also without high traffic. And when i download large files 500-1000MB i got only 8 freeze from 10 downloads. It freeze also when i try to send files, so upload is affected as well.

Ok, here we are again.

Tried r2478, same freeze as with r2468, so no difference.

I think it could be the same freeze, but there has been changes in locking since 0.9.3.1 - in 0.9.3.1 spin_lock is used, later spin_lock_irq_save is used, but both crashes happen in ath_tx_start or in spinlock directly after it, so it could be caused by same factor/bug imo after all

or maybe in this case in 0.9.3.1 in part of code which is causing this there is no lock at all, dunno now, have to read the code

Note to self: Looks like the problem is from ath_hardstart() -> ath_tx_start() -> ath_tx_txqaddbuf().

Problem only shows up in line 2613 of if_ath.c

ATH_TXQ_LOCK_IRQ(txq) is used on line 2548, but ath_tx_txqaddbuf does a lock too.

I wonder which patch changed the locking behavior here... Will try to find out more.

Can anyone confirm this?

i think you found it. In 0.9.3.1 - which is rock solid here, but crashed for the other guy - could be some other stuff, just changes exposed it so it happens on my hw too - there is unlock

ATH_TXQ_LOCK(txq);
	if (athff_can_aggregate(sc, eh, an, skb, vap->iv_fragthreshold, &ff_flush)) {

		if (an->an_tx_ffbuf[skb->priority]) { /* i.e., frame on the staging queue */
			bf = an->an_tx_ffbuf[skb->priority];

			/* get (and remove) the frame from staging queue */
			TAILQ_REMOVE(&txq->axq_stageq, bf, bf_stagelist);
			an->an_tx_ffbuf[skb->priority] = NULL;

			ATH_TXQ_UNLOCK(txq);

			/*
			 * chain skbs and add FF magic
			 *
			 * NB: the arriving skb should not be on a list (skb->list),
			 *     so "re-using" the skb next field should be OK.
			 */
			bf->bf_skb->next = skb;

but in trunk not, this is the difference which could matter in think trunk ->

	ATH_TXQ_LOCK_IRQ(txq);
	if (athff_can_aggregate(sc, eh, an, skb, vap->iv_fragthreshold, &ff_flush)) {
		if (an->an_tx_ffbuf[skb->priority]) { /* i.e., frame on the staging queue */
			bf = an->an_tx_ffbuf[skb->priority];

			/* get (and remove) the frame from staging queue */
			TAILQ_REMOVE(&txq->axq_stageq, bf, bf_stagelist);
			an->an_tx_ffbuf[skb->priority] = NULL;

			/*
			 * chain skbs and add FF magic
			 *
			 * NB: the arriving skb should not be on a list (skb->list),
			 *     so "re-using" the skb next field should be OK.
			 */
			bf->bf_skb->next = skb;
			skb->next = NULL;

but after else statemenet, there is unlock ->

ATH_HARDSTART_GET_TX_BUF_WITH_LOCK;
			if (bf == NULL) {
				ATH_TXQ_UNLOCK_IRQ_EARLY(txq);
				goto hardstart_fail;
			}
			DPRINTF(sc, ATH_DEBUG_XMIT | ATH_DEBUG_FF,
				"%s: adding to fast-frame stage Q\n", __func__);

			bf->bf_skb = skb;
			bf->bf_node = ni;
			bf->bf_queueage = txq->axq_totalqueued;
			an->an_tx_ffbuf[skb->priority] = bf;

			TAILQ_INSERT_HEAD(&txq->axq_stageq, bf, bf_stagelist);

			ATH_TXQ_UNLOCK_IRQ_EARLY(txq);

			return 0;

see ath_txq_unlock_irq_early, it should be in first code block too, if i properly remeber what is going on, am i right?

correction - remember should have been understood, haven't had my coffee yet ...

Try to fix the ATH_TXQ_LOCK problems in ath_hardstart

Can you guys test this patch with the latest svn?

I probably won't have time today to do test it, but hopefully it fixes some of your problems. Its an ugly patch, but the way the locking macros are written, this is the only way i can think of that will work.

I am testing it ATM, assembled two exactly same machines, both under load, both with 4 atheros and 5 wired NICs, both with 2.6.21.5 kernel + latest trunk, patched one is running for two hours already, unpatched one crashed 3x during that time, so it seems that patch helped, will report again after some more time

spoken too early, it just crashed

unpatched version :

Dhanab_ad_Dulfin login: BUG: NMI Watchdog detected LOCKUP on CPU0, eip c037de30, registers:
Modules linked in: wlan_scan_ap wlan_scan_sta snd_pcm_oss snd_mixer_oss nfsd exportfs ipv6 ohci_hcd rtc_cmos rtc_core rtc_lib amd64_agp agpgart shpchp pci_hotplug e1000 uhci_hcd ehci_hcd usbcore i2c_viapro snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_rhine k8temp ath_rate_sample ath_pci ath_hal(P) wlan_acl wlan eeprom w83781d hwmon_vid i2c_isa i2c_amd756 i2c_core ide_scsi
CPU:    0
EIP:    0060:[<c037de30>]    Tainted: P       VLI
EFLAGS: 00000086   (2.6.21.3-ng-ring3-s2s-sqsh-l7-swan-imq-esfq-smp-kvm-amd-dnd #3)
EIP is at _spin_lock_irqsave+0x40/0x50
eax: 00000086   ebx: f64f2480   ecx: 00000086   edx: f6d078d4
esi: 00000086   edi: 00000600   ebp: f6d10000   esp: f624bc08
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process iptraf (pid: 6758, ti=f624a000 task=f7f72ab0 task.ti=f624a000)
Stack: f8b49304 f6d10000 f6d20540 00000600 00000001 00000001 f6d20540 0000000c 
       00000002 00000004 00000000 00000001 00000000 00000000 00000000 00000000 
       00000003 f6f20480 f6d078d4 f624bc80 00000000 f6d20540 00000086 00000000 
Call Trace:
 [<f8b49304>] ath_tx_start+0x9c4/0x13d0 [ath_pci]
 [<f8b41d3d>] ath_hardstart+0x87d/0xae0 [ath_pci]
 [<c01284f6>] do_gettimeofday+0x36/0x130
 [<c02f5668>] sock_def_readable+0x18/0x80
 [<c036540f>] packet_rcv+0x1ff/0x340
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c030c602>] __qdisc_run+0x72/0x1b0
 [<c02fc791>] dev_queue_xmit+0x221/0x2a0
 [<f8b199b7>] ieee80211_hardstart+0x1c7/0x2f0 [wlan]
 [<c02fbf15>] dev_queue_xmit_nit+0xb5/0x100
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c02fc700>] dev_queue_xmit+0x190/0x2a0
 [<c0302291>] neigh_resolve_output+0xc1/0x170
 [<c03205c2>] ip_output+0x172/0x290
 [<c02f70de>] pskb_expand_head+0xde/0x130
 [<c031eaa0>] ip_forward+0x1a0/0x2a0
 [<c031d236>] ip_rcv+0x236/0x4c0
 [<c02fce5e>] netif_receive_skb+0x2be/0x3c0
 [<f8d14ec7>] e1000_intr+0x97/0x120 [e1000]
 [<f8af2ede>] rhine_rx+0x2de/0x440 [via_rhine]
 [<c01467dc>] handle_fasteoi_irq+0x7c/0xb0
 [<f8af1364>] rhine_napipoll+0x24/0xb0 [via_rhine]
 [<c02fd116>] net_rx_action+0x96/0x1e0
 [<c012481d>] __do_softirq+0xcd/0xf0
 [<c0124891>] do_softirq+0x51/0x60
 [<c012493d>] irq_exit+0x6d/0x70
 [<c010682e>] do_IRQ+0x3e/0x80
 [<c0104b9b>] common_interrupt+0x23/0x28
 =======================
Code: c1 90 fe 0a 79 2e f7 c1 00 02 00 00 74 1d fb 66 66 66 90 66 66 66 90 90 f3 90 80 3a 00 7e f9 fa 66 66 66 90 66 66 66 90 90 eb d6 <f3> 90 80 3a 00 7f cf eb f7 89 c8 c3 8d 74 26 00 89 c2 fa 66 66 

patched one :

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000040
 printing eip:
f8b36b2f
*pde = 00000000
Oops: 0002 [#1]
SMP 
Modules linked in: wlan_scan_sta wlan_scan_ap ath_rate_sample ath_pci ath_hal(P) wlan_acl wlan snd_pcm_oss snd_mixer_oss nfsd exportfs ipv6 ohci_hcd rtc_cmos rtc_core rtc_lib amd64_agp agpgart shpchp pci_hotplug e1000 uhci_hcd ehci_hcd usbcore i2c_viapro snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_rhine k8temp eeprom w83781d hwmon_vid i2c_isa i2c_amd756 i2c_core ide_scsi
CPU:    0
EIP:    0060:[<f8b36b2f>]    Tainted: P       VLI
EFLAGS: 00010203   (2.6.21.3-ng-ring3-s2s-sqsh-l7-swan-imq-esfq-smp-kvm-amd-dnd #3)
EIP is at ath_tx_start+0x16f/0x13d0 [ath_pci]
eax: 3014604a   ebx: 0000001a   ecx: 00000000   edx: 00000004
esi: 00000000   edi: 00000000   ebp: f1ab8000   esp: f1ad1b88
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process iptraf (pid: 7702, ti=f1ad0000 task=f1f97a30 task.ti=f1ad0000)
Stack: 00000000 f1ad1c32 0000001a 00000000 f8b87739 f22fb900 00000000 00000002 
       00000004 00000000 00000001 00000000 00000000 00000000 00000000 00000003 
       f1ad1f44 f1ab98d4 00000286 00000000 00000000 00000000 00000000 00000001 
Call Trace:
 [<f8b87739>] ieee80211_encap+0x1b9/0xf90 [wlan]
 [<f8b2f91f>] ath_hardstart+0x45f/0xb50 [ath_pci]
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c030c712>] __qdisc_run+0x182/0x1b0
 [<c0321b21>] ip_append_data+0x641/0x980
 [<c01284f6>] do_gettimeofday+0x36/0x130
 [<c0365495>] packet_rcv+0x285/0x340
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c030c602>] __qdisc_run+0x72/0x1b0
 [<c02fc791>] dev_queue_xmit+0x221/0x2a0
 [<f8b869b7>] ieee80211_hardstart+0x1c7/0x2f0 [wlan]
 [<c02fbf15>] dev_queue_xmit_nit+0xb5/0x100
 [<c02fc4f2>] dev_hard_start_xmit+0x62/0xe0
 [<c02fc700>] dev_queue_xmit+0x190/0x2a0
 [<c0302291>] neigh_resolve_output+0xc1/0x170
 [<c03205c2>] ip_output+0x172/0x290
 [<c02f70de>] pskb_expand_head+0xde/0x130
 [<c031eaa0>] ip_forward+0x1a0/0x2a0
 [<c031d236>] ip_rcv+0x236/0x4c0
 [<c02fce5e>] netif_receive_skb+0x2be/0x3c0
 [<f8d14ec7>] e1000_intr+0x97/0x120 [e1000]
 [<f8af2ede>] rhine_rx+0x2de/0x440 [via_rhine]
 [<c01467dc>] handle_fasteoi_irq+0x7c/0xb0
 [<f8af1364>] rhine_napipoll+0x24/0xb0 [via_rhine]
 [<c02fd116>] net_rx_action+0x96/0x1e0
 [<c012481d>] __do_softirq+0xcd/0xf0
 [<c0124891>] do_softirq+0x51/0x60
 [<c012493d>] irq_exit+0x6d/0x70
 [<c010682e>] do_IRQ+0x3e/0x80
 [<c0104b9b>] common_interrupt+0x23/0x28
 [<c01737e9>] sys_select+0xf9/0x170
 [<c023dc1b>] copy_to_user+0x2b/0x40
 [<c01041c8>] syscall_call+0x7/0xb
 =======================
Code: 11 00 00 c7 44 24 7c ff ff ff ff 83 84 24 80 00 00 00 04 85 c9 0f 84 52 11 00 00 8b 44 24 6c 8b 8c 24 a0 00 00 00 05 00 00 00 40 <89> 41 40 8b 9c 24 9c 00 00 00 f6 83 d4 0e 00 00 01 0f 85 ea 10 
EIP: [<f8b36b2f>] ath_tx_start+0x16f/0x13d0 [ath_pci] SS:ESP 0068:f1ad1b88
Kernel panic - not syncing: Fatal exception in interrupt

btw, it is kernel 2.6.21.3 but it doesn't matter imo will test now my version of patch for this and report back

BTW, I have been the previous anonymous poster

Thanks for testing,

I'm going to check on why the patched version panic'ing. The panic's you show are different for the patch and unpatch.

The patch has a NULL pointer dereference, while the unpatch is on a spinlock locking error.

Better patch for making sure ATH_TXQ_LOCK plays nice.

New patch up. Hopefully this takes care of the problem.

The other patch didn't take into account of the TX_BUF_LOCK and updating the bf...

If you can test it, and let me know how that works, that'll be great.

Hi, i will test it shortly too and post the results.

So, i'm running now r2485 with the ff_flushdone patch. Let's see how it works.

Here testing machine has been running since yesterday evening - about 13 hours without problem, so it seems this patch fixed the issue. Thx for your work dyqith, i think it should be commited if no one has obligations.

Okay updated svn trunk.

I noticed some other panics, but not related to this issue... will have to look at those when they come up again...