Latest working kernel version: None - driver introduced in 2.6.24 Earliest failing kernel version: 2.6.24-rc8-git4 Distribution: Was once Peanut Linux (a Slackware derivative), but now highly customised Hardware Environment: Belkin F5D7010 (11g) wireless adapter and a Draytek Vigor 2600WE AP (11b) Software Environment: rt61pci driver on 2.6.24 kernel Problem Description: I can reliably crash the driver by running the following script: #!/bin/sh for i in `seq 1 100`; do echo $i > itercount rm -f linux-2.6.23.tar.bz2 wget ftp://192.168.1.10/pub/linux-2.6.23.tar.bz2 done The most complete diagnostics I have copied from the console are: Call Trace: [<c011440a>] __update_rq_clock+0x1a/0xf0 [<e08ff59d>] rt2x00lib_txdone+0x9d/0xd0 [rt2x00lib] [<e0909573>] rt61pci_txdone+0x153/0x1f0 [rt61pci] [<e09096ad>] rt61pci_interrupt+0x9d/0xb0 [rt61pci] [<c0140dc7>] handle_IRQ_event+0x27/0x60 [<c0141fbb>] handle_level_irq+0x6b/0x100 [<c014if50>] handle_level_irq+0x0/0x100 [<c0105db8>] do_IRQ+0x68/0xc0 [<c011440a>] __update_rq_clock+0x1a/0xf0 [<c01042f3>] common_interrupt+0x23/0x28 [<c014007b>] encode_comp2_t+0x4b/0x80 [<c011007b>] acpi_copy_wakeup_routine+0x2b/0x9c [<c02161fb>] acpi_processor_idle+0x25b/0x36e [<c01020dc>] cpu_idle+0x5c/0x80 [<c040381b>] start_kernel+0x18b/0x1d0 [<c0403360>] unknown_bootoption+0x0/0x150 ======================== Code: 00 00 00 e9 6c ff ff ff 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 cd 57 56 53 83 ec 10 89 d3 89 44 24 08 ba 20 00 00 00 8b 40 58 <89> 43 14 a1 10 66 3e c0 e8 6c f9 82 df 89 44 24 0c 85 c0 89 c7 EIP: [<e0930eb7>] ieee80211_tx_status_irqsafe+0x17/0x120 [mac80211] SS:ESP 0068: c042ff4c Kernel panic - not syncing: Fatal exception in interrupt Steps to reproduce: If I start any non-trivial network activity, the crash will occur. See the thread at http://marc.info/?l=linux-wireless&m=120098190722048&w=4 for all info collected so far.
Can you recreate this using a current net-2.6 kernel? I would suggest a wireless-2.6 kernel but it is in a bit of flux ATM...
On Friday 01 February 2008 15:24:09 you wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9860 > > > linville@tuxdriver.com changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- CC| |IvDoorn@gmail.com > AssignedTo|networking_wireless@kernel- |linville@tuxdriver.com > > |bugs.osdl.org | > > Status|NEW |ASSIGNED > Component|Wireless |network-wireless > Product|Networking |Drivers > > > > > ------- Comment #1 from linville@tuxdriver.com 2008-02-01 07:24 ------- > Can you recreate this using a current net-2.6 kernel? I would suggest a > wireless-2.6 kernel but it is in a bit of flux ATM... I'm not a git user, so is there a tarball of current net-2.6 available anywhere, please? If so, I'll give it a go. Chris
I've tried 2.6.24-git13, which appears to be in roughly the same state as net-2.6 as far as the rt61pci driver is concerned, and found that I no longer get the lock-up and flashing LEDs. However, my network dies after only minimal activity. For example, if I try to ping another box on my network (a simple "ping 192.168.1.1"), my network locks up after between 3 and 10 pings. Similarly, my network dies before the whole of the home page at kernel.org has arrived. The only way I can get the network back is to unload and reload the driver. (You will be pleased to hear, however, that the rtl8180 driver seems to be solid. It has survived 11 ftp transfers of the 2.6.23 kernel sources without failing.)
Sorry, I should have said that when the network dies, there are no diagnostic messages in /var/log/syslog or in the output from dmesg.
Created attachment 14764 [details] Screenshot of rt61pci oops Screenshot of rt61pci oops
Mmm, my note disappeared somehow :( The screenshot I attached a few moments ago is from 2.6.24.1. I didn't expect the release to have fixed the oops, but thought I'd give it a go anyway. Is theer anything I can do to help get to the bottom of this, bearing in mind that I am not a git user.
Can you enable a framebuffer? That would allow us to see more of the crash message on screen. It is missing some crucial info which has been pushed off.
I think I may have an explanation for the crashes I have been experiencing. Earlier this week, my wireless LAN locked up completely. None of the machines in my home (Linux and Windows) could connect. I powered the router off and on and since then the rt61pci driver is no longer failing. So, it would appear that there is a problem in the driver, but, at least for now, I won't be able to provide you with any additional information. What ever the problem was, the rtl8180 driver in 2.3.25-{gitn,rc1} is not vulnerable to it, because it has worked reliably throughout. I suggest I close the bug and report again if and when my AP begins to 'misbehave'. Is that OK, please?
I think I can confirm this bug, because I'm experiencing the same behaviour; I can't give details, though, because as OP said, i can't find anything in my logs. I can tell you here's the ubuntu hardy kernel, 2.6.24-4 works, while all the following updates do not I know it's little, but i hope it helps
Created attachment 15072 [details] screenshot of the kernel panic as a proof of the bug occurring, I'm posting a screenshot (actually a real shot of the display); really the output seems a bit different. I boot with acpi=force and the patch at bug #8896 is NOT applied (on that bug you can find more about my hardware, anyway). ubuntu 7.04 (gutsy) but with kernel from hardy; bug doesn't occur with 2.6.24-4 but with the following updates does. HTH
Created attachment 15138 [details] some more output for the kpanic some more output
bug seems fixed in net-2.6 branch!
Excellent! Closing on the basis of comment 12...
well if you could please provide a patch for 2.6.24 in the meantime,it would be great; I had to recompile the whole branch and I think I've found some other regressions somewhere else I wouldn't want to have to deal with ATM ;)
Providing that patch is a bit hard, I still have no idea what is/was causing that panic. They all point to something in mac80211 and not rt2x00. Unfortunately they point to a function in mac80211 that is pretty straightforward where not much can go wrong. I fear that the fix for this issue is more a side-effect of a patch that handled something completely different. And knowing that the rt2x00 in 2.6.24 handles some things completely differently then current net-2.6 branch, with some very large patches to rework some internal workings, we probably can't find the correct solution by simply pointing at a particular patch.
Yes, I feared this problem; I'll try and see if people at ubuntu can backport the whole drivers/net/wireless + net/mac80211 trees