Bug 15303 - WLAN cannot be activated if booted with activated RF kill switch on Sony notebook (iwl3945)
WLAN cannot be activated if booted with activated RF kill switch on Sony note...
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Platform
i386 Linux
: P1 normal
Assigned To: Mattia Dongili
:
Depends on:
Blocks: 56331
  Show dependency treegraph
 
Reported: 2010-02-14 22:59 UTC by Thomas Klose
Modified: 2013-04-09 06:23 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: No


Attachments
Output in /var/log/messages (1.87 KB, text/plain)
2010-02-16 19:44 UTC, Thomas Klose
Details
DSDT Table for Sony VAIO VGN-TX3HP (18.65 KB, application/octet-stream)
2010-03-02 13:51 UTC, Thomas Klose
Details
DSDT Table for Sony VAIO VGN-TX5MN (20.79 KB, application/octet-stream)
2010-03-02 13:52 UTC, Thomas Klose
Details
Commented /var/log/messages (sony-laptop: debug=1) (9.26 KB, text/plain)
2010-03-02 16:46 UTC, Thomas Klose
Details
Output of dmesg (58.40 KB, text/plain)
2010-03-02 16:47 UTC, Thomas Klose
Details
Commented /var/log/messages (sony-laptop: modified, debug=1) (8.15 KB, text/plain)
2010-03-04 08:50 UTC, Thomas Klose
Details
sony-laptop: let the minidriver handle the irq first (2.19 KB, patch)
2010-05-24 13:53 UTC, Mattia Dongili
Details | Diff
Commented /var/log/messages (sony-laptop: patched, debug=1) (10.77 KB, text/plain)
2010-05-25 21:27 UTC, Thomas Klose
Details
Ignore wireless events (1.49 KB, patch)
2010-06-06 06:24 UTC, Mattia Dongili
Details | Diff
Ignore wireless events (1.07 KB, patch)
2010-06-06 08:20 UTC, Mattia Dongili
Details | Diff

Description Thomas Klose 2010-02-14 22:59:00 UTC
Keywords:
WLAN, RF kill switch, iwl3945, sony-laptop

Kernel version:
Linux version 2.6.32-13-generic (buildd@vernadsky) (gcc version 4.4.3 (Ubuntu 4.4.3-2ubuntu1) ) #18-Ubuntu SMP Wed Feb 10 21:24:20 UTC 2010
(I was also able to confirm the problem with Ubuntu Karmic and Fedora 12)

Description:
If the RF kill switch is activated during booting my Sony Notebook (VGN-TX3HP) WLAN cannot be activated later. If WLAN is activated during boot it can be deactivated and reactivated without problems.

I was able to narrow down the problem: If I unload the sony-laptop module before disabling the kill switch, WLAN becomes active without problems. Then I can load sony-laptop without it is causing problems.

This problem did not occur with Kernel versions <=2.6.28 (at least).

Steps to reproduce the problem:
- get a Sony Vaio laptop with iwl3945 hardware (my is a TX3HP)
- enable RF kill switch (disable WLAN)
- boot Linux
- disable RF kill switch (enable WLAN)
- WLAN does not become available  

Steps to reproduce my workaround:
- get a Sony Vaio laptop with iwl3945 hardware (my is a TX3HP)
- enable RF kill switch (disable WLAN)
- boot Linux
- unload sony-laptop module
- disable RF kill switch (enable WLAN)
- WLAN becomes available  
- load sony-laptop module
Comment 1 John W. Linville 2010-02-16 17:48:18 UTC
After disabling rfkill switch, did you 'sudo ifconfig wlan0 up'?  IIRC, the iwl3945 hardware cannot detect that event by itself.
Comment 2 Thomas Klose 2010-02-16 19:44:35 UTC
Created attachment 25069 [details]
Output in /var/log/messages
Comment 3 Thomas Klose 2010-02-16 19:44:54 UTC
No. I am not using the ifconfig infrastructure. I configured Gnome's NetworkManager instead. So my /etc/network/interfaces is empty.

