Bug 15710 - NumLock LED stays on after PC poweroff.
NumLock LED stays on after PC poweroff.
Status: CLOSED DUPLICATE of bug 15770
Product: Drivers
Classification: Unclassified
Component: Input Devices
i386 Linux
: P1 low
Assigned To: drivers_input-devices
:
Depends on:
Blocks: 14885
  Show dependency treegraph
 
Reported: 2010-04-07 15:13 UTC by aceman
Modified: 2010-10-28 18:15 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.33
Tree: Mainline
Regression: Yes


Attachments

Description aceman 2010-04-07 15:13:53 UTC
After I shutdown/poweroff my PC, the NumLock LED on the keyboard stays on. This started happening only since the stable kernel 2.6.33, never before. The keyboard is an old standard PS/2 102-key model, no multimedia keys. The motherboard is a new ASUS M2N68 (AMD AM2+ based). I am using the default keyboard kernel driver (builtin) - CONFIG_KEYBOARD_ATKBD, x86 32bit. Kernel 2.6.33.2 still has the problem.
Comment 1 Dmitry Torokhov 2010-04-08 20:46:54 UTC
I do not see many changes to PS/2 in 2.6.33. Could you please try reverting commit 4a299bf591bc5bef3bde8316e603b9eaec5a7696? If this does not help then I am afraid you need to try and isolate the breakage to a particular -rc kernel...
Comment 2 aceman 2010-04-09 19:00:55 UTC
Yes, I fetched the patch from here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4a299bf591bc5bef3bde8316e603b9eaec5a7696

I reverted only this part of the change:

@@ -836,7  +837,7  @@ static void atkbd_cleanup(struct serio *serio)
        struct atkbd *atkbd = serio_get_drvdata(serio);
 
        atkbd_disable(atkbd);
-       ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_BAT);
+       ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_DEF);
 }

It DOES fix the problem, the LED turns OFF.

Here are more kernel messages about my keyboard in case you wish to distinguish keyboards and to send them different commands:
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
Comment 3 Dmitry Torokhov 2010-04-09 21:18:44 UTC
Hm, ATKBD_CMD_RESET_BAT woudl indeed turn off the LED, however I am surprised that we keep keyboard powered after shutdown. Do you have something similar to "wakeup on keypress" enabled in BIOS?

Rafael, do you know if we normally keep keyboards powered?
Comment 4 aceman 2010-04-10 09:35:51 UTC
I have specifically disabled all "Wake up on <device>" in the BIOS. This is a desktop machine, I wish all devices to be really powered down at shutdown.

Maybe the device driver can't check the BIOS setting therefore leaves keyboard powered up in case it is needed for the wakeup function?
Comment 5 Rafael J. Wysocki 2010-04-10 19:06:04 UTC
(In reply to comment #3)
> Hm, ATKBD_CMD_RESET_BAT woudl indeed turn off the LED, however I am surprised
> that we keep keyboard powered after shutdown. Do you have something similar to
> "wakeup on keypress" enabled in BIOS?
> 
> Rafael, do you know if we normally keep keyboards powered?

Not intentionally, at least.

We've had some ACPI changes that might be related to that, but they were committed during the 2.6.34 merge window.

aceman, can you attach the contents of /proc/acpi/wakeup, please?
Comment 6 aceman 2010-04-10 21:34:03 UTC
#cat /proc/acpi/wakeup 
Device  S-state   Status   Sysfs node
PS2K      S4     disabled  pnp:00:0a
UAR1      S4     disabled  pnp:00:0c
NSMB      S4     disabled  pci:0000:00:01.1
USB0      S4     disabled  pci:0000:00:02.0
USB2      S3     disabled  pci:0000:00:02.1
US15      S4     disabled  pci:0000:00:04.0
US12      S3     disabled  pci:0000:00:04.1
NMAC      S5     disabled  pci:0000:00:0a.0
P0P1      S4     disabled  pci:0000:00:08.0
HDAC      S4     disabled  pci:0000:00:07.0
BR10      S4     disabled  pci:0000:00:0b.0
BR11      S4     disabled  pci:0000:00:0c.0
BR12      S4     disabled  pci:0000:00:0d.0
Comment 7 Dmitry Torokhov 2010-04-17 08:30:50 UTC

*** This bug has been marked as a duplicate of bug 15770 ***

Note You need to log in before you can comment on or make changes to this bug.