Description of problem: When I boot a 2.6 kernel, either by installing the package on a FC1 system and rebooting or by trying to boot a boot.iso from a development tree, no keyboard or mouse input works. In addition, the keyboard lights are constantly flickering. They are mostly on, but flicker off. Version-Release number of selected component (if applicable): kernel-smp-2.6.0-0.1.14.i686.rpm How reproducible: 100% This is a dual-processor Dell Precision 420.
I'm having problems using a ps2 keyboard with the just released 2.6 kernel and Core 1.0. I downloaded, configured, compiled & installed the released 2.6.0 kernel (kernel-source-2.6.0-0.1.14.i386.rpm) and everything went smoothly until I tried to login from the 1st console (X is turned off locally) and the keyboard didn't work. Thinking I had done something stupid when I rolled by own kernel, I pulled down a prebuilt kernel (kernel-2.6.0-0.1.14.i686.rpm) and installed it. No change. The situation is I can telnet in or use remote X and everything works as it should but when I try to use the local ps2 keyboard in the default text console, the system doesn't seem to recognize it. I can boot with the original kernel (2.4.22-1.2115. nptl) and the keyboard works correctly in the text consoles. The hardware is an elderly UP ASUS P3B-F with 512M & 300Mhz processor. It has USB, but no devices. No ATA, SCSI disk & CDROM hung off an Adaptec2940 Ultra2 SCSI adapter. 100% reproducible.
I have the same problem. I have an usb mouse and a ps/2 keyboard on a relatively new system. I'll keep investigating to see if there is a solution.
Just tried an unmodified 2.6.1-rc1 (full kernel, not patched), no joy. Console still not resposive.
I tried playing with these kernel options: acpi apm atkbd_reset i8042_noaux i8042_reset i8042_unlock i8042_direct i8042_dumbkbd None seemed to have any effect.
Still a problem with -30 kernel in the development tree ?
I'm afraid so.
Same struggle here....I get a message in /var/log/messages that say: i8042.c: Can't read CTR while initializing i8042 In the mean time I have recompiled 2.6.1 arjanv latest with few unrelated patches (mpt fusion, alsa 101 etc.) with everything compiled into the kernel and this works without a glitch. I can' tell the difference since 8042 stuff seems to be compiled in for the -41 kernel too. I just saw this patch in the -mm3 kernel: input-01-i8042-suspend.patch I'll compile -41 with this and see if it helps.
Still there with -43 and the one that has the above patch compiled in. Since I am running 2.6.1+patches perfectly fine with the same SERIO options compiled in the problem seems to be not what is turned on but what is turned OFF. In my custom compilation I turned of everything that I do not use (acpi etc).
Just tried 2.6.1-mm4; no joy
2.6.3-1.96 Fedora kernel source w/custom options/compile seems to have solved my problems. Keyboard/mouse working as they should.
Which options? The 2.6.3-1.96smp i686 package does not fix the problem for me; neither does 2.6.3-1.109smp.
I should have been clearer. I downloaded and installed the kernel source (kernel-source-2.6.3-1.96.i386.rpm) and then configured from scratch and compiled. Note that my machine is not SMP; don't see why that should make a difference but there's no way to tell. Note also that I'm using gcc32. We may have totally different problems with similar symptoms.
Just saying you recompiled the kernel "with custom options" and the problem went away, doesn't help us to know which specific options you changed which may have affected the problem however. Can you be more specific?
Be sure to upgrade to XFree86 4.3.0-60 in rawhide also if you haven't already. It fixes the atkbd.c related bug.
Mike, I can guarantee this is nothing to do with X. The keyboard is unresponsive before init even starts -- in fact, right at the point where the 'serio' lines appear.
Ok, thanks Tim
fdepercin.com: could you at least attach your config file so that we can look at the differences between what you use (which works) and what we use (which doesn't)?
So switching keyboards to the one that actually came with this machine makes the problem go away. What make of keyboard do other people see this problem with? The one I'm using is a "Microsoft Natural Keyboard Elite".
I rebuilt atkbd with debugging on (and some extra printks for atkbd_connect/reconnect/disconnect), and here is the output from a Dell keyboard (works fine): serio: i8042 AUX port at 0x60,0x64 irq 12 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fe flags 01 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 serio: i8042 KBD port at 0x60,0x64 irq 1 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Received ab flags 00 atkbd.c: Received 41 flags 00 atkbd.c: Sent: ed atkbd.c: Received fa flags 00 atkbd.c: Sent: 00 atkbd.c: Received fa flags 00 atkbd.c: Sent: f3 atkbd.c: Received fa flags 00 atkbd.c: Sent: 00 atkbd.c: Received fa flags 00 atkbd.c: Sent: f4 atkbd.c: Received fa flags 00 input: AT Translated Set 2 keyboard on isa0060/serio0 But here is the output using the Microsoft keyboard (doesn't work): serio: i8042 AUX port at 0x60,0x64 irq 12 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fe flags 01 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 serio: i8042 KBD port at 0x60,0x64 irq 1 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 [...] atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 [...] atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Received ab flags 00 atkbd.c: Received ff flags 01 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 input: AT Translated Set 2 keyboard on isa0060/serio0 [...] atkbd.c: Received aa flags 00 atkbd: disconnected atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Received ff flags 01 atkbd: connecting atkbd.c: Sent: f2 atkbd.c: Received fa flags 00 atkbd.c: Sent: ed atkbd.c: Received fe flags 01 (sequence continues)
Created attachment 98457 [details] linux-kbd.patch This patch works around the problem for me.
So can we add this patch?
Please report this to the input maintainer vojtech. Touching this code makes me nervous as a lot of the time its a case of "fixes for person A" whilst "breaks person B's setup". This patch doesn't strike me as a real fix, but a workaround.
Can I get the whole sequence (without bits snipped out) for both the working and non-working case? It seems to me that the Microsoft keyboard doesn't accept the Set LED command, which would be highly unusual.
As I recall I only cut out irrelevant printks (from other parts of the kernel). The working trace appears in full, as it was in dmesg. The non-working case is unending.
I no longer have access to this hardware.