However, it seems that iwl3945 can detect the switch events. If I unload sony-laptop and switch, WLAN becomes available by itself. It is possible that NetworkManager is polling the WLAN hardware status though.

Please find attached a file with information from /var/log/messages. I disabled the kill switch after booting with and without sony-laptop module to generate it.

The USB device "usb 5-1" seems to be the integrated bluetooth transceiver which is de/activated by the same switch.
Comment 4 John W. Linville 2010-02-16 20:00:10 UTC
ifconfig doesn't use /etc/network/interfaces -- that is some Debian-ish configuration file.  At least at one time in the past it was required to ifconfig up an iwl3945 device after disabling rfkill.

It sounds to me like the problem you are experiencing is with sony-laptop.
Comment 5 Thomas Klose 2010-02-17 11:22:05 UTC
(In reply to comment #4)
> It sounds to me like the problem you are experiencing is with sony-laptop.
I agree.
Comment 6 Zhang Rui 2010-03-02 08:46:03 UTC
re-assign to Mattia.
Comment 7 Mattia Dongili 2010-03-02 11:07:15 UTC
Hi Thomas,

could you attach the DSDT table from your laptop?

Also, could you test the following:
1. boot with rfkill switch on and sony-laptop loaded, what does
   $ grep . /sys/class/rfkill/*/{state,name}
   report?
2. switch rfkill off, what does the above command report?
3. would at this point echoing 1 to the sony-wlan rfkill node trigger the wlan card to appear?

Last, in your report when you talk about rfkill your're referring to the hardware switch, not the soft one, right?

Thanks
Comment 8 Thomas Klose 2010-03-02 13:49:37 UTC
(In reply to comment #7)
> could you attach the DSDT table from your laptop?
I will attach DSDT tables for Sony VAIO VGN-TX5MN and VGN-TX3HP. Both show the same problem. However, the tables seem to be different.

> Also, could you test the following:
> 1. boot with rfkill switch on and sony-laptop loaded, what does
>    $ grep . /sys/class/rfkill/*/{state,name}
>    report?
It reports:
   /sys/class/rfkill/rfkill0/state:2
   /sys/class/rfkill/rfkill0/name:phy0

> 2. switch rfkill off, what does the above command report?
It reports:
   /sys/class/rfkill/rfkill2/state:1
   /sys/class/rfkill/rfkill3/state:0
   /sys/class/rfkill/rfkill2/name:hci0
   /sys/class/rfkill/rfkill3/name:phy2

If I switch it on again, the output is _not_ the same as before:
   /sys/class/rfkill/rfkill3/state:2
   /sys/class/rfkill/rfkill3/name:phy2

And off again:
   /sys/class/rfkill/rfkill4/state:1
   /sys/class/rfkill/rfkill6/state:0
   /sys/class/rfkill/rfkill4/name:hci0
   /sys/class/rfkill/rfkill6/name:phy4

If I continue, different numbers appear. This seems a little bit strange?

> 3. would at this point echoing 1 to the sony-wlan rfkill node trigger the wlan
> card to appear?
Yes. If I echo 1 to state of the current phy node wlan becomes active.
 
> Last, in your report when you talk about rfkill your're referring to the
> hardware switch, not the soft one, right?
I am always refering to the hardware switch.
Comment 9 Thomas Klose 2010-03-02 13:51:30 UTC
Created attachment 25318 [details]
DSDT Table for Sony VAIO VGN-TX3HP
Comment 10 Thomas Klose 2010-03-02 13:52:13 UTC
Created attachment 25319 [details]
DSDT Table for Sony VAIO VGN-TX5MN
Comment 11 Mattia Dongili 2010-03-02 14:37:13 UTC
Thanks

(In reply to comment #8)
> (In reply to comment #7)
> > could you attach the DSDT table from your laptop?
> I will attach DSDT tables for Sony VAIO VGN-TX5MN and VGN-TX3HP. Both show the
> same problem. However, the tables seem to be different.

the sony-laptop driver is not controlling the wlan kill switch on those TX vaios. At least it's not trying to.
 
> > 2. switch rfkill off, what does the above command report?
> It reports:
>    /sys/class/rfkill/rfkill2/state:1
>    /sys/class/rfkill/rfkill3/state:0
>    /sys/class/rfkill/rfkill2/name:hci0
>    /sys/class/rfkill/rfkill3/name:phy2

these are not sony-laptop's, the wifi driver handles them. I assume that if you did this without sony-laptop the state of phyN is 1 after you switch rfkill off.

...
> If I continue, different numbers appear. This seems a little bit strange?

no, new device nodes get created each time you switch on/off.

> > 3. would at this point echoing 1 to the sony-wlan rfkill node trigger the wlan
> > card to appear?
> Yes. If I echo 1 to state of the current phy node wlan becomes active.

Odd, and all this behaviour is different if the sony-laptop driver is loaded...

All I can think of is that when the SPIC device is enabled (the one handled by sony-laptop) the hardware expects the software to take some odd action (why??).
Can you play around a bit with rfkill switch with sony-laptop loaded (possibly with `modprobe sony-laptop debug=1`) and see if the interrupt count increases for sony-laptop in /proc/interrupts (don't touch the fn keys, they will increase the interrupt count too). Also please attach the output of dmesg resulting from this test.

-- mattia
Comment 12 Thomas Klose 2010-03-02 16:45:06 UTC
(In reply to comment #11)
> > > 2. switch rfkill off, what does the above command report?
> > It reports:
> >    /sys/class/rfkill/rfkill2/state:1
> >    /sys/class/rfkill/rfkill3/state:0
> >    /sys/class/rfkill/rfkill2/name:hci0
> >    /sys/class/rfkill/rfkill3/name:phy2
> 
> these are not sony-laptop's, the wifi driver handles them. I assume that if you
> did this without sony-laptop the state of phyN is 1 after you switch rfkill
> off.
Yes. The output then is:
   /sys/class/rfkill/rfkill2/state:1
   /sys/class/rfkill/rfkill3/state:1
   /sys/class/rfkill/rfkill2/name:hci0
   /sys/class/rfkill/rfkill3/name:phy2

> > > 3. would at this point echoing 1 to the sony-wlan rfkill node trigger the wlan
> > > card to appear?
> > Yes. If I echo 1 to state of the current phy node wlan becomes active.
> 
> Odd, and all this behaviour is different if the sony-laptop driver is loaded...
It seems this way.

> All I can think of is that when the SPIC device is enabled (the one handled by
> sony-laptop) the hardware expects the software to take some odd action (why??).
> Can you play around a bit with rfkill switch with sony-laptop loaded (possibly
> with `modprobe sony-laptop debug=1`) and see if the interrupt count increases
> for sony-laptop in /proc/interrupts (don't touch the fn keys, they will
> increase the interrupt count too). Also please attach the output of dmesg
> resulting from this test.
It seems that changing the state of the kill switch always results in one interrupt for module sony-laptop. This is confirmed by a comment in /var/log/messages if the debug mode is enabled.

Please find attached a commented part of the messages file and output of dmesg.

Thanks, Thomas
Comment 13 Thomas Klose 2010-03-02 16:46:28 UTC
Created attachment 25323 [details]
Commented /var/log/messages (sony-laptop: debug=1)
Comment 14 Thomas Klose 2010-03-02 16:47:03 UTC
Created attachment 25324 [details]
Output of dmesg
Comment 15 Mattia Dongili 2010-03-03 14:04:58 UTC
(In reply to comment #12)
> (In reply to comment #11)
...
> > All I can think of is that when the SPIC device is enabled (the one handled by
> > sony-laptop) the hardware expects the software to take some odd action (why??).
> > Can you play around a bit with rfkill switch with sony-laptop loaded (possibly
> > with `modprobe sony-laptop debug=1`) and see if the interrupt count increases
> > for sony-laptop in /proc/interrupts (don't touch the fn keys, they will
> > increase the interrupt count too). Also please attach the output of dmesg
> > resulting from this test.
> It seems that changing the state of the kill switch always results in one
> interrupt for module sony-laptop. This is confirmed by a comment in
> /var/log/messages if the debug mode is enabled.

Thanks.
I don't think there is much that can be done here. The interrupt you see and the event printed in the kernel log are handled from sony-laptop as an input events and sent to userspace via the input subsystem, X should get them.
You should also get the event via acpid, I guess I should convert that /proc event to a netlink one at some point.

Anyway, unfortunately, there is no way that sony-laptop can control the rfkill switch via the SPIC device. It's completely undocumented and I don't have the hardware nor the time to invest in tracing windows drivers to understand how to deal with it.

The only thing that I'm curious about is what happens if you comment out the rfkill event handling (around line 1774 of drivers/platform/x86/sony-laptop.c):

/* The set of possible wireless events */
static struct sonypi_event sonypi_wlessev[] = {
        { 0x59, SONYPI_EVENT_WIRELESS_ON },
        { 0x5a, SONYPI_EVENT_WIRELESS_OFF },
        { 0, 0 }
};

comment this out the reference to sonypi_wlessev at line 1882 as well. You should get an additional interrupt and event printed out. Might be worth giving it a go.

-- mattia
Comment 16 Mattia Dongili 2010-03-03 14:06:08 UTC
sorry, line numbers from my previous comment are a bit off in 2.6.32, just search the variable in the code.

-- mattia
Comment 17 Thomas Klose 2010-03-04 08:46:49 UTC
(In reply to comment #15)
> I don't think there is much that can be done here. The interrupt you see and
> the event printed in the kernel log are handled from sony-laptop as an input
> events and sent to userspace via the input subsystem, X should get them.
> You should also get the event via acpid, I guess I should convert that /proc
> event to a netlink one at some point.
> 
> Anyway, unfortunately, there is no way that sony-laptop can control the rfkill
> switch via the SPIC device. It's completely undocumented and I don't have the
> hardware nor the time to invest in tracing windows drivers to understand how to
> deal with it.
It worked with older kernel versions, though. And since the Fn keys did work too, the sony-laptop module was not an issue then.

> 
> The only thing that I'm curious about is what happens if you comment out the
> rfkill event handling (around line 1774 of drivers/platform/x86/sony-laptop.c):
> 
> /* The set of possible wireless events */
> static struct sonypi_event sonypi_wlessev[] = {
>         { 0x59, SONYPI_EVENT_WIRELESS_ON },
>         { 0x5a, SONYPI_EVENT_WIRELESS_OFF },
>         { 0, 0 }
> };
> 
> comment this out the reference to sonypi_wlessev at line 1882 as well. You
> should get an additional interrupt and event printed out. Might be worth giving
> it a go.
This actually does the trick. With this modifications it works perfectly. I attatch commentet output in /var/log/messages again (sony-laptop debug=1).

Regards, Thomas
Comment 18 Thomas Klose 2010-03-04 08:50:22 UTC
Created attachment 25353 [details]
Commented /var/log/messages (sony-laptop: modified, debug=1)
Comment 19 Zhang Rui 2010-03-10 05:46:44 UTC
ping mattia, any update? :)
Comment 20 Mattia Dongili 2010-03-10 21:08:56 UTC
(In reply to comment #17)
> (In reply to comment #15)
...
> > /* The set of possible wireless events */
> > static struct sonypi_event sonypi_wlessev[] = {
> >         { 0x59, SONYPI_EVENT_WIRELESS_ON },
> >         { 0x5a, SONYPI_EVENT_WIRELESS_OFF },
> >         { 0, 0 }
> > };
> > 
> > comment this out the reference to sonypi_wlessev at line 1882 as well. You
> > should get an additional interrupt and event printed out. Might be worth giving
> > it a go.
> This actually does the trick. With this modifications it works perfectly. I
> attatch commentet output in /var/log/messages again (sony-laptop debug=1).
...

(In reply to comment #19)
> ping mattia, any update? :)

yeah, well.... Aftert the latest comment from Thomas, the fix is quite obvious but I won't have time to submit a proper one until some time next week (hopefully earlier).

cheers
-- mattia
Comment 21 Zhang Rui 2010-03-11 07:56:39 UTC
great, thanks!
Comment 22 Zhang Rui 2010-03-25 06:02:12 UTC
hi, mattia,

is there a patch available? :p

thanks,
rui
Comment 23 Thomas Klose 2010-05-23 10:46:14 UTC
Are there any news on the issue?
Comment 24 Mattia Dongili 2010-05-24 13:52:06 UTC
Hi Thomas,
can you see if the attached patch works for you?
I believe the same issue may be reproducible on my SZ but it's quite some time I don't power it up, I'll see if I can find the time to upgrade it in the next days.

Thanks and apologies for the long silence...
Comment 25 Mattia Dongili 2010-05-24 13:53:33 UTC
Created attachment 26522 [details]
sony-laptop: let the minidriver handle the irq first
Comment 26 Thomas Klose 2010-05-25 21:25:54 UTC
Hi Mattia,

(In reply to comment #24)
> can you see if the attached patch works for you?

I successfully applied the patch to a current 2.6.32 kernel. Unfortunately it still does not work.

On the bright side: The iwl3954 device is now found and initialized, but for some reason the iwlwifi microcode is not loaded. Thus WLAN is still not available.

Please find attached the output in /var/log/messages while
1. loading sony-laptop with debug option
2. kill switch -> off
3. kill switch -> on
4. unloading sony-laptop
5. kill switch -> off

Please note the additional lines without sony-laptop (last part) 
"firmware: requesting iwlwifi..."

> I believe the same issue may be reproducible on my SZ but it's quite some time
> I don't power it up, I'll see if I can find the time to upgrade it in the next
> days.
Sounds good. However, its no problem to test here either.

Thanks! Thomas
Comment 27 Thomas Klose 2010-05-25 21:27:08 UTC
Created attachment 26542 [details]
 Commented /var/log/messages (sony-laptop: patched, debug=1)
Comment 28 Mattia Dongili 2010-06-01 11:23:19 UTC
sigh...
Ok, the only other thing that may have affected SPIC handling since 2.6.28 (and that I can think of) is this commit d1e0de92d6c706cc68627c884b2d58d3db707804:

diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index 4dee1a2..903fca3 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -2792,7 +2792,7 @@ static int sony_pic_add(struct acpi_device *device)
        /* request IRQ */
        list_for_each_entry_reverse(irq, &spic_dev.interrupts, list) {
                if (!request_irq(irq->irq.interrupts[0], sony_pic_irq,
-                                       IRQF_SHARED, "sony-laptop", &spic_dev)) {
+                                       IRQF_DISABLED, "sony-laptop", &spic_dev)) {
                        dprintk("IRQ: %d - triggering: %d - "
                                        "polarity: %d - shr: %d\n",
                                        irq->irq.interrupts[0],

Can you try to back it out? Otherwise I guess the only other last option left is to ignore the rfkill switch events (removing those lines of code as you did some time ago should have had this effect -- although I don't understand why you didn't get an unknown event warning in the logs... mind retrying?).

Thanks
Comment 29 Thomas Klose 2010-06-01 15:53:14 UTC
(In reply to comment #28)
> sigh...
> Ok, the only other thing that may have affected SPIC handling since 2.6.28 and
> that I can think of) is this commit d1e0de92d6c706cc68627c884b2d58d3db707804:
> 
> Can you try to back it out? 

I changed the argument in the already *patched* file to IRQF_SHARED: Nothing changes. The output in /var/log/messages is exactly the same as in "Commented /var/log/messages (sony-laptop: patched, debug=1)". 

I noted in the output that iwlwifi microcode is loaded, indeed if the kill switch is turned ON. This is not the case if the WLAN actually becomes active (without sony-laptop). This behavior is also present with unpached sony-laptop. Perhaps it is a lead?

> Otherwise I guess the only other last option left
> is to ignore the rfkill switch events (removing those lines of code as you did
> some time ago should have had this effect -- although I don't understand why
> you didn't get an unknown event warning in the logs... mind retrying?).

Could you please be more specific how I should proceed?

Thanks, Thomas
Comment 30 Mattia Dongili 2010-06-06 06:23:13 UTC
Ok, I think I was a but mislead (by myself...) on this issue. Two other attempts:
1. load sony-laptop with the option mask=0xffffdfff, this should ignore the wireless events.

2. apply the attached patch (you can unapply the one that I sent before). Really it should have the exact same effect as (1) except that it will also print if the event was ignored.

Thanks
Comment 31 Mattia Dongili 2010-06-06 06:24:48 UTC
Created attachment 26665 [details]
Ignore wireless events
Comment 32 Mattia Dongili 2010-06-06 08:20:06 UTC
Created attachment 26666 [details]
Ignore wireless events

apologies, the previous one is just plain broken
Comment 33 Thomas Klose 2010-06-07 17:00:18 UTC
Hi Mattia, good news:

(In reply to comment #30)
> Ok, I think I was a but mislead (by myself...) on this issue. Two other
> attempts:
> 1. load sony-laptop with the option mask=0xffffdfff, this should ignore the
> wireless events.

It works!
 
> 2. apply the attached patch (you can unapply the one that I sent before).
> Really it should have the exact same effect as (1) except that it will also
> print if the event was ignored.

The patch seems to solve the problem :)
Although, no additional outputs are generated. Its the same as in
"Commented /var/log/messages (sony-laptop: modified, debug=1)".

Is this solution automatically applied to the current 2.6.32 kernel (Ubuntu Lucid) or only to future versions? In the latter case I could file a bug report to Ubuntu Launchpad with your patch.

Thank you!

Regards, Thomas
Comment 34 Mattia Dongili 2010-06-08 12:44:14 UTC
Hi Thomas,
well #1 is available in any kernel, so you could add something like
  options sony-laptop mask=0xffffdfff
to /etc/modprobe.d/sony-laptop.conf and the option will be automatically applied every time sony-laptop is loaded.

for #2 it may be a bit of a problem. I have to try to recollect why the event was introduced in the first place (it has been there since forever). I don't think an rfkill switch makes much sense to be propagate to userspace (this is what is happening today and what is getting on the way of properly enabling wifi) but I'm not sure what the expectation is on the Linux side.
I'll follow up on this after a bit of discussing on some mailing list.

Cheers!
Comment 35 Thomas Klose 2010-06-08 13:11:21 UTC
(In reply to comment #34)
> Hi Thomas,
> well #1 is available in any kernel, so you could add something like
>   options sony-laptop mask=0xffffdfff
> to /etc/modprobe.d/sony-laptop.conf and the option will be automatically
> applied every time sony-laptop is loaded.
> 
> for #2 it may be a bit of a problem. I have to try to recollect why the event
> was introduced in the first place (it has been there since forever). I don't
> think an rfkill switch makes much sense to be propagate to userspace (this is
> what is happening today and what is getting on the way of properly enabling
> wifi) but I'm not sure what the expectation is on the Linux side.
> I'll follow up on this after a bit of discussing on some mailing list.

So I will file a bug report with a reference to this thread. So the Ubuntu developers can decide by themselves how to proceed with the Lucid kernel.

Thanks, Thomas
Comment 36 Florian Mickler 2011-03-29 00:35:09 UTC
A patch referencing this bug report has been merged in v2.6.38-9043-gc585015:

commit 4eeb50220a4efd8c33598a228d03aff203a7ad07
Author: Mattia Dongili <malattia@linux.it>
Date:   Sat Feb 19 11:52:27 2011 +0900

    sony-laptop: ignore hard switch rfkill events (SPIC)

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