Is this still happening in 2.6.13-rc4?

It's probably an acpi problem..

I'm seeing the same symptoms on a IBM x205 with BIOS revision 1.50.  It didn't
appear in earlier revisions of the BIOS, nor does it appear in linux 2.4.  I
don't have any binary module crud loaded on the system; the only change between
acpi=on and acpi=off is this in dmesg:

serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1

becomes:

i8042.c: Can't read CTR while initializing i8042.

Will try with 2.6.13-rc6 tomorrow when I get the chance.

Does 'usb-handoff' help?

usb-handoff=1 makes the PS/2 keyboard/mouse work on both 2.6.12.3 and
2.6.13-rc6.  Without that option, they are quite inoperable.  Having sniffed
around in Google for usb-handoff, it seems that this has something to do with
USB controller/BIOS quirks; would it be helpful if I tried disabled USB legacy
support in the BIOS?  (Assuming, of course, that the option hasn't totally
disappeared out of the BIOS ;))  Or am I just shooting into the dark?  Truly it
does seem odd that an option with "usb" in the name would fix ... PS/2. 
Entertaining, x86 is.

FWIW, this (x205) machine has an Intel 845 chipset.  I've seen others
complaining about this same problem with i7505 motherboards; to my knowledge our
7505-based machine (x225) doesn't suffer from this weirdness.

Anyway, thanks for the tip, Vojtech!  Looks like there's a
usb-handoff-by-default patch in -mm.

Yes, disabling the option in the BIOS should help, too. And yes, -mm has a patch
to make 'usb-handoff' the default. And yes, x86 is quite interesting.

Disabling USB legacy support also fixes the problem.

I can't explain why "acpi=off" is a workaround for this issue,
perhaps it changes some un-documented BIOS behaviour?

I guess BIOS writers just do not expect to have ACPI and USB legacy emulation 
code active at the same time - USB legacy emulation is most useful at boot time 
and in DOS where ACPI is certainly not used.

Automatic USB handoff is now in mainline, once they work out last issues with 
it I will start closing bugs such as this one.

Ted, Darrick, could you please try 2.6.16-rc1 and let us know if it works for 
you without any special command options?

2.6.16-rc1 works for me without any special options.

Just for the record, what USB controller(s) does your box have?

lspci output:

00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
        Subsystem: IBM Unknown device 1f00
        Flags: bus master, medium devsel, latency 0, IRQ 11
        I/O ports at a000 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
        Subsystem: IBM Unknown device 1f00
        Flags: bus master, medium devsel, latency 0, IRQ 10
        I/O ports at a040 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 02) (prog-if 20 [EHCI])
        Subsystem: IBM Unknown device 1f00
        Flags: bus master, medium devsel, latency 0, IRQ 9
        Memory at 84c00000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Debug port

It also does not work for me with 2.6.15, 2.6.15.1 and 2.6.16-rc1. Allways the same problem
i8042.c: Can't read CTR while initializing i8042.

I have Gigabyte MB, with nforce4 chipset.

Alan,

Could youplease take a look at this - from what I've seen it looks like UHCI 
handoff works fine but not OHCI handoff.

Thanks!

Martin, can you try editing the 2.6.16-rc1 kernel source?  Find the
quirk_usb_early_handoff() routine at the end of drivers/usb/host/pci-quirks.c
and comment out the line where it calls quirk_usb_handoff_ohci(pdev).  There's a
good chance this will fix your problem.  If it does, I'll know what part of the
code needs more work.

OK, i'l try evening, but one thing i'v found yesterday is that when i disable USB mouse support in 
BIOS everything works well.

OK, here is the result.

I have comment out quirk_usb_handoff_ohci(pdev), like this (i think it is good)

       if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
                quirk_usb_handoff_uhci(pdev);
/*        else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
                quirk_usb_handoff_ohci(pdev); */
        else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
                quirk_usb_disable_ehci(pdev);

And now PS2 mouse works, but my USB keyboard goes crazy :-) But is maybe ok, when this lines 
are missing.

dmesg shows now this

PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1


That's all.

If i can help somway, plese let me know.

Try uncommenting the quirk code so that it will run again, and apply this patch:

  http://bugzilla.kernel.org/attachment.cgi?id=7182&action=view

That's from another bugzilla entry that looks like the same problem as yours.

This patch does not work for me.

Here is the result. I have boot with i8042.debug

PNP: No PS/2 controller found. Probing ports directly.
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
i8042.c: Can't read CTR while initializing i8042.

Created attachment 7220 [details]
Add usb_delay_handoff kernel parameter

It looks like there won't be any easy way to fix this problem.	The best I can
come up with is this patch, which adds a new kernel parameter to prevent the
USB handoff from occurring too early.  After removing the other ohci_init
patch, which didn't work, and applying this one, you should be able to add the
word usb_delay_handoff on the boot command line and have a working keyboard.

Shouldn't the name be "no_usb_handoff"? The handoff will only be done if
USB modules are loaded, which doesn't necessarily have to happen.

SuSE already has carried a similar patch to disable the PCI-quirk USB handoff
code when the default was to do it.

The handoff is delayed until the USB driver modules do it.  If the driver
modules don't get loaded then the handoff is delayed indefinitely.

I don't want to call the parameter "no_usb_handoff" because it most cases the
handoff _will_ eventually take place.

Martin,

Do you still have the same problem with the newer kernels (2.6.20)?

Thanks!

I'll try, because at this time i don't have any PS2 device nor 2.6.20 kernel.

Please reopen this bug if it's still present with kernel 2.6.21.