Please send me by private email the acpidump and dmidecode information
for your ThinkPad, I don't have any for the T21. Feel free to
XXXXXX-out the UUID and serial number of your T21 in the dmidecode
output.
The machine was clean after a boot, correct? (no sleeps or other
known-to-be-busted-in-2.6.26 operations before the OOPS?)
Assuming the comments on the LED code from the first ibm-acpi maintainer
are correct, the T20-T22 use the same LED interface, the "LED_OLD"
ibm-acpi codepath. That codepath is indeed NOT tested often, as I don't
have a way to do so. Bugs there wouldn't surprise me too much.
If you try it using the sysfs led class, do you get the same OOPS? (I
expect you to. If you don't, I *need* to know this).
Is it always a problem with the last led (number 7), or other leds also
cause the OOPS?
Also, please try the patch below, and send me the debug output it will
generate.
--
"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
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 3f28f6e..392c800 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -3867,6 +3867,9 @@ static int led_set_status(unsigned int led, enum led_status_t ledstatus)
int rc = 0;
+ printk(TPACPI_ERR "debug: led %u, status %u, mode %u\n",
+ led, ledstatus, led_supported);
+
switch (led_supported) {
case TPACPI_LED_570:
/* 570 */
@@ -3878,13 +3881,22 @@ static int led_set_status(unsigned int led, enum led_status_t ledstatus)
case TPACPI_LED_OLD:
/* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20 */
led = 1 << led;
+ printk(TPACPI_ERR "debug: led is now 0x%0X\n", led);
+ printk(TPACPI_ERR "debug: will write A=0x%0X, B=0x%0X\n",
+ led * led_exp_hlbl[ledstatus],
+ led * led_exp_hlcl[ledstatus]);
+
rc = ec_write(TPACPI_LED_E...
