Description of problem: When I boot my T61 with radio kill switch enabled (=wireless switched off) and then switch it off (=enable wireless), nothing happens. I have to unload module iwl4965, load it again and restart NetworkManager, to see wireless networks in nm-applet. Trick with echo 0 > ./devices/pci0000:00/0000:00:1c.1/0000:03:00.0/rf_kill does not work. It remains 2 Version-Release number of selected component (if applicable): Fedora 8 with updates upto 14 Feb 2008 # rpm -q iwl4965-firmware kernel iwl4965-firmware-4.44.1.20-1 kernel-2.6.23.14-115.fc8 kernel-2.6.23.15-137.fc8 # uname -a Linux 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux Additional info: My wife has slightly older T61 with the same wireless card and she sees the same behaviour. Moreover she claims, that it worked say 2 or 3 weeks ago.
I am having the same problem, except that when I turn the wireless on using the kill switch, I get the error message "Disabling IRQ 17". I've attached the relevant section from my syslog. This is with kernel version 2.6.23.15-137.fc8 and iwl4965-firmware version 4.44.1.20-1. This first started happening with kernel version 2.6.23.14-115.fc8, but worked fine with kernel versions prior to that. $ uname -a Linux 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 295079 [details] Syslog entries related to IRQ 17
I have the same problem as Scott on my X61s w/iwl4965 running rawhide x86_64. It hasn't worked for quite some time. kernel-2.6.25-0.50.rc2.fc9 doesn't even boot. $ uname -a Linux brad.office 2.6.25-0.40.rc1.git2.fc9 #1 SMP Wed Feb 13 17:17:48 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 295090 [details] Syslog entries slightly different than Scott's
It seems that I have the same problem on a HP Pavilion dv6599, except that I get the "kernel: Disabling IRQ #16" instead of 17. I do not use enough my wireless to be able to say from when it does this. uname -a Linux pingouGreen.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
I think I've recreated this on my t61, first impression is that iwl4965 has unregistered irq handler inappropriately. I'll take a closer look at the code to confirm.
A workaround is to unload then reload the module. I also have to ifconfig <int> up as well, manually.
This is still broken with kernel 2.6.24.3-12.fc8.
I still have this problem with kernel-2.6.24.3-28.fc8.x86_64 and kernel-2.6.25-0.107.rc5.fc9.x86_64. Also, the wireless won't connect regardless of module reloading workarounds or even booting up with RFKILL off.
Hi, This bug is absolutely reproducible. If I boot my laptop with wifi off (i.e. with RF kill switch on, i.e. with LEDs off), and then, after the computer finished booting, press the WiFi button, the computer crashes with exactly the same symptoms as desctibed above. Note that first 2.6.23 kernels didn't suffer from this issue, i.e. the 2.6.23.1-42.fc8 shipped with original F8 works great for me. The first kernel to suffer from this problem was 2.6.23.14-115.fc8. (See this thread: http://www.nabble.com/Kernel-115-Doesn't-Like-iwl4965-td15413273.html).
I haven't had a chance to try it, but these kernels have a fix related to iwlwifi and rfkill: http://koji.fedoraproject.org/koji/buildinfo?buildID=44217 http://koji.fedoraproject.org/koji/buildinfo?buildID=44544 Perhaps someone else would like to try it in the meantime? If so, please report back here with the results...thanks!
The console still prints 'disabling IRQ 17' with kernel-2.6.25-0.185.rc7.git6.fc9. And a call trace: iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC ACPI: PCI interrupt for device 0000:03:00.0 disabled irq 17: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.25-0.185.rc7.git6.fc9.x86_64 #1 Call Trace: <IRQ> [<ffffffff812a5ef3>] ? _spin_unlock+0x26/0x2a [<ffffffff81079523>] __report_bad_irq+0x38/0x7c [<ffffffff8107976c>] note_interrupt+0x205/0x26d [<ffffffff81079e8f>] handle_fasteoi_irq+0xb3/0xdd [<ffffffff8100e733>] do_IRQ+0xf7/0x167 [<ffffffff8100c5e6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff811894b5>] ? acpi_idle_enter_bm+0x2b1/0x336 [<ffffffff811894ab>] ? acpi_idle_enter_bm+0x2a7/0x336 [<ffffffff812028fe>] ? menu_select+0x6f/0x8f [<ffffffff8120196f>] ? cpuidle_idle_call+0x8b/0xbf [<ffffffff812018e4>] ? cpuidle_idle_call+0x0/0xbf [<ffffffff8100b141>] ? default_idle+0x0/0x73 [<ffffffff8100b0f9>] ? cpu_idle+0xaa/0xf2 [<ffffffff81296206>] ? rest_init+0x5a/0x5c handlers: [<ffffffff811d08f2>] (usb_hcd_irq+0x0/0x62) [<ffffffff882ab372>] (azx_interrupt+0x0/0xe0 [snd_hda_intel]) Disabling IRQ #17 ALSA sound/pci/hda/hda_intel.c:596: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x002f000a I'm going to try kernel-2.6.24.4-69.fc8 when it's done building.
While waiting I tried kernel-2.6.24.4-64.fc8. It printed 'Disabling IRQ 17' and recorded a call trace similar to above. kernel-2.6.24.4-69.fc8 seems to have fixed the IRQ problem but created some quirks with NetworkManager and the wireless LED. I booted the machine with RK kill on and then switched RK kill off after logging in through GDM. NM showed the disconnected icon and didn't show any scanned networks. I toggled 'Enable Wireless' off and on again and then NM showed networks and connected to the default AP. I tried booting up with RK kill off and then toggling it on and off. A few seconds after switching on RK kill, the wireless LED turned on again. I switched off RK kill and the LED stayed on. The LED worked as expected when cycling between on and off a few more times. Should this go in another bug?
Re: comment 12 -- sorry, I was wrong. No rawhide kernels w/ the patch have been built yet. Re: comment 13 -- it sounds like the patch in question actually resolves the base issue! :-) The item in the 3rd paragraph might should go to the NetworkManager people, although they might tell me the driver is not doing something properly -- not sure. The item in the 4th paragraph might be worth a new (kernel) bug as well. I'm going to mark this one as CURRENTRELEASE based on your report about -69.fc8...thanks!
I'm still getting this stack trace with kernel 2.6.24.5-85.fc8. irq 17: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Tainted: P 2.6.24.5-85.fc8 #1 Call Trace: <IRQ> [<ffffffff8104b993>] hrtimer_start+0x113/0x125 [<ffffffff8106f03b>] __report_bad_irq+0x30/0x72 [<ffffffff8106f28c>] note_interrupt+0x20f/0x253 [<ffffffff8106fb8c>] handle_fasteoi_irq+0xa9/0xd0 [<ffffffff8100e62f>] do_IRQ+0xf1/0x162 [<ffffffff8100c3a1>] ret_from_intr+0x0/0xa <EOI> [<ffffffff8125cc95>] unix_poll+0x0/0x96 [<ffffffff81032cc6>] finish_task_switch+0x33/0xa8 [<ffffffff81267f96>] thread_return+0x3d/0x81 [<ffffffff8101cecf>] lapic_next_event+0x0/0xa [<ffffffff81050cfd>] tick_nohz_restart_sched_tick+0x12b/0x12f [<ffffffff811dea2b>] cpuidle_idle_call+0x0/0xa9 [<ffffffff8100b150>] cpu_idle+0xb7/0xbc handlers: [<ffffffff811b4dfe>] (usb_hcd_irq+0x0/0x52) [<ffffffff881d6494>] (irq_handler+0x0/0x370 [firewire_ohci]) [<ffffffff882b3df7>] (azx_interrupt+0x0/0xc3 [snd_hda_intel]) Disabling IRQ #17