You are not logged in.
Pages: 1
Does anybody know what's happened with ThinkPad LEDs control?
I used to use the interface:
/proc/acpi/ibm/led
to control LEDs, but now (just installed Archlinux on a T430) I see that only 2 LEDs work, trying to control others brings up "No such device" message.
The working LEDs are: 0 - the power button, 7 - the moon symbol.
Kernel: 3.12.9-2.
I remember them all working in Gentoo at 3.10.x kernels, but tried Arch's LTS kernel - still the same 2 LEDs only are available.
Thanks for ideas!
Last edited by aragats (2014-02-21 15:36:21)
Offline
I cannot find anything related to IBM in the tree. Maybe it was some sort of ACPI or platform addition.
Could you post the dmesg? Preferbly of a working and a non-working kernel.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Here are dmesg from non-working and working kernels:
Arch 3.12.9 (most LEDs don't work):
http://pastebin.com/McxBneRW
Gentoo 3.9.7 (all LEDs work):
http://pastebin.com/EZdzKRTf
As you can see they both are using:
ThinkPad ACPI Extras v0.24 from http://ibm-acpi.sf.net
Offline
The dmesg from 3.9.7 is incomplete.
ronald@Charlie /usr/src/linux
$ find . -name Kconfig -print0 | xargs -0 grep ACPI_IBM
./drivers/pci/hotplug/Kconfig:config HOTPLUG_PCI_ACPI_IBM
The ibm-acpi driver is part of the Linux kernel 2.6.10 and later (option CONFIG_ACPI_IBM). The version included in the kernel may be older than the latest release available from this web site.
I think it went upstream in 2.6.10 and was merged with something else in either 3.12, 3.11 or 3.10.
I suggest you use the arch wayback machine to try these kernels to pinpoint in which version it went wrong.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
I booted the same ThinkPad from a Gentoo-based live CD with kernel 3.12.9. Almost all LEDs work. Although Gentoo might have the kernel patched, I would rather assume it's a configuration issue.
dmesg:
http://ara-ler.com/journal/201402201140/1/dmesg
kernel config:
http://ara-ler.com/journal/201402201140/1/config
Offline
[ 26.035160] thinkpad_acpi: warning: userspace override of important firmware LEDs is enabled
The dmesg you posted is once again incomplete. But the above could be a clue. But I have no idea what it means.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
[ 26.035160] thinkpad_acpi: warning: userspace override of important firmware LEDs is enabled
The dmesg you posted is once again incomplete. But the above could be a clue. But I have no idea what it means.
Greate! Thanks for pointing out, Rexilion! That's a real hint, I never paid attention to that "override" word. RTFM is the answer!
https://www.kernel.org/doc/Documentatio … d-acpi.txt
It states:
Unrestricted access to all LEDs requires that thinkpad-acpi be
compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled.
Distributions must never enable this option. Individual users that
are aware of the consequences are welcome to enabling it.
So I've compiled my custom kernel with that option enabled and the LEDs work again!
Offline
Cool. Maybe you could safe yourself the burden of recompiling the kernel by looking for a boot parameter? Other than that, good job!
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Maybe you could safe yourself the burden of recompiling the kernel by looking for a boot parameter?
That would have more sense, of course, but...
Just checked the driver code (thinkpad_acpi.c), the behavior is chosen at compile time:
#ifdef CONFIG_THINKPAD_ACPI_UNSAFE_LEDS
return false;
#else
return (1U & (TPACPI_SAFE_LEDS >> led)) == 0;
#endif
so it wouldn't be possible to use a boot parameter...
Offline
I cannot write C, but I would seriously consider writing up a patch using snippets from the net and try to get this upstream. You can say that it breaks relied on behaviour (regression). The kernel developers are pretty serious about that, so you might have a shot.
Of course, I'm only speaking from the lazy arm chair in this respect. But it's not rocket science to make it a boot parameter I think.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
There is another strange thing: the microphone mute button LED has been "disabled" at some point. I've found the following description how to patch the kernel module to make it accessible from the user space (Ubuntu's):
http://askubuntu.com/questions/125367/e … -thinkpads
I've tried and recompiled the module "thinkapd_acpi" - and it works! But it was working before! I definitely used it a year or two ago. How come the mic LED becomes "unsafe"?..
Offline
I did some digging. It was first relocated and then renamed.
The LED class handling was added here.
But the working v3.10 kernel was released in the middle of 2013 . It was moved again from misc/drivers/ to drivers/platform/x86 here.
+Unrestricted access to all LEDs requires that thinkpad-acpi be
+compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled.
+Distributions must never enable this option. Individual users that
+are aware of the consequences are welcome to enabling it.
I guess the option was disabled after v3.10 on most distro's. The commit was on april 2009. V3.10 was released in the middle of 2013.
+ Overriding LED state on ThinkPads can mask important
+ firmware alerts (like critical battery condition), or misled
+ the user into damaging the hardware (undocking or ejecting
+ the bay while buses are still active), etc.
Better keep an eye on your dmesg. And if you ever run into trouble with relation to the kernel, you should try to disable this.
EDIT: As for your LED trouble. Maybe this is related. You can test it by reverting this patch or trying a v3.11 kernel. The former is better.
Last edited by Rexilion (2014-02-23 10:17:05)
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Pages: 1