Thread: [Madwifi-devel] Kernel Oops after "ifconfig ath0 up" (madwifi-ng r1486)
Status: Beta
Brought to you by:
otaku
From: Raphael S. <hi...@ra...> - 2006-04-29 10:17:15
|
Dear all, I constantly get a kernel oops with my TP-Link D510 wireless card (oops attached). Otherwise my system (HP Omnibook 800CT, Kernel 2.6.16.1, Kernel config and startup-dmesg attached) is perfectly stable. My Xircom network card (it is 16bit pcmcia, maybe this counts?) works perfectly as well. When I just insert the wireless card, it says in the kernel log: ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) wlan: 0.8.4.2 (svn 1486) ath_rate_sample: 1.2 (svn 1486) ath_pci: 0.9.4.5 (svn 1486) PCI: Enabling device 0000:02:00.0 (0000 -> 0002) wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps s wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 7.8 phy 4.5 radio 5.6 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0x12000000, irq=9 The system remains durably stable at this step. But after invoking "ifconfig ath0 up" it panics either immediately or after a few seconds (once after 2 minutes or so). Sometimes there is enough time to run a "iwlist ath0 scan" - it shows all APs in range. Once I also managed to associate for a few seconds before the freeze... You can find the oops attached to this email. I think its something about IRQs (btw: there are no IRQ conflicts, I checked this point, of course...). It makes no difference if I include the "spinlock patch" (ticket #472) or not. I am struggling with this error since weeks, tried several revisions of madwifi and madwifi-ng and all thinkable combinations of kernel parameteres regarding the PCMCIA socket, PCI, PNP and APM stuff... Maybe someone on this list can help me? Thanks, Raphael |
From: Daniel W. <dy...@gm...> - 2006-04-29 15:18:33
|
Can you try the latest revision in svn ? It has some fixes for these type of issues. |
From: Raphael S. <hi...@ra...> - 2006-04-29 17:03:12
|
On Sat, Apr 29 at 08:11, Daniel Wu wrote: > Can you try the latest revision in svn ? I tried r1531, the latest one. > It has some fixes for these type of issues. Not for my problem, looks like. This time it oopses that way (seems to be the same problem to me): ****************** Unable to handle kernel paging request at virtual address fe570014 printing eip: *pde = 00000000 Oops: 0000 [#1] Modules linked in: wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal serial_cse CPU: 0 EIP: 0060:[<c593547c>] Tainted: P VLI EFLAGS: 00010202 (2.6.16.1 #1) EIP is at zz005b88fd+0x20/0x130 [ath_hal] eax: fe570000 ebx: c1bc0150 ecx: 0000000f edx: c1bc0150 esi: c4b9ac00 edi: c1bc8000 ebp: c1bc2260 esp: c02d9eec ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c02d8000 task=c029cb00) Stack: <0>c1924150 c4b9ac00 c1bc0150 c59719e1 c1bc8000 c1bc0150 01bc0150 fe5700 026bec29 00000000 0000000a 026bec29 00000000 c02d9f24 c1bc37b4 c1bc8000 c1bc8000 00000000 c1bc2260 00000000 c1bc8000 c5972008 c1bc2260 faec96c6 Call Trace: [<c59719e1>] ath_uapsd_processtriggers+0xb1/0x4c0 [ath_pci] [<c5972008>] ath_intr+0x218/0x300 [ath_pci] [<c012aef8>] handle_IRQ_event+0x28/0x70 [<c012af97>] __do_IRQ+0x57/0xa0 [<c010415a>] do_IRQ+0x1a/0x30 [<c0102aca>] common_interrupt+0x1a/0x20 [<c0100ba3>] default_idle+0x33/0x60 [<c010987b>] apm_cpu_idle+0x8b/0x150 [<c0100c3c>] cpu_idle+0x4c/0x60 [<c02da6b6>] start_kernel+0x146/0x160 Code: 10 00 00 00 00 b8 01 00 00 00 c3 57 56 53 8b 7c 24 10 8b 5c 24 14 89 da 8 <0>Kernel panic - not syncing: Fatal exception in interrupt ****************** Any suggestion appreciated... Raphael |
From: Paolo <oo...@us...> - 2006-04-29 18:59:44
|
On Sat, Apr 29, 2006 at 07:02:33PM +0200, Raphael Susewind wrote: > EFLAGS: 00010202 (2.6.16.1 #1) try 2.6.16.11 if you can - 2.6.16.x, x<5 had some issues for me as well. Besides, .11 fixes a few sec. related issues. -- paolo |
From: Raphael S. <hi...@ra...> - 2006-04-30 10:29:13
|
On Sat, Apr 29 at 08:59, Paolo wrote: > try 2.6.16.11 if you can - 2.6.16.x, x<5 had some issues for me as well. > Besides, .11 fixes a few sec. related issues. Does not help - again the same oops... Raphael |
From: Raphael S. <hi...@ra...> - 2006-04-30 11:19:44
|
On Sun, Apr 30 at 12:28, Raphael Susewind wrote: Dear all, I found the following discussion in the madwifi-devel-archives: http://article.gmane.org/gmane.linux.drivers.madwifi.devel/1525 and tried the solution proposed there (moving the ath_uapsd_processtriggers out of the interrupt loop into the ath_rx_tasklet). This does not solve the problem, but at least it takes now a lot more time until oops... So I assume the whole problem comes from too much stress on the receive-handling. As I am only scanning at the moment this is bad news - what will happen if I start real network traffic...? However, would be nice if someone could explain me what all this uapsd and rx stuff does and how I can better debug it so that we together can trace down the problem... Raphael > On Sat, Apr 29 at 08:59, Paolo wrote: > > > try 2.6.16.11 if you can - 2.6.16.x, x<5 had some issues for me as well. > > Besides, .11 fixes a few sec. related issues. > > Does not help - again the same oops... > > Raphael |
From: Michael R. <ma...@no...> - 2006-05-30 05:10:58
|
Hi. Raphael Susewind wrote: > I found the following discussion in the madwifi-devel-archives: > > http://article.gmane.org/gmane.linux.drivers.madwifi.devel/1525 > > and tried the solution proposed there (moving the ath_uapsd_processtriggers > out of the interrupt loop into the ath_rx_tasklet). This does not solve the > problem, but at least it takes now a lot more time until oops... So I assume > the whole problem comes from too much stress on the receive-handling. Is this still an issue with 0.9.0 or the most current svn (which has a new HAL)? Bye, Mike |
From: Raphael S. <hi...@ra...> - 2006-05-30 09:50:08
|
On Tue, May 30 at 07:10, Michael Renzmann wrote: Hi, > Is this still an issue with 0.9.0 or the most current svn (which has a > new HAL)? Yes. I tried with r1605 (and HAL 0.9.17 which I downloaded manually) and r1611 (same HAL) - still the same problem. But it takes more time until oops now - sometimes up to a few minutes... Since i started this discussion on the list i also opened a ticket (#593) for this problem and I suggest discussing further there... Raphael |