Distribution: Slackware 10.0 Hardware Environment: Dell Inspiron 1100, notebook Software Environment: Problem Description: Keyboard just don't work on any 2.6.11-rc. All other things work ok. With next log-record at boot time: kernel: i8042.c: Can't read CTR while initializing i8042. While usual record is: kernel: i8042.c: Warning: Keylock active. kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Steps to reproduce:
i8042.noacpi boot option helps, keyboard is detected.
Ok, the acpi probing is gone in Vojtech's tree (replaced by PNP driver)...
Does 'usb-handoff' on the kernel command line help?
Ahh, I see. It works without ACPI. Can you provide the full dmesg? It's probably that ACPI reported wrong port numbers. We'll need to add some sanity checks into that probe routine.
Created attachment 4548 [details] kernel boot log, 2.6.11-rc4, keyboard is not detected kernel boot log, 2.6.11-rc4, keyboard is not detected thanks for helping.
Feb 15 00:23:13 voodoo-1100 kernel: ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1 Feb 15 00:23:13 voodoo-1100 kernel: ACPI: PS/2 Mouse Controller [PS2M] at irq 12 Feb 15 00:23:13 voodoo-1100 kernel: i8042.c: Can't read CTR while initializing i8042. It's exactly what I thought. ACPI reports ports 0x60, 0x66 where the correct numbers are 0x60,0x64. In my current tree we're not using ACPI directly, rather than that we're using ACPIPnP, but I suppose the information will be equally wrong here. I'll implement a sanity check in the code to take care of that. Until then, please use i8042.noacpi=1.
Oleksiy, Could you please verify that keyboard is properly detected even without i8042.noacpi with later kernels (for example 2.6.14)? Thanks!
Hi, I use Ubuntu Dapper Drake 6.06 and got the same problem with kernel 2.6.15-25-686, so I dare say it can be confirmed as 'not fixed' up until that kernel. I'm not sure about 2.6.17.1 though, as I'm new to linux and unwilling to compile a whole kernel. Regards, Tauwasser
Oleksiy, tauwasser, can you confirm if the problem still present in current kernel? Maybe a different problem this time in #8. Thanks.
I think we can close this bug until someone claims the problem still exists. Please reopen if the problem still there.