Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1099 (closed defect: fixed)

Opened 13 years ago

Last modified 11 years ago

Crash on x86_64 SMP

Reported by: filippinp [a] yahoo [.] co [.] uk Assigned to:
Priority: major Milestone: version 0.9.5
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Hi, I would like to report this one: 

Call Trace: <IRQ> <ffffffff882ea8c3>{:wlan:ieee80211_beacon_update+67}
       <ffffffff88329d64>{:ath_pci:ath_beacon_generate+868}
       <ffffffff88332525>{:ath_pci:ath_intr+757} 
<ffffffff804100dc>{handle_IRQ_event+44}
       <ffffffff804ad76c>{__do_IRQ+188} <ffffffff8046f122>{do_IRQ+66}
       <ffffffff8059b424>{neigh_lookup+196} 
<ffffffff80463848>{ret_from_intr+0}
       <ffffffff882f97b0>{:wlan:ieee80211_set_tim+0} 
<ffffffff80469263>{_spin_lock+3}
       <ffffffff882f9849>{:wlan:ieee80211_set_tim+153} 
<ffffffff882ed91a>{:wlan:ieee80211_input+2170}
       <ffffffff882b0d27>{:ath_hal:ath_hal_process_noisefloor+298}
       <ffffffff8833195b>{:ath_pci:ath_rx_tasklet+1579} 
<ffffffff80491e86>{tasklet_action+102}
       <ffffffff804115af>{__do_softirq+95} 
<ffffffff804644ea>{call_softirq+30}
       <ffffffff8046ed2c>{do_softirq+44} <ffffffff8046f127>{do_IRQ+71}
       <ffffffff8046cee0>{default_idle+0} 
<ffffffff80463848>{ret_from_intr+0} <EOI>
       <ffffffff80431a80>{unix_poll+0} <ffffffff8046cf0b>{default_idle+43}
       <ffffffff8044d4a0>{cpu_idle+160} <ffffffff80725890>{start_kernel+496}
       <ffffffff80725273>{_sinittext+627}

and 

Call Trace: <IRQ> <ffffffff8831c8c3>{:wlan:ieee80211_beacon_update+67}
       <ffffffff8867e957>{:nvidia:_nv007015rm+125} 
<ffffffff885d281b>{:nvidia:_nv005897rm+21}
       <ffffffff8835bd64>{:ath_pci:ath_beacon_generate+868}
       <ffffffff88364525>{:ath_pci:ath_intr+757} 
<ffffffff88487881>{:nvidia:_nv003582rm+39}
       <ffffffff8867eb14>{:nvidia:_nv007228rm+38} 
<ffffffff88487881>{:nvidia:_nv003582rm+39}
       <ffffffff804100dc>{handle_IRQ_event+44} 
<ffffffff804ad76c>{__do_IRQ+188}
       <ffffffff8867eb14>{:nvidia:_nv007228rm+38} 
<ffffffff8046f122>{do_IRQ+66}
       <ffffffff80463848>{ret_from_intr+0} 
<ffffffff8832b7b0>{:wlan:ieee80211_set_tim+0}
       <ffffffff80469263>{_spin_lock+3} 
<ffffffff8832b849>{:wlan:ieee80211_set_tim+153}
       <ffffffff8831f91a>{:wlan:ieee80211_input+2170} 
<ffffffff88487881>{:nvidia:_nv003582rm+39}
       <ffffffff8867eb14>{:nvidia:_nv007228rm+38} 
<ffffffff882e2d27>{:ath_hal:ath_hal_process_noisefloor+298}
       <ffffffff8836395b>{:ath_pci:ath_rx_tasklet+1579} 
<ffffffff80491e86>{tasklet_action+102}
       <ffffffff804115af>{__do_softirq+95} 
<ffffffff804644ea>{call_softirq+30}
       <ffffffff8046ed2c>{do_softirq+44} <ffffffff8046f127>{do_IRQ+71}
       <ffffffff8046cee0>{default_idle+0} 
<ffffffff80463848>{ret_from_intr+0} <EOI>
       <ffffffff80412e90>{tcp_poll+0} <ffffffff8046cf0b>{default_idle+43}
       <ffffffff8044d4a0>{cpu_idle+160} <ffffffff80725890>{start_kernel+496}
       <ffffffff80725273>{_sinittext+627}

(I have attached a serial console)

The card is in master mode, I am using WEP (I know WEP is bad, but I cannot manage to get my PocketPc? connected with hostapd, but this is an unrelated problem).

The bug is not very frequent - it hangs twice a day, SysRq? is working, but the rest of the PC is completely frozen. I have no way to reproduce this behavior quickly, it seems to be random, usually on the morning I find the machine dead (no usage overnight), plus it happens once in the evening (heavy usage).

I think there is some sort of correlation with the nvidia driver or X, as the machine do not seem to crash in text mode (but I have not tested this extensively).

I searched the existing tickets, it seems that this bug has already been fixed long time ago.

The problem started as soon I upgrade my system to AMD64 x2 and upgraded the system to x86_64, the same driver was working flawlessly before with the same wireless card.

I was using initially madwifi-ng svn r1850, I upgraded to r1968 with a slight improvement - it seems a little bit more stable, but it could be just an impression.

This is my system (uname -a)

Linux cleo 2.6.17.13-tmb-desktop-4mdvsmp #1 SMP Thu Sep 14 14:30:20 CEST 2006 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ GNU/Linux

(I was using 2.6.19 and then downgraded - no changes)

modprobing: 

Jan 15 23:42:26 cleo kernel: ath_pci: 0.9.4.5 (svn r1968)
Jan 15 23:42:26 cleo kernel: ACPI: PCI Interrupt 0000:01:01.0[A] -> Link 
[LNKB] -> GSI 18 (level, low) -> IRQ 82
Jan 15 23:42:26 cleo kernel: wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 
24Mbps 36Mbps 48Mbps 54Mbps
Jan 15 23:42:26 cleo kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Jan 15 23:42:26 cleo kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 
11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Jan 15 23:42:26 cleo kernel: wifi0: H/W encryption support: WEP AES 
AES_CCM TKIP
Jan 15 23:42:26 cleo kernel: wifi0: mac 5.6 phy 4.1 5 GHz radio 1.7 2 
GHz radio 2.3
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 1 for WME_AC_BE traffic
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 0 for WME_AC_BK traffic
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 2 for WME_AC_VI traffic
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 3 for WME_AC_VO traffic
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 8 for CAB traffic
Jan 15 23:42:26 cleo kernel: wifi0: Use hw queue 9 for beacons
Jan 15 23:42:26 cleo kernel: wifi0: Atheros 5212: mem=0xfbfd0000, irq=82

Any other info you need, just ask.

Any clue?

Change History

01/30/07 02:34:56 changed by anonymous

Any news?

02/05/07 23:27:32 changed by anonymous

I installed revision 2070.

Now the problem is more evident (the machine crashes in two hours when using the wireless network), but the machine freezes completely, and SysRq? is not working, so I cannot trigger a stack trace to the serial port, and the serial cable was not connected when the crashes happened (I use a laptop with wireless because I want to be able to move freely around!).

I will try to reproduce it during the weekend with the cable attached, hoping that something is sent over the serial at least on the moment of the crash.

02/20/07 22:19:49 changed by mentor

  • priority changed from critical to major.

02/20/07 22:33:49 changed by mentor

Would you post the text of the kernel bug? Is it a virtual memory trap? A BUG()?

02/27/07 21:46:34 changed by anonymous

I will try to reproduce it again (now the wireless card is disabled). However, in the last days this was always a hard lockup - with no trace to the console.

10/12/07 01:20:23 changed by filippinp [a] yahoo [.] co [.] uk

Hi, I tried a recent version in svn, it is more than a month that it is running without any problem!

I think that this ticket can be safely closed.

10/12/07 06:23:15 changed by mrenzmann

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone set to version 0.9.4.

Thanks for the feedback.

02/11/08 06:15:15 changed by mrenzmann

  • milestone changed from version 0.9.4 to version 0.9.5.

04/17/08 13:46:37 changed by posting@blx4.net

Hi guys,

has this bug really been fixed ?

I seem to have been hitting a similar problem for the last few months, more or less since I went from x64_32/SMP to x64_64/SMP.

Current setup is "Linux 2.6.23-hardened-r9 #2 SMP Mon Apr 14 15:19:45 CEST 2008 x86_64 AMD", madwifi r3545, hostap 0.6.3. ath0 is member of a bridge. WME (802.11e) disabled:

[ 29.244743] ath_hal: module license 'Proprietary' taints kernel. [ 29.246420] ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133) [ 29.253345] wlan: svn r3545 [ 29.256696] ath_pci: svn r3545 [ 29.257040] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 19 [ 29.257047] ACPI: PCI Interrupt 0000:01:09.0[A] -> Link [LNKC] -> GSI 19 (level, low) -> IRQ 19 [ 29.686986] MadWifi: ath_attach: HAL managed transmit power control (TPC) disabled. [ 29.687002] MadWifi: ath_attach: Interference mitigation is supported. Currently disabled. [ 29.687594] MadWifi: ath_attach: Switching rfkill capability off. [ 29.712408] ath_rate_sample: 1.2 (svn r3545) [ 29.713999] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps [ 29.714004] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps [ 29.714012] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps [ 29.714016] wifi0: H/W encryption support: WEP AES AES_CCM TKIP [ 29.714022] wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic [ 29.714024] wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic [ 29.714026] wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic [ 29.714028] wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic [ 29.714030] wifi0: ath_announce: Use hw queue 8 for CAB traffic [ 29.714031] wifi0: ath_announce: Use hw queue 9 for beacons [ 29.744302] ath_pci: wifi0: Atheros 5212: mem=0xfebe0000, irq=19

Things seem to run fine for a while, but suddenly the system locks up hard and reboots (panic=5). No log messages.

The most reliable way to trigger this is to use my Siemens SL75WLAN phone. I get a call and (often - not always) as soon as I pick up, the machine locks up. The SIP messages don't seem to trigger it. It happens as soon as the voice data is being sent (both ways!, could that trigger something) ?

Using my Thinkpad with a built-in Atheros a/b/g card is less likely to trigger this bug. In fact, I can't remember if it ever did, but can not rule it out.

Any further info that I could provide ?

Thx,

Mathias