Problem Description: booting with acpi on locks keyboard and mouse. booting with acpi=off prevents this from occuring the difference between the boot up messages is as follows (i believe they illustrate the problem/conflict location) #-------------------------------------------------- # diff 2.6.12.1-8th 2.6.12.1-8th.acpioff 50c50 < Kernel command line: BOOT_IMAGE=Linux2NEW ro root=305 idebus=66 model=full_dig nodevfs --- > Kernel command line: BOOT_IMAGE=Linux2NEW ro root=305 idebus=66 model=full_dig nodevfs apci=off 56c56 < Detected 2993.158 MHz processor. --- > Detected 2993.275 MHz processor. 161c161 < audit(1119609326.250:0): initialized --- > audit(1119610137.685:0): initialized 193,195c193,194 < i8042.c: Can't read CTR while initializing i8042. < pnp: Device 00:09 does not supported disabling. < pnp: Device 00:08 does not supported disabling. --- > serio: i8042 AUX port at 0x60,0x64 irq 12 > serio: i8042 KBD port at 0x60,0x64 irq 1 313a313 > input: AT Translated Set 2 keyboard on isa0060/serio0 323a324 > input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 325a327,330 > nvidia: module license 'NVIDIA' taints kernel. > ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 169 > PCI: Setting latency timer of device 0000:01:00.0 to 64 > NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7667 Fri Jun 17 07:01:04 PDT 2005 341,344d345 < nvidia: module license 'NVIDIA' taints kernel. < ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 169 < PCI: Setting latency timer of device 0000:01:00.0 to 64 < NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7667 Fri Jun 17 07:01:04 PDT 2005 #-------------------------------------------------- Hopefully this isint my own fault, i tried forever to solve this but it does seem to be a bug. -Ted #-------------------------------------------------- # some of my system information # Distribution: debian 3.1 More kernel info: Linux version 2.6.12.1 (root@anvil) (gcc version 3.3.6 (Debian 1:3.3.6-6)) #8 SMP Fri Jun 24 10:27:13 EDT 2005 Linux anvil 2.6.12.1 #8 SMP Fri Jun 24 10:27:13 EDT 2005 i686 GNU/Linux Gnu C 3.3.6 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.38-WIP reiserfsprogs line reiser4progs line PPP 2.4.3 nfs-utils 1.0.7 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.5 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 056 Modules Loaded snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc nvidia Hardware motherboard: ECS PF21 (Intel X925 / Socket 775) Intel p4 (630) processor
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.