On Tue, 19 Mar 2013, Daniel Vetter wrote: > > That might be misleading. It's possible that the erroneous IRQs _are_ > > being issued but you're simply not aware of them. If the kernel thinks > > that no device is using IRQ 16 then it will leave that IRQ disabled. > > I guess I should have phrased it more precisely, but that's exactly > what I expect is happening on my machine: I don't have anything on > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence > the irq is completely disabled. Which obviously makes it impossible > for me to reproduce the issue. To test that theory, is there a quick > way to force-enable a given interrupt, short of just hacking up a 2nd > dummy irq handler in my driver? I don't know of any way. In fact, I have been thinking of writing a test driver module, with a module parameter telling it which IRQ number to register for. It seems like the sort of thing that would be useful to have, from time to time. Alan Stern -- 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
