Messages in this thread |  | | | Date | Fri, 9 Dec 2011 12:17:40 +0100 | | Subject | Re: Unhandled IRQs on AMD E-450 | | From | Jeroen Van den Keybus <> |
| |
> The VT6308 is PCI, and you have only one bus.
There's also a bridge on the FCH: bus 0 dev. 14 fn. 4, but I see that the memory and IO regions of the e1000 and the VT630x are withing the range of the ASM108x bridge. Thanks for pointing that out.
> It's possible that > 1) the ASM1083 does not react to changes of the PCI interrupt line, or > 2) the interrupt controller ignores INTx_Deassert messages.
I'm a bit puzzled. The IOAPIC operates on external IRQ lines. So that would mean the LAPICs ?
> I'm wondering what the difference between triggering an interrupt and > reloading the driver is that makes it work again. I'd guess that > reattaching the driver reinitializes the interrupt, which would point > to 2).
I tried irq_disable(); irq_enable(); in spurious.c. That didn't change anything. Storm continues. Also important: from my logs it appears that when a driver is reloaded, there is indeed no storm at all. In my log posted at Dec. 6, that is clearly visible.
> All PCI interrupts (whether 'real' lines in hardware or emulated with > PCIe messages) end up at the I/O-APIC.
That would mean that the IO-APIC would decode MSI messages. I don't think it can do that. Would it not be possible that the PCI bus IRQ lines are directly connected to the FCH IO-APIC inputs (and that the ASM1083 INTx lines are simply not connected ?
(Makes me wonder why Asus did not simply use the existing PCI bridge on the FCH, which BTW also seems to depend on the use of the external INTx lines.)
> Check if a newer BIOS exists.
Did that. No newer version is available.
> Your trigger-interrupt patch would also be possible with firewire-ohci.
If this would work, you'd have to patch the drivers of all PCI devices. I'd much rather do it by modifying something in the IRQ handling code.
>> I'm thinking of immediately re-enabling the irqs after they've been >> disabled in spurious.c.
> You could try free_irq/request_irq, but I guess you cannot do this > directly from inside an interrupt handler.
No, I did irq_disable/irq_enable, which should directly call the mask/unmask methods of the chip handler. I still must check that, though, and especially if the correct handler is used. But as I said before, it didn't seem to do the trick.
>> I also think that the following posts may refer to the same problem:
<< > That's similar symptoms, but completely different hardware. At first sight, yes, but they still share some of the problem areas. I justed wanted to point out possibly similar cases. Never mind. ( >> http://ubuntuforums.org/showthread.php?t=1883854 Asus board with ASM1083 (same bridge).
>> https://lkml.org/lkml/2011/6/30/197 >> https://lkml.org/lkml/2011/10/14/146 Has device 1b21:1080 (same bridge) in its Asus system.
https://lkml.org/lkml/2011/10/22/157 Has a E35M1-M board (essentially the same board as the E45M1-M with the AMD E350 instead of the E450) )
J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |