login
Search
Hello, 2.6.25-rc2-git7 has regression, thinkpad keys do not work any more. Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a -- Lukáš Hejtmánek --
Hi, Please always provide the commit subject along with the hash in bug reports. Also, CCing the author and the relevant list on a report usually is a good idea. :-) Thanks, Rafael --
This commit is indeed broken, and I have a tentative fix for it. But I'd like to have a better description of just "how" the thinkpad keys do not work anymore, to make sure I fix the entire breakage in one go. I will stare at the code and the fix a bit more before sending in any patches, Make it "mandatory" if you want a fast reply :^) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
Well, keys generate ACPI interrupt but acpid never receives any event. I would be happy to test fixes to see whether things go well. -- Lukáš Hejtmánek --
Not even over the new netlink socket? Or the thinkpad-acpi input device? Sure, try this one: diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index 7500c44..0f74351 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -1078,7 +1078,8 @@ static int hotkey_get_tablet_mode(int *status) if (!acpi_evalf(hkey_handle, &s, "MHKG", "d")) return -EIO; - return ((s & TP_HOTKEY_TABLET_MASK) != 0); + *status = ((s & TP_HOTKEY_TABLET_MASK) != 0); + return 0; } /* -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
how can I check this? volume keys work. But anything through acpid does not. Even AC/battery switch [ 247.170385] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 247.170398] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 247.170402] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 247.170407] thinkpad_acpi: Lenovo ThinkPad T61 [ 247.171289] thinkpad_acpi: radio switch found; radios are enabled [ 247.184889] thinkpad_acpi: requested hot key mask 0xffffffff, but firmware forced it to 0x00ffffff [ 247.188509] thinkpad_acpi: detected a 16-level brightness capable ThinkPad [ 247.189027] input: ThinkPad Extra Buttons as /devices/virtual/input/input10 [ 418.790341] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \_SB.PCI0.LPC.EC for ec [ 418.793747] thinkpad_acpi: ibm_init: probing for driver [ 418.793758] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 418.793762] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 418.793766] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 418.793771] thinkpad_acpi: Lenovo ThinkPad T61 [ 418.793775] thinkpad_acpi: ibm_init: driver installed [ 418.793780] thinkpad_acpi: ibm_init: probing for hotkey [ 418.793827] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 428.258389] thinkpad_acpi: radio switch found; radios are enabled [ 428.258423] thinkpad_acpi: hotkey_init: using Lenovo default hot key map [ 428.258431] thinkpad_acpi: hotkey_init: enabling hot key handling [ 428.264778] thinkpad_acpi: hotkey_init: legacy hot key reporting over procfs enabled [ 418.806536] thinkpad_acpi: register_tpacpi_subdriver: registering hotkey as an ACPI driver [ 418.808594] thinkpad_acpi: ibm_init: hotkey installed [ 418.816087] thinkpad_acpi: requested hot key mask 0xffffffff, but firmware forced it to 0x00ffffff [ 418.816100] thinkpad_acpi: ibm_init: probing for bluetooth [ 418.816114] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 418.821862] thinkpad_acpi: ibm_init: ...
Yeah, there is an EC-related regression in 2.6.25-rc3 that bites your thinkpad. I don't have a link to it right now, but if you look for the Don't do this. Just let the driver select the default mask, unless you It wouldn't fix any EC issues. If you just revert the 6c231bd5eb07ce546517019f334652b9ecfc329a commit entirely (note, I don't mean revert TO THE COMMIT), by doing something like this: git checkout v2.6.25-rc3 git show 6c231bd5eb07ce546517019f334652b9ecfc329a | patch -p1 -R Does it fix anything ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
http://bugzilla.kernel.org/show_bug.cgi?id=10100 (easy to remember ;=)) Thanks, Rafael --
Greetings to all, I recently stumbled across a Dell OptiPlex 320 which brings a nasty assembly of hardware. Besides the many issues reported (system/bios time de-sync, SATA controller detection, etc), this particular model doesn't seem to correctly recognize the CPU, which I'm not even sure what it is (I haven't seen anyone else complaining about it). As far as I could investigate, it looks like a weird P4 1.8Ghz, dual core. However, /proc/cpuinfo only reports 1 processor, 1.8Ghz. I'm saying that it's a dual core because I've seen an identical machine running Windows, showing 2 CPUs. Besides, other tools report it as "dual core". Below is the output of /proc/cpuinfo and some head lines of dmesg. Here is the output of Todd Allen's cpuid tool (20060917): (multi-processing synth): hyper-threaded (t=2) (synth) = Intel Core 2 Duo (Conroe/Allendale) / Core 2 Extreme Processor (Conroe) / Dual-Core Xeon Processor 5100 (Woodcrest), 65nm I've tried OpenSuSE 10.3 default kernel, 2.6.22.5, the oSuSE last update, 2.6.22.17, and a custom-built 2.6.24.2, all 32bit. I just notice now that I could have tried downgrading... What I'm looking for is some guidance in how can I trace this for you and perhaps help you/me somehow. I've digged this mailing-list and lots of other sources, and no one seems to complain about this, which is odd... ------------------- /proc/cpuinfo -------------------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Genuine Intel(R) CPU 2160 @ 1.80GHz stepping : 2 cpu MHz : 1800.256 cache size : 1024 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3614.79 clflush size ...
On Wed, 2008-02-27 at 11:54 +0000, Nuno Tavares wrote: FYI, DELL often changes its hardware for the same model number. Xav --
Multi processor requires acpi, so your acpi=off will disable all but the first CPU. Is the system really so broken that you have to tell the kernel to disable everything? -- Len Sorensen --
this one fixes all my troubles with thinkpad hotkeys in rc3. OK, thanks. -- Lukáš Hejtmánek --
Ping - is anyone sending this upstream? Would be nice to have my x60 usable for -rc4 at least. -- Jens Axboe --
Please take a look at patches in #10100. Alex. --
Can you be more specific (eg if you want me to test any/all of them, let me know)? -- Jens Axboe --
Patch from comment #3 is in -mm at the moment, and has good chance to appear in linus tree. I am trying to invent something less crufty along the lines of comment #4, but not succeeded yet. --
Updating and doing what the bugzilla entry suggests, that is reverting the offending commit. That makes my brightness controls work, but the volume and mute keys still do not work. -- Jens Axboe --
Those are not an ACPI business in your thinkpad anymore. They go over the KDC, so we're out of the loop. That means the bug is fixed completely. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
KDC? Pressing the buttons used to indicate mute and volume level in kmix, now they don't. That is somewhat annoying. If there's a way to get that working, please let me know. -- Jens Axboe --
You shouldn't need to do anything other than teach userspace to respond to them, as they generate the proper KEY_* events. If you are giving the AML _OSI(Linux), at least... But maybe looking at the keyboard output in console mode, to make triple sure the events ARE being sent over the KDC as they should, would be in order? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
so, do I understand correctly that volume keys have been controlled by ACPI and seemed to work independently on SW and now (exactly since when?) are passed complety to the user space as key codes? -- Lukáš Hejtmánek --
Yes, since the first *61 model. And field-upgradeable firmware revisons have a say on how this thing works, since the entire KDC is software in a Lenovo ThinkPad (it is just a small part of the EC firmware, that comes with the BIOS upgrades). I have some long email sitting on my draft folders about how to restore full sanity to thinkpad mixer behaviour on Linux, but I have to cool down for a few days before I revise it and send it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
I'm also seeing regression on my thinkpad z60m where with git tree (tested again with 2 days old git) "thinkvantage" button stopped working (pressing it was previously seen by some userspace kde which run konsole). On 2.6.24 presses are seen. -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ --
well, on 2.6.25-rc4, some keys are not reported as input (xev does not see any key press), some keys are. Is this desired? Or all the keys (fn+f1-12 + volume + backlight + think vantage) should be reported as some input event and thus acpid makes no sense any more? -- Lukáš Hejtmánek --
xev has to get events from somewhere. That somewhere happens to be a buggy mess right now (X.org evdev device). Or it is getting it through some other middleware, like HAL, which can have its own problems. If you want to test thinkpad-acpi functionality, get HAL and X.org out of the way. The easiest way is to do it in single user mode. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
In my thinkpad z60m case. On 2.6.24 kernels pressing "thinkvantage" key is seen by acpid like this: Mar 13 08:27:48 tarm acpid: received event "ibm/hotkey HKEY 00000080 00001018" Mar 13 08:27:48 tarm acpid: notifying client 4071[126:126] Mar 13 08:27:48 tarm acpid: notifying client 4096[0:0] Mar 13 08:27:48 tarm acpid: notifying client 4230[0:0] Mar 13 08:27:48 tarm acpid: completed event "ibm/hotkey HKEY 00000080 00001018" (this log was done while X was running + some kde apps). Now under git kernel there is no such event. X has nothing to do with it since I tested without X running, too. -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ --
I got this event under 2.6.25-rc3-git1. However, I wonder why some keys are reported as key press through input device and some only for acpid. I thing, all the key should be reported in the same way... -- Lukáš Hejtmánek --
And lets now get back to reality - the reality that now breaks the previously working setup of lots of users. So you are telling me that in order to get my volume key functionality back I have to get rid of HAL and X? Lets turn back time a bit. Why was this change made? IOW, what was the reason for breaking a working setup for lots of users? It better be a damn good reason, or I would heavily argue for reverting this change so that 2.6.25 actually WORKS as expected for thinkpad users. -- Jens Axboe --
so, you are telling that xev does not show keycodes of volume buttons for you, right? Because for me, it works. Thinkvantage does not work. -- Lukáš Hejtmánek --
They do not generate any events, xev reports nothing. The ThinkVantage button doesn't generate any events either. -- Jens Axboe --
what about BIOS upgrade? I think this really should work. Ahh, maybe you are facing EC problems? Are you using just stock vanila kernel or some additional patches? -- Lukáš Hejtmánek --
It's stock -git as of this morning, with the 208c70a45624400fafd7511b96bc426bf01f8f5e commit reverted. And some other unrelated patches I'm working on, but nothing that has anything remotely to do with this. -- Jens Axboe --
I use the latest BIOS for my T61 and it just works. At least the event is generated either for acpid or for Xserver. -- Lukáš Hejtmánek --
This is an x60, so there may be other differences there. -- Jens Axboe --
There are was some playing with acpi_osi=Linux in this timeframe, known to deal with sound buttons too. Some of Thinkpads were inserted into the blacklist to need this OSI. It might be that your Thinkpad needs it too... Regards, Alex. --
Please talk to me like I'm an ACPI ignorant - because I am. Where is this blacklist? -- Jens Axboe --
drivers/acpi/blacklist.c:485. You probably could set acp_osi=Linux as kernel parameter to check if it helps. --
I booted with acpi_osi=Linux and it has made no difference. -- Jens Axboe --
What is the last kernel there these buttons work? --
It worked fine in 2.6.24, not sure when it broke in 2.6.25-rcX, but it was some time ago. I initially thought it was the same issue and would be fixed by the revert of 208c70a45624400fafd7511b96bc426bf01f8f5e, but that turned out not to be the case. -- Jens Axboe --
On a T61/X61 Thinkpad, anything but the very latest BIOS is too old. They have been modifying the BIOS in areas that are directly related to Linux EC problems anywhere in the entire ACPI subsystem can, and have, caused weird thinkpad-acpi issues. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
I am telling you to go single user mode to check if the problem is in thinkpad-acpi. Nothing more, nothing less. AFTER we find out where the What change? For all we know, it could be a bug. And if it is not a bug, read the thinkpad-acpi documentation, and complain to me exactly about whatever change described in there that is giving you issues. Or give me a bissect culprit. Or do the testing I asked you to do, and tell me the I will get pissed very fast, if you keep up with this tone. I certainly did not send in any changes that should cause what you describe on purpose, UNLESS you have disabled with the "deprecated" /proc/acpi/event stuff. In which case, it is your problem to get proper userspace. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
There were no changes to thinkpad-acpi that should have caused this. So I need more data to find out what is happening. Might be a problem elsewhere in ACPI, or some bug in thinkpad-acpi. You DO have /proc/acpi/event, correct? Please send me the debug output of thinkpad-acpi when it is loaded with "debug=0xffff" as a parameter (and for extra bonus, please compile it with the verbose debug Kconfig option). Also, send me the output of "grep . /sys/bus/platform/devices/thinkpad_acpi/*" -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
Yep, I do have /proc/acpi event. I'll build thinkpad-acpi modular and /sys/bus/platform/devices/thinkpad_acpi/bluetooth_enable:0 grep: /sys/bus/platform/devices/thinkpad_acpi/cmos_command: Permission denied /sys/bus/platform/devices/thinkpad_acpi/hotkey_all_mask:0x00ffffff /sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_enabled:0 /sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_mask:0x0000080c /sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1 /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008c7fff /sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1 /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008c7fff /sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1 /sys/bus/platform/devices/thinkpad_acpi/modalias:platform:thinkpad_acpi /sys/bus/platform/devices/thinkpad_acpi/uevent:DRIVER=thinkpad_acpi /sys/bus/platform/devices/thinkpad_acpi/uevent:PHYSDEVBUS=platform /sys/bus/platform/devices/thinkpad_acpi/uevent:PHYSDEVDRIVER=thinkpad_acpi /sys/bus/platform/devices/thinkpad_acpi/uevent:MODALIAS=platform:thinkpad_acpi /sys/bus/platform/devices/thinkpad_acpi/wakeup_hotunplug_complete:0 /sys/bus/platform/devices/thinkpad_acpi/wakeup_reason:0 -- Jens Axboe --
Updated to current kernel (saw it had a bunch of acpi fixes), and it now works correctly! xev sees the events and the mixer sees mute/unmute and volume up+down events. So I think we can lay this one to rest, thankfully. -- Jens Axboe --
Same here, recent git works fine on z60m. -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ --
A while ago I worked on a new acpi daemon that could receive events from both netlink and /dev/input devices. Right now it's more like a testing tool then a real replacement for the current acpid. I haven't had time to work on it. http://git.dbservice.com/?p=acpid;a=summary $ git clone git://dbservice.com/acpid You'll need dbus and lua to compile it. There's also a readme that describes how to get it running and how it works. In its default configuration it will print the events into stdout. tom --
I used the wrong return convention on hotkey_get_tablet_mode(), breaking a lot of stuff. Bad Henrique! Fix it to return the status in the parameter-by-reference, and IO status on the function return value. Duh. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Zdenek Kabelac <zdenek.kabelac@gmail.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz> --- drivers/misc/thinkpad_acpi.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index bb269d0..6cb7812 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -1078,7 +1078,8 @@ static int hotkey_get_tablet_mode(int *status) if (!acpi_evalf(hkey_handle, &s, "MHKG", "d")) return -EIO; - return ((s & TP_HOTKEY_TABLET_MASK) != 0); + *status = ((s & TP_HOTKEY_TABLET_MASK) != 0); + return 0; } /* -- 1.5.4.2 --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing List | ixbge: remove TX lock and redo TX accounting. |
| Linux Kernel Mailing List | ixgbe: fix several counter register errata |
| Lin |