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.
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>
The above commit has been identified as the source of the problem.
can we get full dmesg content please? (preferably from both working and non-working)
Created attachment 15589 [details] working - dmesg-2.6.24.3-12.fc8-i8042.debug
Created attachment 15590 [details] not working - dmesg-2.6.25-0.121.rc5.git4.fc9-i8042.debug
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 ?
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.
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 ?
fixed by commit 5761d64b277c287a7520b868c32d656ef03374b4
http://people.freebsd.org/~jhb/papers/bsdcan/2007/article/node4.html 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.)
"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.