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
After disabling rfkill switch, did you 'sudo ifconfig wlan0 up'? IIRC, the iwl3945 hardware cannot detect that event by itself.
Created attachment 25069 [details] Output in /var/log/messages
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.
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.
(In reply to comment #4) > It sounds to me like the problem you are experiencing is with sony-laptop. I agree.
re-assign to Mattia.
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
(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.
Created attachment 25318 [details] DSDT Table for Sony VAIO VGN-TX3HP
Created attachment 25319 [details] DSDT Table for Sony VAIO VGN-TX5MN
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
(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
Created attachment 25323 [details] Commented /var/log/messages (sony-laptop: debug=1)
Created attachment 25324 [details] Output of dmesg
(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
sorry, line numbers from my previous comment are a bit off in 2.6.32, just search the variable in the code. -- mattia
(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
Created attachment 25353 [details] Commented /var/log/messages (sony-laptop: modified, debug=1)
ping mattia, any update? :)
(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
great, thanks!
hi, mattia, is there a patch available? :p thanks, rui
Are there any news on the issue?
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...
Created attachment 26522 [details] sony-laptop: let the minidriver handle the irq first
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
Created attachment 26542 [details] Commented /var/log/messages (sony-laptop: patched, debug=1)
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
(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
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
Created attachment 26665 [details] Ignore wireless events
Created attachment 26666 [details] Ignore wireless events apologies, the previous one is just plain broken
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
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!
(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
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)