Bug 10382 - 2.6.25-rc5.git4 regression PS/2 mouse not detected/working
Summary: 2.6.25-rc5.git4 regression PS/2 mouse not detected/working
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_i386
Depends on:
Blocks: 9832
  Show dependency tree
Reported: 2008-04-02 10:33 UTC by Rafael J. Wysocki
Modified: 2008-07-19 23:05 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.25-rc5.git4
Regression: Yes
Bisected commit-id:

working - dmesg- (41.15 KB, text/plain)
2008-04-02 23:05 UTC, Yanko Kaneti
not working - dmesg-2.6.25-0.121.rc5.git4.fc9-i8042.debug (26.54 KB, text/plain)
2008-04-02 23:07 UTC, Yanko Kaneti

Description Rafael J. Wysocki 2008-04-02 10:33:23 UTC
Subject    : 2.6.25-rc5.git4 regression PS/2 mouse not detected/working
Submitter  : Yanko Kaneti <yaneti@declera.com>
Date       : 2008-04-02 10:59
References : http://lkml.org/lkml/2008/4/2/210
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Handled-By : Balaji Rao <balajirrao@gmail.com>

This entry is being used for tracking a regression from 2.6.24.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2008-04-02 15:47:09 UTC
commit e3f37a54f690d3e64995ea7ecea08c5ab3070faf
Author: Balaji Rao <balajirrao@gmail.com>
Date:   Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers

    Signed-off-by: Balaji Rao <balajirrao@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Comment 2 Rafael J. Wysocki 2008-04-02 15:47:57 UTC
The above commit has been identified as the source of the problem.
Comment 3 Arjan van de Ven 2008-04-02 15:56:05 UTC
can we get full dmesg content please?
(preferably from both working and non-working)
Comment 4 Yanko Kaneti 2008-04-02 23:05:33 UTC
Created attachment 15589 [details]
working - dmesg-
Comment 5 Yanko Kaneti 2008-04-02 23:07:04 UTC
Created attachment 15590 [details]
not working - dmesg-2.6.25-0.121.rc5.git4.fc9-i8042.debug
Comment 6 Balaji Rao R 2008-04-03 00:38:50 UTC
The line to watch out is ,

Working: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0 (HPET fails, mouse works)
Not Working: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 11, 12 (HPET works, mouse fails)

As I have said earlier, IRQ12 is being assigned to the HPET timer, which should not be the case. IRQ12 is used by legacy devices and should be left alone.

If I would know which interrupts are reserved for legacy use, I can fix it right away. Can anyone please tell me which IRQs in addition to IRQ12 are reserved on x86 ?
Comment 7 H. Peter Anvin 2008-04-03 08:27:46 UTC
It varies from system to system, and ACPI or PIR is supposed to tell you.  The only ones that are *always* assigned to legacy anymore are IRQ 0 (PIT), IRQ 2 (cascade) and IRQ 8 (RTC).

PS/2 keyboard and mouse, if present, use IRQ 1 and IRQ 12 respectively.

Legacy floppy, if present, uses IRQ 6, and DMA 2.

Traditional IDE, if present, use IRQ 14 and 15.

Serial ports, if present, use IRQ 3 and 4.

Parallel ports, if present, use IRQ 7 and 5 (in that order), and DMA 3 and 1.

Of course, with IOAPIC enabled, any of these can move around, since the mappings are chipset-specific in IOAPIC mode.
Comment 8 Balaji Rao R 2008-04-03 13:58:05 UTC
I tried many approaches, none worked out. IRQ12 is hardcoded for the i8042-aux device. I'm not sure how to move it around in the IO-APIC case.

Depending on how much time we have for the stable release, I think we should revert this commit, if possible. Its not good to have this nasty bug lying around in the stable release. The HPET case, which the patch intended to solve, is not common and its not a problem with the kernel. The patch actually tries to makeup for the mistake committed by BIOS, which should ideally take care of assigning IRQs to HPET timers.

Ingo, can we revert this commit ?
Comment 9 Adrian Bunk 2008-04-04 15:55:30 UTC
fixed by commit 5761d64b277c287a7520b868c32d656ef03374b4
Comment 10 David Brownell 2008-07-19 22:58:14 UTC

effectively suggests that only IRQs 5, 9-11, and 16+ would be decent candidates for assigning to HPET, and maybe not #5 on some systems ... assuming that traditional numbering is preserved even with an IO-APIC.  That's compatible with Peter's Comment #7.

However the real conundrum would seem to be the advice to assign an *unshared* IRQ for use with HPET.  (In some cases that's a requirement.  E.g. ICH8 docs say that while its HPET timer 2 can be used with IRQ #11, that must not be shared.  Using timer2 with IRQs 20-23 doesn't have that restriction.) Those are hard to come by on many systems, unless MSI can be used, especially without supporting infrastructure.

(My particular interest is wanting HPET to stop using the RTC IRQ.  I'm getting the feeling that's impractical until more HPETs with MSI capability arrive.  However, I suspect that assigning non-legacy interrupts for HPET timers 2 and above should be practical, especially if IRQ sharing is allowed ... as I'd expect it should be with /dev/hpet usage.)
Comment 11 H. Peter Anvin 2008-07-19 23:05:55 UTC
"My particular interest is wanting HPET to stop using the RTC IRQ."

Why is that?

The IRQs listed make no sense, quite frankly.  IRQs 5 and 9-11 are the ones without a seriously common legacy function, but they are heavily overbooked by bus devices.

Note You need to log in before you can comment on or make changes to this bug.