Re: Unhandled IRQs on AMD E-450
From: Jeroen Van den Keybus
Date: Sun Dec 04 2011 - 09:08:13 EST
Clemens,
FYI,
> In theory, lspci's "Status: ... INTx+" shows an active interrupt line.
I have succeeded in catching a lspci on the SATA controller with INTx+
while IRQ 19 is disabled.
00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA
Controller [AHCI mode] (rev 40) (prog-if 01 [AHCI 1.0])
Subsystem: ASUSTeK Computer Inc. Device 8496
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 32
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at f140 [size=8]
Region 1: I/O ports at f130 [size=4]
Region 2: I/O ports at f120 [size=8]
Region 3: I/O ports at f110 [size=4]
Region 4: I/O ports at f100 [size=16]
Region 5: Memory at feb4f000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] SATA HBA v1.0 InCfgSpace
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
Kernel modules: ahci
The fact that the next lspci's showed INTx- shows that its pin is
definitely not stuck, does it not ? When I do e.g.
$ du -h -x --max-depth=1
in a second terminal, it gets the line nicely back to INTx+ due to
outstanding SATA commands. Cancelling the above du command (would
otherwise take ages to complete) results in INTx-.
Continuing with your patch...
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/