When I enable /etc/init.d/numlock the keyboard is dead in kdm. Using the mouse to restart the X-Server solves the problem. It also helps to disconnect the (PS/2) keyboard and reconnect it. So I guess the 8042 or/and the kernel driver gets confused. I have only reproduced the problem on the config below (Kernel 2.6.7, SIS 741). It does *not* occur on my other box (Kernel 2.6.5, VIA KT600, USB Keyboard). Reproducible: Always Steps to Reproduce: 1. Just boot into default runlevel with /etc/init.d/numlock enabled 2. 3. Actual Results: Cannot type anything. Expected Results: Hey, let me type my password :-) Gentoo 2004.2 with no "emerge sync" afterwards Kernel 2.6.7 SIS 741 based board PS/2 keyboard Xorg X-Server Message "atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly" in syslog. Guess this is due to setleds. Disabling or enabling legacy USB support in BIOS does not change anything.
Can you please try 2.6.9-rc2 or newer? I believe that there are lots of i8042 fixes in there.
Daniel, thanks for your hint. I applied the patches up to (including) 2.6.9-rc2 from kernel.org to my 2.6.7 vanilla kernel. And it doesn't change anything. The keyboard locks up in kdm when /etc/init.d/numlock is active. And again "atkbd.c: Spurious ACK on isa0060/serio0...". Shouldn't the kbd driver expect the ACK after issueing some LED command to the keyboard? BTW: I am currently using a different keyboard now. Thanx for your help anyway.
So has using a different keyboard solved the problem? Are you still connecting it in the same way?
Daniel, no, changing the keyboard does not solve the problem. Everything as with the other keyboard. This is what I intended to express.
The Spurious ACK message is quite common and isn't really a problem. Have you always had this problem, or did it just break in a kernel upgrade? Perhaps you could try a different version of Xorg? I'd suggest that you remove numlock from your runlevel, and find the exact command which breaks it for you (man setleds). You could then file a bug at http://bugzilla.kernel.org as this appears to be an upstream issue.
