On Wed, 7 Mar 2007, Ash Milsted wrote: > > Anyway, here's the bootlog for Dmitry from a boot with broken keyboard (2.6.21-rc3): The non-working setup doesn't get any interrupts back, and thus doesn't see the ACK for the "\xd4\xed" command. It really looks interrupt-related (especially considering that it goes away when you ask ACPI to not do certain things), but at the same time, the differences between -git6 and -git7 really don't seem to have *any* ACPI or PCI irq routing changes, so I think this really is related to the input-layer, and perhaps the real difference between ACPI irq routing and not is just the timing or IO acecss patterns that you get when you use the local apic vs the i8259 legacy irq controller. For example, if there is a edge-triggered interrupt involved (and both keyboard *and* mouse are edge-triggered), the io-apic and the i8259 work differently: temporarily disabling the interrupt will reset the edge trigger logic on the i8259, but not on an IO-APIC. So the lack of interrupts could be due to the input layer not clearing the interrupt source during setup, so some *old* interrupt just stays around, and because it's always set, on an IO-APIC it will never show as an edge at all - but on the i8259 the very action of registering the irq routine will create an edge. There's some reason to believe that you may have a pending interrupt waiting: for the working case, you actually have: > Mar 7 23:20:41 joker atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. so there was certainly *something* unexpected there. I'm not saying that's it, but it could explain why something that looks interrupt-related and that changes depending on whether you use ACPI to set up interrupts or not can have these kinds of reasons, that just depend on which interrupt controller the kernel happens to use, even though it's not "really" about lost interrupts at all, but just a driver that doesn't acknowledge a pending one. Or something. Doing the git bisect would really help. Linus - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
