Bug 4791

Summary: ACPI + SERIO_I8042 bug/conflict
Product: Drivers Reporter: ted tiberio (ted)
Component: Input DevicesAssignee: Dmitry Torokhov (dmitry.torokhov)
Status: REJECTED INSUFFICIENT_DATA    
Severity: high CC: acpi-bugzilla, akpm, bunk, djwong, komodo, stern, vojtech
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.12.1 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Add usb_delay_handoff kernel parameter

Description ted tiberio 2005-06-24 09:33:43 UTC
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
Comment 1 Andrew Morton 2005-07-28 22:31:01 UTC
Is this still happening in 2.6.13-rc4?

It's probably an acpi problem..
Comment 2 Darrick J. Wong 2005-08-16 19:09:53 UTC
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.
Comment 3 Vojtech Pavlik 2005-08-17 01:41:58 UTC
Does 'usb-handoff' help?
Comment 4 Darrick J. Wong 2005-08-17 02:50:46 UTC
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.
Comment 5 Vojtech Pavlik 2005-08-17 04:19:10 UTC
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.
Comment 6 Darrick J. Wong 2005-08-17 13:29:29 UTC
Disabling USB legacy support also fixes the problem.
Comment 7 Len Brown 2006-01-18 00:43:03 UTC
I can't explain why "acpi=off" is a workaround for this issue,
perhaps it changes some un-documented BIOS behaviour?
Comment 8 Dmitry Torokhov 2006-01-18 06:27:39 UTC
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?
Comment 9 Darrick J. Wong 2006-01-18 14:49:32 UTC
2.6.16-rc1 works for me without any special options.
Comment 10 Dmitry Torokhov 2006-01-18 14:58:37 UTC
Just for the record, what USB controller(s) does your box have?
Comment 11 Darrick J. Wong 2006-01-18 15:05:44 UTC
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
Comment 12 Martin 2006-01-27 01:27:47 UTC
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.
Comment 13 Dmitry Torokhov 2006-01-27 09:36:02 UTC
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!
Comment 14 Alan Stern 2006-01-27 13:23:23 UTC
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.
Comment 15 Martin 2006-01-30 00:34:50 UTC
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.
Comment 16 Martin 2006-01-31 01:32:12 UTC
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.
Comment 17 Alan Stern 2006-01-31 07:10:18 UTC
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.
Comment 18 Martin 2006-02-01 00:33:52 UTC
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.
Comment 19 Alan Stern 2006-02-02 13:18:19 UTC
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.
Comment 20 Vojtech Pavlik 2006-02-02 14:21:17 UTC
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.
Comment 21 Alan Stern 2006-02-03 06:52:55 UTC
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.
Comment 22 Dmitry Torokhov 2007-03-12 08:53:13 UTC
Martin,

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

Thanks!
Comment 23 Martin 2007-03-12 09:02:25 UTC
I'll try, because at this time i don't have any PS2 device nor 2.6.20 kernel.
Comment 24 Adrian Bunk 2007-06-03 14:28:26 UTC
Please reopen this bug if it's still present with kernel 2.6.21.