Bug 432927 - switching of rfkill switch not detected on T61/iwl4965
switching of rfkill switch not detected on T61/iwl4965
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-15 03:26 EST by Jiri Cerny
Modified: 2012-06-06 20:25 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.6.24.4-69.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-02 14:03:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Syslog entries related to IRQ 17 (1.56 KB, text/plain)
2008-02-16 13:58 EST, Scott Banwart
no flags Details
Syslog entries slightly different than Scott's (1.68 KB, text/plain)
2008-02-17 02:19 EST, Brad Walker
no flags Details

  None (edit)
Description Jiri Cerny 2008-02-15 03:26:22 EST
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.
Comment 1 Scott Banwart 2008-02-16 13:58:04 EST
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
Comment 2 Scott Banwart 2008-02-16 13:58:48 EST
Created attachment 295079 [details]
Syslog entries related to IRQ 17
Comment 3 Brad Walker 2008-02-17 02:17:50 EST
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
Comment 4 Brad Walker 2008-02-17 02:19:06 EST
Created attachment 295090 [details]
Syslog entries slightly different than Scott's
Comment 5 Pierre-Yves 2008-02-18 03:57:38 EST
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

Comment 6 John W. Linville 2008-02-19 16:27:20 EST
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.
Comment 7 Bradley 2008-02-23 05:24:06 EST
A workaround is to unload then reload the module. I also have to ifconfig <int>
up as well, manually.
Comment 8 Scott Banwart 2008-03-11 10:07:06 EDT
This is still broken with kernel 2.6.24.3-12.fc8.
Comment 9 Brad Walker 2008-03-11 10:54:33 EDT
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.
Comment 10 Leonid Podolny 2008-03-21 10:29:06 EDT
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). 
Comment 11 John W. Linville 2008-04-02 10:41:49 EDT
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!
Comment 12 Brad Walker 2008-04-02 10:59:43 EDT
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.
Comment 13 Brad Walker 2008-04-02 12:55:57 EDT
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?
Comment 14 John W. Linville 2008-04-02 14:03:48 EDT
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!
Comment 15 Scott Banwart 2008-04-30 10:19:56 EDT
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

Note You need to log in before you can comment on or make changes to this bug.