Bug 43007
|
Description
Andras Korn
2012-03-28 18:22:06 UTC
(I run an amd64 kernel; I just assume the issue manifests on i386 as well.) Could you please attach the output of `rfkill list` and `dmesg`? Thanks a lot Created attachment 72749 [details]
output of rfkill list with lobotomised acer-wmi fix
Bluetooth is really soft blocked (I turned it off in Gnome).
acer-wireless is likely a phantom device.
phy0 is what ends up bogus "hard blocked" if I don't lobotomise the patch.
Created attachment 72750 [details]
dmesg with 3.2.0-1-grml-amd64 kernel
This kernel doesn't have the acer-wmi fix yet. Wifi works with it.
Created attachment 72751 [details]
dmesg with 3.3, lobotomised acer-wmi fix
Wifi works with this kernel after acer-wmi is loaded.
I'll collect rfkill list and dmesg output from non-working setups later today. Created attachment 72763 [details]
rfkill with 3.3 vanilla
This is what happens with the 3.3 "fixed" acer-wmi module.
In the last experiment, I load my lobotomised acer-wmi module instead of the vanilla one into the same kernel, and wifi immediately starts working.
I suppose the exception list needs to be made more specific somehow...?
For the sake of clarity, this is how I modified the acer-wmi module in 3.3 to make it work:
--- 3.3/drivers/platform/x86/acer-wmi.c 2012-03-19 00:15:34.000000000 +0100
+++ 3.3/drivers/platform/x86/acer-wmi.c.mine 2012-03-30 16:11:05.037741000 +0200
@@ -689,9 +689,6 @@
}
static const struct acpi_device_id norfkill_ids[] = {
- { "VPC2004", 0},
- { "IBM0068", 0},
- { "LEN0068", 0},
{ "", 0},
};
The attachment in comment #7 is interested. Looks like register acer-wireless rfkill unblock phy0's hard block. Can you help with two test? 1) With 3.3 vanilla kernel, please try to switch the physical wireless switch and see how `rfkill list` output change. 2) With 3.2 based kernel, please try to blacklist acer-wmi and see if the wireless works or not. Thanks a lot. (In reply to comment #9) > 1) With 3.3 vanilla kernel, please try to switch the physical wireless switch > and see how `rfkill list` output change. It lists bluetooth as hard blocked, otherwise no change. > 2) With 3.2 based kernel, please try to blacklist acer-wmi and see if the > wireless works or not. I think it doesn't, but I'll try. Hi, lets fall back to the traditional way.
Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel:
sudo watch -n 1 perl acer_ec.pl regs
and push the Fn+F5 several times, try to find out which register tells us the *real* rfkill status.
[1] http://code.google.com/p/aceracpi/wiki/EmbeddedController
and please let me know the output of `cat /sys/class/dmi/id/board_vendor` and `cat /sys/class/dmi/id/product_name`
I will try to have an exception.
Thanks a lot.
(In reply to comment #11) Hi, > Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel: > > sudo watch -n 1 perl acer_ec.pl regs > > and push the Fn+F5 several times, try to find out which register tells us the > *real* rfkill status. I'll do this. Meanwhile, I'm attaching the results of the experiment with 3.0.2. Summary: wifi doesn't work (appears hard blocked) until acer-wmi is loaded. After loading acer-wmi, both the hard and soft switches appear to function properly. > and please let me know the output of `cat /sys/class/dmi/id/board_vendor` and > `cat /sys/class/dmi/id/product_name` /sys/class/dmi/id/bios_date:05/23/2011 /sys/class/dmi/id/bios_vendor:LENOVO /sys/class/dmi/id/bios_version:4BCN21WW /sys/class/dmi/id/board_asset_tag:Base Board Asset Tag Unknown /sys/class/dmi/id/board_name:Inagua /sys/class/dmi/id/board_serial:<redacted> /sys/class/dmi/id/board_vendor:LENOVO /sys/class/dmi/id/board_version:109-B78210-00A /sys/class/dmi/id/chassis_asset_tag:Chassis Asset Tag Unknown /sys/class/dmi/id/chassis_serial:Chassis Serial Number Unknown /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:LENOVO /sys/class/dmi/id/chassis_version:Chassis Version Unknown /sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvr4BCN21WW:bd05/23/2011:svnLENOVO:pn1038D3G:pvrIdeapadS205:rvnLENOVO:rnInagua:rvr109-B7821 -00A:cvnLENOVO:ct10:cvrChassisVersionUnknown: /sys/class/dmi/id/product_name:1038D3G /sys/class/dmi/id/product_serial:<redacted> /sys/class/dmi/id/product_uuid:B4B9ACE0-B2F1-11E0-AD9F-F2204BB03A53 /sys/class/dmi/id/product_version:Ideapad S205 /sys/class/dmi/id/sys_vendor:LENOVO /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvr4BCN21WW:bd05/23/2011:svnLENOVO:pn1038D3G:pvrIdeapadS205:rvnLENOVO:rnInagua:rvr10 -B78210-00A:cvnLENOVO:ct10:cvrChassisVersionUnknown: Created attachment 72952 [details]
Effects of blacklisting acer-wmi in 3.0.2, soft and hard switches, then loading acer-wmi and toggling switches again.
It appears that ec_read() also trigger something in ec firmware to unblock. Please test with acer_ec.pl and in the mean time, I will generate the patch. (In reply to comment #11) > Hi, lets fall back to the traditional way. > > Please download the acer_ec.pl[1] and run command with 3.3 vanilla kernel: > > sudo watch -n 1 perl acer_ec.pl regs > > and push the Fn+F5 several times, try to find out which register tells us the > *real* rfkill status. I ran "watch -d -n 1 acer_ec.pl regs \; rfkill list" and this is what I found: When wireless in unblocked, register 0x71's value is 131. When I press fn+f5, the value changes to 130. Additionally, first phy0's "soft blocked" changes from "no" to "yes", then 2-3 seconds later "hard blocked" also changes from "no" to "yes". Pressing fn+f5 again causes register 0x71 to revert to 131; "soft blocked" immediately changes to "no", and a few seconds later "hard blocked" also changes to "no". Unfortunately, there are quite a few registers that keep changing frequently, which makes determining which ones change due to fn+f5 difficult. Frequently changing registers are 0x72, 0x83, 0x8b, 0x94, 0x95, 0xa8, 0xa9 0xaa, 0xb8, 0xe0, 0xe4, 0xe6, 0xe8, 0xec, 0xed, possibly others. The "soft blocked" state of "acer-wireless" sometimes changes seemingly at random (apparently it changes from "yes" to "no" once every few minutes, and then changes back to "yes" 1-2 seconds later). With some further experimentation and scripting I came up with this: Register 113 when soft blocked: no is 131 Register 113 when soft blocked: yes is 130 Register 149 when hard blocked: no is 132 Register 149 when hard blocked: yes is 127 Register 149 when hard blocked: yes is 128 Register 149 when hard blocked: yes is 130 Register 149 when soft blocked: no is 130 Register 149 when soft blocked: no is 132 Register 149 when soft blocked: yes is 127 Register 149 when soft blocked: yes is 128 Register 168 when hard blocked: no is 59 Register 168 when hard blocked: yes is 60 Register 224 when hard blocked: no is 54 Register 224 when hard blocked: no is 57 Register 224 when hard blocked: yes is 58 Register 224 when hard blocked: yes is 59 Register 224 when hard blocked: yes is 61 Register 224 when hard blocked: yes is 63 Register 224 when hard blocked: yes is 71 Register 224 when soft blocked: no is 54 Register 224 when soft blocked: no is 58 Register 224 when soft blocked: no is 61 Register 224 when soft blocked: no is 71 Register 224 when soft blocked: yes is 57 Register 224 when soft blocked: yes is 59 Register 224 when soft blocked: yes is 63 Register 230 when hard blocked: no is 117 Register 230 when hard blocked: no is 125 Register 230 when hard blocked: yes is 102 Register 230 when hard blocked: yes is 104 Register 230 when hard blocked: yes is 106 Register 230 when hard blocked: yes is 108 Register 230 when hard blocked: yes is 113 Register 230 when soft blocked: no is 102 Register 230 when soft blocked: no is 106 Register 230 when soft blocked: no is 113 Register 230 when soft blocked: no is 125 Register 230 when soft blocked: yes is 104 Register 230 when soft blocked: yes is 108 Register 230 when soft blocked: yes is 117 Register 232 when hard blocked: no is 247 Register 232 when hard blocked: yes is 228 Register 232 when hard blocked: yes is 24 Register 232 when hard blocked: yes is 245 Register 232 when hard blocked: yes is 30 Register 232 when soft blocked: no is 24 Register 232 when soft blocked: no is 245 Register 232 when soft blocked: no is 247 Register 232 when soft blocked: no is 30 Register 232 when soft blocked: yes is 228 Register 232 when soft blocked: yes is 29 Register 236 when hard blocked: no is 119 Register 236 when hard blocked: no is 91 Register 236 when hard blocked: yes is 104 Register 236 when hard blocked: yes is 136 Register 236 when hard blocked: yes is 139 Register 236 when hard blocked: yes is 142 Register 236 when hard blocked: yes is 87 Register 236 when soft blocked: no is 119 Register 236 when soft blocked: no is 136 Register 236 when soft blocked: no is 139 Register 236 when soft blocked: no is 87 Register 236 when soft blocked: yes is 104 Register 236 when soft blocked: yes is 142 Register 236 when soft blocked: yes is 91 Explanation: I wrote a script that recorded the value of all registers along with the state of the hard and soft blocking state of phy0. I toggled the blocks a few times, logging the register values. I then removed values that occurred in both blocked and unblocked states (because these apparently can't be used to differentiate between blocked and unblocked states). Finally, I removed values where a register now only had a single recorded value (i.e. there was a specific value that only occurred in the blocked or unblocked state, but no specific value that only occurred in the other state). There was an anomaly with register 148 in that an empty value was recorded for it at least once, I don't know why. Its only remaining entry in the above list would read "Register 148 when hard blocked: yes is 127" (apparently this value did not occur with "hard blocked: no"). I hope this helps. Created attachment 72963 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-Brazos-wifi-sw.patch
Does this patch in 3.4-rc1 works to you?
Created attachment 72970 [details]
for ideapad s205 (Inagua)
Hi Joey,
There are many SKUs all named ideapad s205. I believe this is not the one we heard.
I revised the patch and we need Andras to verify which one works, or neither.
(I will do that, but it takes time, sorry.) (Progress: currently building 3.4-rc4 with Ike's patch. Will keep you posted.) I tried both patches. Neither helped (rfkill listed phy0 as hard blocked with both). I was the one that posted on launchpad https://bugs.launchpad.net/ubuntu/+source/linux/+bug/875659/comments/85 and was directed here. A thing that I'm still confused about is why the focus is on fn+f5. My S205 has two ways to control the wireless: a switch on the side, which supposedly would be the real hard killswitch, and only works for bluetooth -- but it does work (the hard block is toggled), and the fn+f5 which also correctly toggles the wlan soft block. Both of these things I can see working with rfkill list. Ok, as for the testing. I performed it using the latest mainline kernel from the kernel-ppa, 3.4-rc5-precise. I looked at the output of acer_ec.pl while toggling fn+f5 and had no luck at all. There are some registers which change spuriously, but there is no register which clearly changes between two states when pressing the combo. With the switch on the side, I had more luck: both 0x52 and 0x78 clearly change between toggles, 0 for "killswitch on (wifi off)", 1 for "killswitch off". I forgot to include:
bios_date:08/10/2011
bios_vendor:LENOVO
bios_version:4BCN24WW
board_name:Inagua
board_vendor:LENOVO
board_version:109-B78210-00A
chassis_type:10
chassis_vendor:LENOVO
product_name:10382JG
product_version:Ideapad S205
sys_vendor:LENOVO
Andra's machine still seems to be using an older BIOS, but mine is not the "normal" 4BCN24WW bios, I had to replace it with a hacked version that removed the wireless card whitelist, so I could switch the internal card to an Intel Centrino Ultimate-N 6300.
Also I was checking rfkill with kernel 3.0, and the side killswitch correctly controls both the bluetooth and wifi hard blocks (and works correctly). This is after loading and rmmoding acer_wmi. With acer_wmi loaded I have another entry in the rfkill list, which seems to always be in this state:
4: acer-wireless: Wireless LAN
Soft blocked: yes
Hard blocked: no
@Andras Sorry for late. Could you try a patch please? Obviously I do not know how to attach a patch. So I put it at http://people.canonical.com/~ikepanhc/lp/bugzilla.kernel/43007/ Created attachment 73911 [details]
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
Created attachment 73921 [details]
Patch by Ike Panhc to read EC register 0xA on Ideapad 10382JG during initialisation
(In reply to comment #24) > @Andras > > Sorry for late. Could you try a patch please? Yes, thank you, will do (but will take some days). I attached the patch for you. :) (In reply to comment #25) > Obviously I do not know how to attach a patch. > > So I put it at > http://people.canonical.com/~ikepanhc/lp/bugzilla.kernel/43007/ Sorry, this patch doesn't help either. I applied it to 3.4.4; my phy0 is still "hard blocked". My earlier workaround (mucking with acpi_device_id norfkill_ids) still resolves the problem for me (but would likey break wifi for others). Same here, I applied the patch to ubuntu's 3.2 kernel tree, and the issue is still present. Are there any news? Is there some more testing that can be done? Thanks. Hi Ivo, Obviously the 0xA EC register not work on your machine, we need try to grab which EC register works with you. Please run this acer_ec.pl from Carlos: http://code.google.com/p/aceracpi/wiki/EmbeddedController http://aceracpi.googlecode.com/svn/trunk/acer_ec/acer_ec.pl Simple use: watch -n 1 perl acer_ec.pl regs Then press your wireless Fn key to monitor which register changed when you press Fn key: e.g. the register at row B0 and column 0A is register 0xBA (0x is used to indicate this is a hexadecimal number). There maybe have other EC register changing when you press key, please do a couple of times and make sure you find out the right one. If we are lucky, we can find out one EC register mapping to your wireless state. (In reply to comment #32) > Hi Ivo, > > Obviously the 0xA EC register not work on your machine, we need try to grab > which EC register works with you. > > Please run this acer_ec.pl from Carlos: > http://code.google.com/p/aceracpi/wiki/EmbeddedController > http://aceracpi.googlecode.com/svn/trunk/acer_ec/acer_ec.pl > > Simple use: > watch -n 1 perl acer_ec.pl regs > > Then press your wireless Fn key to monitor which register changed when > you press Fn key: > > e.g. the register at row B0 and column 0A is register 0xBA (0x is used > to indicate this is a hexadecimal number). > > There maybe have other EC register changing when you press key, please > do a couple of times and make sure you find out the right one. > > If we are lucky, we can find out one EC register mapping to your > wireless state. As I've said before: I don't understand the focus on the fn key. The fn key works fine, it triggers the soft block, and it works (and I can't see it with acer_ec.pl). The issue is that current kernels ignore the hard killswitch key, which is on the side of the laptop, and read it as being always OFF. For the side hard killswitch key, the EC registers 0x52 and 0x78 change whenever I toggle it, 0 for "killswitch on (wifi off)", 1 for "killswitch off". (In reply to comment #33) > (In reply to comment #32) ... > > As I've said before: I don't understand the focus on the fn key. The fn key > works fine, it triggers the soft block, and it works (and I can't see it with > acer_ec.pl). The issue is that current kernels ignore the hard killswitch > key, > which is on the side of the laptop, and read it as being always OFF. > > For the side hard killswitch key, the EC registers 0x52 and 0x78 change > whenever I toggle it, 0 for "killswitch on (wifi off)", 1 for "killswitch > off". Hi Ivo, Thanks for your information. Due to there have 2 EC registers changed when you toggle the hardware switch. Please also help to attach the acpidump and dmidecode, I want to check the OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this machine. Thanks a lot! Created attachment 78591 [details]
acpidump output
Created attachment 78601 [details]
dmidecode output
(In reply to comment #34) > Hi Ivo, > > Thanks for your information. > > Due to there have 2 EC registers changed when you toggle the hardware switch. > Please also help to attach the acpidump and dmidecode, I want to check the > OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this > machine. > > Thanks a lot! I've just attached my acpidump and dmidecode. I don't believe it makes a difference, but I'm using a bios hacked to remove the wifi card whitelist. Thanks a lot for looking into this (I'm still stuck on 3.0 so I can still have wifi, but I have problems with usb and microphone that supposedly are fixed in newer kernel versions). (In reply to comment #37) > (In reply to comment #34) > > Hi Ivo, > > > > Thanks for your information. > > > > Due to there have 2 EC registers changed when you toggle the hardware > switch. > > Please also help to attach the acpidump and dmidecode, I want to check the > > OperationRegion of EmbeddedControl. And, the dmidecode is for indicate this > > machine. > > > > Thanks a lot! > > I've just attached my acpidump and dmidecode. I don't believe it makes a > difference, but I'm using a bios hacked to remove the wifi card whitelist. > Thanks for your DSDT, I checked the region of embedded controller, there have 0x72 register that included BTEN and WLEN reflect to the RF status of wireless and bluetooth. The _Q2B method access WLEN and BTEN, this method should called by Fn+F? key. But, I didn't see 0x78 register marked on region of embedded controller. > Thanks a lot for looking into this (I'm still stuck on 3.0 so I can still > have > wifi, but I have problems with usb and microphone that supposedly are fixed > in > newer kernel versions). Let's focus on hardware switch (hard block of killswitch) first, please try the following acer-wmi patch for add your machine to type 3 quirk. Created attachment 78621 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-10382JG-wifi-sw.patch
acer-wmi: support Lenovo ideapad S205 10382JG wifi switch
This patch is for v3.2 kernel, I will port to newest kernel after tested.
(In reply to comment #39) > Created an attachment (id=78621) [details] > 0001-acer-wmi-support-Lenovo-ideapad-S205-10382JG-wifi-sw.patch > > acer-wmi: support Lenovo ideapad S205 10382JG wifi switch > > This patch is for v3.2 kernel, I will port to newest kernel after tested. I've applied the patch on top of Ubuntu's 3.2 kernel tree (3.2.0-30-generic), and it works nicely. I get three entries on rfkill list: 0: ideapad_bluetooth: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 2: acer-wireless: Wireless LAN Soft blocked: no Hard blocked: no and both the side hardkill button and fn+f5 work correctly! Thanks a lot! I can finally run a more recent kernel! Great! I just sent out patch to upstream for review: [PATCH] acer-wmi: support Lenovo ideapad S205 10382JG wifi switch Can you add the Lenovo S205-1038DPG to the list of quirks please? It also uses the 0x78 register that the s205 quirk checks for it's hardware wifi switch. I verified this by modifying my acer-wmi.ko file and changing the string that currently refers to the 10382JG and changed it to say 1038DPG before rebooting. With that modification the quirk kicked in, and the hardware wifi switch is correctly reported. (In reply to comment #42) > Can you add the Lenovo S205-1038DPG to the list of quirks please? It also > uses > the 0x78 register that the s205 quirk checks for it's hardware wifi switch. > > I verified this by modifying my acer-wmi.ko file and changing the string that > currently refers to the 10382JG and changed it to say 1038DPG before > rebooting. > With that modification the quirk kicked in, and the hardware wifi switch is > correctly reported. Thanks for your report, I sent patch to platform mail for review and waiting merge. Thanks Created attachment 84411 [details]
0001-acer-wmi-support-Lenovo-ideapad-S205-1038DPG-wifi-s.patch
Sent to upstream for review
It seems that none of the patches (10382JG/1038DPG) has been accepted upstream... Is there anything else we can do to help speed it up? FWIW, the issue is still present in 3.7.6, and the same lobotomy in acer-wmi.c still "fixes" it for me. A patch referencing this bug report has been merged in Linux v3.9-rc1: commit e6c33f1fe797355f1aed53b01230bd13ef52deff Author: Lee, Chun-Yi <joeyli.kernel@gmail.com> Date: Fri Dec 14 16:14:25 2012 +0800 acer-wmi: support Lenovo ideapad S205 10382JG wifi switch A patch referencing this bug report has been merged in Linux v3.9-rc1: commit 5f3511d2a61e7874730d3ccc1a32d418259133be Author: Lee, Chun-Yi <joeyli.kernel@gmail.com> Date: Fri Dec 14 16:14:28 2012 +0800 acer-wmi: support Lenovo ideapad S205 1038DPG wifi switch Issue still present in 3.10.5. Also, emptying static const struct acpi_device_id norfkill_ids[] in acer-wmi.c still mostly "fixes" the problem in 3.10.5. Strangely, the phantom rfkill is still re-engaged after a suspend-resume cycle, but toggling the two hardware switches(*) seems to help (maybe only one of the two needs to be toggled, I don't know yet). (*) fn-f5 (soft lock) and the small switch on the side of the netbook (hard lock). |