Fn+F2 key does not work on my latop which should turn on the WiFi. It seems it's a regression sinece it worked in 2.6.23 or so in my impression.
Created attachment 18128 [details] lost wireless network after press Fn+F2, but the LED is still on. The attachment is the whole dmesg, hope it could help the work. I found a "strange" phenomenon that after I press Fn+F2 key, I will lost my wireless cennection.But the LED is still on, there will be a message pop up in dmesg: "wlan0: No ProbeResp from current AP 00:1d:0f:66:fb:02 - assume out of range" Only if I boot into Windows to press Fn+F2 one more time to turn it on, my linux could cennected to wlan. Wish I have provide enough info.
please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the Fn+f2 key to see if there is an increase of some specific GPEs. please attach the acpidump output as well.
Created attachment 18162 [details] acpidump output Here is the command output: grissiom@gri:~$ grep . /sys/firmware/acpi/interrupts/* /sys/firmware/acpi/interrupts/error: 0 /sys/firmware/acpi/interrupts/ff_gbl_lock: 0 enable /sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid /sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enable /sys/firmware/acpi/interrupts/ff_rt_clk: 0 invalid /sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid /sys/firmware/acpi/interrupts/gpe00: 0 invalid /sys/firmware/acpi/interrupts/gpe01: 0 enable /sys/firmware/acpi/interrupts/gpe02: 0 invalid /sys/firmware/acpi/interrupts/gpe03: 0 enable /sys/firmware/acpi/interrupts/gpe04: 0 invalid /sys/firmware/acpi/interrupts/gpe05: 0 invalid /sys/firmware/acpi/interrupts/gpe06: 0 invalid /sys/firmware/acpi/interrupts/gpe07: 0 invalid /sys/firmware/acpi/interrupts/gpe08: 0 invalid /sys/firmware/acpi/interrupts/gpe09: 0 invalid /sys/firmware/acpi/interrupts/gpe0A: 0 invalid /sys/firmware/acpi/interrupts/gpe0B: 0 invalid /sys/firmware/acpi/interrupts/gpe0C: 0 invalid /sys/firmware/acpi/interrupts/gpe0D: 0 invalid /sys/firmware/acpi/interrupts/gpe0E: 0 invalid /sys/firmware/acpi/interrupts/gpe0F: 0 invalid /sys/firmware/acpi/interrupts/gpe10: 0 invalid /sys/firmware/acpi/interrupts/gpe11: 0 invalid /sys/firmware/acpi/interrupts/gpe12: 0 invalid /sys/firmware/acpi/interrupts/gpe13: 0 invalid /sys/firmware/acpi/interrupts/gpe14: 113 enable /sys/firmware/acpi/interrupts/gpe15: 0 enable /sys/firmware/acpi/interrupts/gpe16: 0 invalid /sys/firmware/acpi/interrupts/gpe17: 0 invalid /sys/firmware/acpi/interrupts/gpe18: 0 invalid /sys/firmware/acpi/interrupts/gpe19: 0 invalid /sys/firmware/acpi/interrupts/gpe1A: 0 invalid /sys/firmware/acpi/interrupts/gpe1B: 0 enable /sys/firmware/acpi/interrupts/gpe1C: 0 invalid /sys/firmware/acpi/interrupts/gpe1D: 0 invalid /sys/firmware/acpi/interrupts/gpe1E: 0 invalid /sys/firmware/acpi/interrupts/gpe1F: 1 enable /sys/firmware/acpi/interrupts/gpe_all: 114 /sys/firmware/acpi/interrupts/sci: 114 (press Fn+F2 key here)grissiom@gri:~$ grep . /sys/firmware/acpi/interrupts/* /sys/firmware/acpi/interrupts/error: 0 /sys/firmware/acpi/interrupts/ff_gbl_lock: 0 enable /sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid /sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enable /sys/firmware/acpi/interrupts/ff_rt_clk: 0 invalid /sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid /sys/firmware/acpi/interrupts/gpe00: 0 invalid /sys/firmware/acpi/interrupts/gpe01: 0 enable /sys/firmware/acpi/interrupts/gpe02: 0 invalid /sys/firmware/acpi/interrupts/gpe03: 0 enable /sys/firmware/acpi/interrupts/gpe04: 0 invalid /sys/firmware/acpi/interrupts/gpe05: 0 invalid /sys/firmware/acpi/interrupts/gpe06: 0 invalid /sys/firmware/acpi/interrupts/gpe07: 0 invalid /sys/firmware/acpi/interrupts/gpe08: 0 invalid /sys/firmware/acpi/interrupts/gpe09: 0 invalid /sys/firmware/acpi/interrupts/gpe0A: 0 invalid /sys/firmware/acpi/interrupts/gpe0B: 0 invalid /sys/firmware/acpi/interrupts/gpe0C: 0 invalid /sys/firmware/acpi/interrupts/gpe0D: 0 invalid /sys/firmware/acpi/interrupts/gpe0E: 0 invalid /sys/firmware/acpi/interrupts/gpe0F: 0 invalid /sys/firmware/acpi/interrupts/gpe10: 0 invalid /sys/firmware/acpi/interrupts/gpe11: 0 invalid /sys/firmware/acpi/interrupts/gpe12: 0 invalid /sys/firmware/acpi/interrupts/gpe13: 0 invalid /sys/firmware/acpi/interrupts/gpe14: 116 enable /sys/firmware/acpi/interrupts/gpe15: 0 enable /sys/firmware/acpi/interrupts/gpe16: 0 invalid /sys/firmware/acpi/interrupts/gpe17: 0 invalid /sys/firmware/acpi/interrupts/gpe18: 0 invalid /sys/firmware/acpi/interrupts/gpe19: 0 invalid /sys/firmware/acpi/interrupts/gpe1A: 0 invalid /sys/firmware/acpi/interrupts/gpe1B: 0 enable /sys/firmware/acpi/interrupts/gpe1C: 0 invalid /sys/firmware/acpi/interrupts/gpe1D: 0 invalid /sys/firmware/acpi/interrupts/gpe1E: 0 invalid /sys/firmware/acpi/interrupts/gpe1F: 1 enable /sys/firmware/acpi/interrupts/gpe_all: 117 /sys/firmware/acpi/interrupts/sci: 117 the gpe14 increased 3 after press the key.
what if reverting the commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a? i.e. revert this patch, diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 0924992..5622aee 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -194,7 +194,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum ec_event event, int force_poll) while (time_before(jiffies, delay)) { if (acpi_ec_check_status(ec, event)) return 0; - udelay(ACPI_EC_UDELAY); + msleep(1); } } pr_err(PREFIX "acpi_ec_wait timeout, status = 0x%2.2x, event = %s\n",
Sorry, problem still not fixed.
Will you please enable the debug function in drivers/acpi/ec.c on the latest kernel(2.6.27-rc9)?( uncomment the next line is OK /* #define DEBUG */) After pressing Fn+F2 the hotkey, please attach the output of dmesg. thanks.
It will be great if you can attach the output of lspci -vvvxxx. Thanks
Created attachment 18208 [details] lspci-vvvxxx output this is the lspci-vvvxxx output. Wish it could be helpful.
Created attachment 18209 [details] dmesg of the kernel enabled DEBUG in ec I presses the Fn+F2 key on about time 273, i.e, the last section of the full dmesg would be the consequence of my key pressing. Hope it could be helpful.
Please identify the latest release where this worked properly. If you can git bisect, that would be ideal. The quick way would be to limit git bisect to drivers/acpi/ec.c
(In reply to comment #10) > Please identify the latest release where this worked properly. > If you can git bisect, that would be ideal. > The quick way would be to limit git bisect to drivers/acpi/ec.c > Hmm, I know little about git. I just use it to keep track with Linus' tree without download-apply so many patches. Hmm, maybe I would learn how to use it in a professional way but I do not have so much time now.
Hi, Gu Rui From the log in comment #9 it seems that the _Qxx method will be executed when pressing the Fn+F2 key(Maybe it is the _Q93 object). And in the _Qxx object the SMI operation will be called. Maybe the WLAN will be turned off. Will you please confirm whether the WLAN will be turned off if pressing the Fn+F2 key on windows? thanks.
(In reply to comment #12) > Hi, Gu Rui > From the log in comment #9 it seems that the _Qxx method will be executed > when pressing the Fn+F2 key(Maybe it is the _Q93 object). And in the _Qxx > object the SMI operation will be called. Maybe the WLAN will be turned off. > > Will you please confirm whether the WLAN will be turned off if pressing > the > Fn+F2 key on windows? > thanks. > Yes, it works well on windows. When I boot the system into Single mode and press the keys, I got: atkbd.c: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0). atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known. in dmesg. But the wireless card is still not activated, at least the led is still off. Wish it could help.
Fn + F2 still does not working in 2.6.28-rc7. Even with rfkill enabled.
In order to get the key work, we should make sure: 1. who can get the notification when hotkey is pressed. (both i8042 controller and ACPI EC device in this case). 2. who can turn on/off the WiFi led. I asked a wireless expert, and this is his answer: 1. usually, it's ACPI that can catch the hotkey press event. And it should trigger an interrupt of the wireless device, which is probably done by the SMI call. 2. this depends. there are some platform specific ways to turn off the wifi led, or the wireless driver may control the led in some case. Anyway, from the symptom described in comment #2, this seems like a wireless driver problem, which doesn't disable the hardware correctly. But we should make sure the ACPI notification is always sent correctly when the hotkey is pressed. In order to know which _Qxx method is evaluated, please apply the patch attach below, enable EC debug option, and rebuild the kernel. Then press the Fn+F2 hotkey for three times, and attach the dmesg output.
Created attachment 19203 [details] patch: debug ec query methods yakui, I think we should also send this patch to Alexey, which is an improvement of EC debug information, what do you think?
Created attachment 19204 [details] dmesg after enabling debug in ec and applying patch in Comment #16 I pressed the keys after "[ 114.000873] Clocksource tsc unstable (delta = -122172970 ns)" shown. Thanks.
everytime when fn+f2 hotkey is pressed, ACPI EC driver gets an notification and evaluates the _Q93 method, which trigger a SMI. I don't think there is anything that we can debug more. This should be a wireless driver issue, which doesn't disable the device correctly.
In recently daily use, I can identify that fn+f2 key does disable the _card_. Because pressing fn+f2 key I could find wireless networks and one more pressing I could not see any wireless network. But the LED is always on despite the stat of the wireless card. So I think now the problem is restricted to a LED problem.
What wireless driver is in use here?
The driver is b43. It's shown in dmesg.
Created attachment 19526 [details] new dmesg After I update my kernel to 2.6.28-git2, I reconfigured the kernel with more proper settings.So we can see that the hardware is enabled/disabled when key pressed. But the LED is still unaware of the stat of the hardware. I have tried configurations with all CONFIG_LEDS* on/off, problem still remain.
Hi guys, The LED is perfectly synchronized with the status of the hardware with certain configurations. I don't which configuration turn the feature on but it works now on 2.6.28. So I mark this entry as unreproducible. Thanks for caring this issue ;)