Hi,
Do the PCI Express chipsets also use the same PCI API ? The device
specifications are thus for the device that i am looking at:
PCI Express interface
* Compliant to PCI Express Base Specification 1.0a
* The PCI Express circuit supports isochronous data traffic intended
for uninterrupted transfer of streaming data like video streaming
o x1 PCI Express endpoint (2.5 Gbit/s)
o Data and clock recovery from serial stream
o Low jitter and BER
* Type 0 configuration space header
o 64-bit addressing
o Single BAR; programmable address range of 17 bits, 18 bits,
19 bits or 20 bits dependent on application requirements
* PCI Express capabilities
o 128 bytes write packet size and 64 bytes read packet size
o MSI support
o Software directed power management of four device power
states (D0 to D3)
o Active state power management of link states
o Vendor specific capability for VC1 support; after reset VC1
isochronous capability is disabled
I have been trying the said card with a normal PCI style driver, but
while booting the kernel (2.6.21.1) i do get a message like this (an
Intel DP965LT motherboard with BIOS version:
MQ96510J.86A.1612.2006.1227.1513)
Also accessing the interrupt registers causes a hard freeze, for which
only the RESET button seems to be of any help.
Uncompressing Linux .. Ok, booting the kernel.
BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
vendor)
PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0
Any ideas as to what could be wrong ?
Thanks,
Manu
On Wed, May 23, 2007 at 04:15:01PM +0400, Manu Abraham wrote:
> Hi,
>
> Do the PCI Express chipsets also use the same PCI API ?
At the Linux kernel driver level, yes, they do.
> The device
> specifications are thus for the device that i am looking at:
>
> PCI Express interface
>
> * Compliant to PCI Express Base Specification 1.0a
> * The PCI Express circuit supports isochronous data traffic intended
> for uninterrupted transfer of streaming data like video streaming
> o x1 PCI Express endpoint (2.5 Gbit/s)
> o Data and clock recovery from serial stream
> o Low jitter and BER
> * Type 0 configuration space header
> o 64-bit addressing
> o Single BAR; programmable address range of 17 bits, 18 bits,
> 19 bits or 20 bits dependent on application requirements
> * PCI Express capabilities
> o 128 bytes write packet size and 64 bytes read packet size
> o MSI support
> o Software directed power management of four device power
> states (D0 to D3)
> o Active state power management of link states
> o Vendor specific capability for VC1 support; after reset VC1
> isochronous capability is disabled
>
> I have been trying the said card with a normal PCI style driver, but
> while booting the kernel (2.6.21.1) i do get a message like this (an
> Intel DP965LT motherboard with BIOS version:
> MQ96510J.86A.1612.2006.1227.1513)
> Also accessing the interrupt registers causes a hard freeze, for which
> only the RESET button seems to be of any help.
>
> Uncompressing Linux .. Ok, booting the kernel.
> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
> vendor)
> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0
>
> Any ideas as to what could be wrong ?
What type of PCI device is this? What driver is controlling it? What
is the output of 'lspci -v' at boot time?
thanks,
greg k-h
root@manu-04:~# lspci -vvvn
00:00.0 0600: 8086:29a0 (rev 02)
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00:01.0 0604: 8086:29a1 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 30000000-31ffffff
Prefetchable memory behind bridge: 0000000020000000-000000002fffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: [88] Subsystem: 8086:0000
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4139
Capabilities: [a0] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x16
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
Slot: Number 0, PowerLimit 75.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Off, PwrInd On, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
00:03.0 0780: 8086:29a4 (rev 02)
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32426100 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
00:19.0 0200: 8086:104b (rev 02)
Subsystem: 8086:0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 216
Region 0: Memory at 32400000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at 32424000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 20e0 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4171
00:1a.0 0c03: 8086:2834 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at 20c0 [size=32]
00:1a.1 0c03: 8086:2835 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 10
Region 4: I/O ports at 20a0 [size=32]
00:1a.7 0c03: 8086:283a (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 11
Region 0: Memory at 32425c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
00:1b.0 0403: 8086:284b (rev 02)
Subsystem: 8086:2111
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 9
Region 0: Memory at 32420000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
00:1c.0 0604: 8086:283f (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 32500000-325fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 1, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4141
Capabilities: [90] Subsystem: 8086:283f
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.1 0604: 8086:2841 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 32300000-323fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 2, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4149
Capabilities: [90] Subsystem: 8086:2841
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.2 0604: 8086:2843 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 32600000-326fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 3, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4151
Capabilities: [90] Subsystem: 8086:2843
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.3 0604: 8086:2845 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 32700000-327fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 4, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4159
Capabilities: [90] Subsystem: 8086:2845
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.4 0604: 8086:2847 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 32200000-322fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 5
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 5, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4161
Capabilities: [90] Subsystem: 8086:2847
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1d.0 0c03: 8086:2830 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at 2080 [size=32]
00:1d.1 0c03: 8086:2831 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 11
Region 4: I/O ports at 2060 [size=32]
00:1d.2 0c03: 8086:2832 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 11
Region 4: I/O ports at 2040 [size=32]
00:1d.7 0c03: 8086:2836 (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32425800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
00:1e.0 0604: 8086:244e (rev f2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=07, subordinate=07, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: 32100000-321fffff
Prefetchable memory behind bridge: 0000000032000000-00000000320fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] Subsystem: 8086:514d
00:1f.0 0601: 8086:2810 (rev 02)
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00:1f.2 0106: 8086:2824 (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 217
Region 0: I/O ports at 2108 [size=8]
Region 1: I/O ports at 2114 [size=4]
Region 2: I/O ports at 2100 [size=8]
Region 3: I/O ports at 2110 [size=4]
Region 4: I/O ports at 2020 [size=32]
Region 5: Memory at 32425000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+
Address: fee0100c Data: 4169
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] #12 [0010]
00:1f.3 0c05: 8086:283e (rev 02)
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 10
Region 0: Memory at 32426000 (32-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 2000 [size=32]
01:00.0 0300: 10de:01d1 (rev a1) (prog-if 00 [VGA])
Subsystem: 1043:8229
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 31000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at 20000000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at 30000000 (64-bit, non-prefetchable) [size=16M]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [78] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <256ns, L1 <4us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x16
03:00.0 0101: 11ab:6101 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: 11ab:6101
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1018 [size=8]
Region 1: I/O ports at 1024 [size=4]
Region 2: I/O ports at 1010 [size=8]
Region 3: I/O ports at 1020 [size=4]
Region 4: I/O ports at 1000 [size=16]
Region 5: Memory at 32300000 (32-bit, non-prefetchable) [size=512]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
Link: Latency L0s <256ns, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
06:00.0 0480: 1131:7162 (rev 01)
Subsystem: 1822:0027
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32200000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [50] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <256ns, L1 <1us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
Link: Latency L0s <4us, L1 <64us
Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [74] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Vendor Specific Information
07:00.0 0400: 109e:036e (rev 11)
Subsystem: 1822:0001
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 32001000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
07:00.1 0480: 109e:0878 (rev 11)
Subsystem: 1822:0001
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 32000000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
07:03.0 0c00: 104c:8023 (prog-if 10 [OHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32104000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at 32100000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
root@manu-04:~# clear
root@manu-04:~# lspci -vvn
00:00.0 0600: 8086:29a0 (rev 02)
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00:01.0 0604: 8086:29a1 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 30000000-31ffffff
Prefetchable memory behind bridge: 0000000020000000-000000002fffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: [88] Subsystem: 8086:0000
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4139
Capabilities: [a0] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x16
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
Slot: Number 0, PowerLimit 75.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Off, PwrInd On, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
00:03.0 0780: 8086:29a4 (rev 02)
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32426100 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
00:19.0 0200: 8086:104b (rev 02)
Subsystem: 8086:0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 216
Region 0: Memory at 32400000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at 32424000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 20e0 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4171
00:1a.0 0c03: 8086:2834 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at 20c0 [size=32]
00:1a.1 0c03: 8086:2835 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 10
Region 4: I/O ports at 20a0 [size=32]
00:1a.7 0c03: 8086:283a (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 11
Region 0: Memory at 32425c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
00:1b.0 0403: 8086:284b (rev 02)
Subsystem: 8086:2111
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 9
Region 0: Memory at 32420000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
00:1c.0 0604: 8086:283f (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Memory behind bridge: 32500000-325fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 1, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4141
Capabilities: [90] Subsystem: 8086:283f
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.1 0604: 8086:2841 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 32300000-323fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 2, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4149
Capabilities: [90] Subsystem: 8086:2841
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.2 0604: 8086:2843 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
Memory behind bridge: 32600000-326fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 3, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4151
Capabilities: [90] Subsystem: 8086:2843
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.3 0604: 8086:2845 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
Memory behind bridge: 32700000-327fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x0
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 4, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4159
Capabilities: [90] Subsystem: 8086:2845
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1c.4 0604: 8086:2847 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
Memory behind bridge: 32200000-322fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 5
Link: Latency L0s <1us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
Slot: Number 5, PowerLimit 10.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Unknown, PwrInd Unknown, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Address: fee0100c Data: 4161
Capabilities: [90] Subsystem: 8086:2847
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1d.0 0c03: 8086:2830 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at 2080 [size=32]
00:1d.1 0c03: 8086:2831 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 11
Region 4: I/O ports at 2060 [size=32]
00:1d.2 0c03: 8086:2832 (rev 02) (prog-if 00 [UHCI])
Subsystem: 8086:514d
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 11
Region 4: I/O ports at 2040 [size=32]
00:1d.7 0c03: 8086:2836 (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32425800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
00:1e.0 0604: 8086:244e (rev f2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=07, subordinate=07, sec-latency=32
Memory behind bridge: 32100000-321fffff
Prefetchable memory behind bridge: 0000000032000000-00000000320fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] Subsystem: 8086:514d
00:1f.0 0601: 8086:2810 (rev 02)
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00:1f.2 0106: 8086:2824 (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 217
Region 0: I/O ports at 2108 [size=8]
Region 1: I/O ports at 2114 [size=4]
Region 2: I/O ports at 2100 [size=8]
Region 3: I/O ports at 2110 [size=4]
Region 4: I/O ports at 2020 [size=32]
Region 5: Memory at 32425000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+
Address: fee0100c Data: 4169
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] #12 [0010]
00:1f.3 0c05: 8086:283e (rev 02)
Subsystem: 8086:514d
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 10
Region 0: Memory at 32426000 (32-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 2000 [size=32]
01:00.0 0300: 10de:01d1 (rev a1) (prog-if 00 [VGA])
Subsystem: 1043:8229
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 31000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at 20000000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at 30000000 (64-bit, non-prefetchable) [size=16M]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [78] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <256ns, L1 <4us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
Link: Latency L0s <256ns, L1 <4us
Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x16
03:00.0 0101: 11ab:6101 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: 11ab:6101
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1018 [size=8]
Region 1: I/O ports at 1024 [size=4]
Region 2: I/O ports at 1010 [size=8]
Region 3: I/O ports at 1020 [size=4]
Region 4: I/O ports at 1000 [size=16]
Region 5: Memory at 32300000 (32-bit, non-prefetchable) [size=512]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
Link: Latency L0s <256ns, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
06:00.0 0480: 1131:7162 (rev 01)
Subsystem: 1822:0027
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32200000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [50] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <256ns, L1 <1us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
Link: Latency L0s <4us, L1 <64us
Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [74] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Vendor Specific Information
07:00.0 0400: 109e:036e (rev 11)
Subsystem: 1822:0001
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 32001000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
07:00.1 0480: 109e:0878 (rev 11)
Subsystem: 1822:0001
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 32000000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
07:03.0 0c00: 104c:8023 (prog-if 10 [OHCI])
Subsystem: 8086:514d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 32104000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at 32100000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
root@manu-04:~#
>> Uncompressing Linux .. Ok, booting the kernel.
>> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor)
>> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0
This message is about device 01:00.0 as it says (your nvidia video
card based on later lspci output).
> The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface.
>
> 06:00.0 Multimedia controller: Philips Semiconductors Unknown device
> 7162 (rev 01)
> Subsystem: Twinhan Technology Co. Ltd Unknown device 0027
This is device 06:00.0, so it's not related to that earlier message at
all. You didn't say what problem you're having with your driver for
this device... but all standard PCI stuff should work fine for PCIe
devices -- the normal PCI driver stuff is all you should need for
everything but exotic cases.
- R.
Roland Dreier wrote:
>>> Uncompressing Linux .. Ok, booting the kernel.
>>> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor)
>>> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0
>
> This message is about device 01:00.0 as it says (your nvidia video
> card based on later lspci output).
>
> > The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface.
> >
> > 06:00.0 Multimedia controller: Philips Semiconductors Unknown device
> > 7162 (rev 01)
> > Subsystem: Twinhan Technology Co. Ltd Unknown device 0027
>
> This is device 06:00.0, so it's not related to that earlier message at
> all. You didn't say what problem you're having with your driver for
> this device...
If i uncomment the saa716x_read or write, what i get is a solid freeze
on module load. If i leave it commented out, the module loads fine.
static irqreturn_t saa716x_pcie_irq(int irq, void *dev_id)
{
struct saa716x *saa716x;
u32 stat, mask;
if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) {
printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__);
return IRQ_NONE;
}
// stat = saa716x_read(0x500);
dprintk(verbose, SAA716x_DEBUG, 0, "=== Interrupts[%04x] [", stat);
dprintk(verbose, SAA716x_DEBUG, 0, "] ==\n");
return IRQ_HANDLED;
}
int saa716x_pcie_init(struct saa716x *saa716x)
{
struct pci_dev *pdev = saa716x->pdev;
int err = 0;
u8 latency, revision;
printk(KERN_INFO "%s: found a %s device\n", __func__,
saa716x->hwconfig->model_name);
pci_set_drvdata(pdev, saa716x);
if ((err = pci_enable_device(pdev)) != 0) {
printk(KERN_ERR "%s ERROR: pci enable failed (%i)\n", __func__, err);
goto fail0;
}
if (request_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0), DRIVER_NAME) == NULL) {
printk(KERN_ERR "%s ERROR: mem region request failed\n", __func__);
err = -ENOMEM;
goto fail1;
}
saa716x->mmio = ioremap(pci_resource_start(pdev, 0), 0x1000); // FIXME:
check this size
if ((err = request_irq(pdev->irq, saa716x_pcie_irq, IRQF_SHARED |
IRQF_DISABLED,
DRIVER_NAME, (void *) saa716x)) != 0) {
printk(KERN_ERR "%s ERROR: irq request failed (%i)\n", err, __func__);
goto fail2;
}
pci_set_master(pdev);
pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency);
pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
dprintk(verbose, SAA716x_ERROR, 0, " SAA7160/1/2 Rev %d [%04x:%04x], ",
revision,
saa716x->pdev->subsystem_vendor, saa716x->pdev->subsystem_device);
dprintk(verbose, SAA716x_ERROR, 0,
"irq: %d, latency: %d\n memory: 0x%04x, mmio: 0x%p\n",
saa716x->pdev->irq, latency, pci_resource_start(pdev, 0), saa716x->mmio);
saa716x->verbose = verbose;
// init_waitqueue_head(&saa716x->i2c_queue);
/* Disable all interrupts here */
// saa716x_write(0, 0x500);
return 0;
fail2:
iounmap(saa716x->mmio);
release_mem_region(pci_resource_start(saa716x->pdev, 0),
pci_resource_len(saa716x->pdev, 0));
fail1:
pci_disable_device(pdev);
fail0:
pci_set_drvdata(pdev, NULL);
return err;
}
EXPORT_SYMBOL_GPL(saa716x_pcie_init);
> but all standard PCI stuff should work fine for PCIe
> devices -- the normal PCI driver stuff is all you should need for
> everything but exotic cases.
That part is then fine. Does MSI require any special tinkering ?
Thanks,
Manu
> If i uncomment the saa716x_read or write, what i get is a solid freeze
> on module load. If i leave it commented out, the module loads fine.
That sounds like a typical bug during driver development... you're
probably wedging the hardware by doing the wrong access.
I didn't see the source for saa716x_read or write in the code you
posted, so it's hard to say if there's a problem with them.
Is your interrupt handler getting called? Is the device generating
interrupts?
> That part is then fine. Does MSI require any special tinkering ?
Just pci_enable_msi() as usual.
- R.
#ifndef __SAA716x_PRIV_H
#define __SAA716x_PRIV_H
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/sched.h>
#include <linux/mutex.h>
#include "dvbdev.h"
#include "dvb_demux.h"
#include "dmxdev.h"
#include "dvb_frontend.h"
#include "dvb_net.h"
#define SAA716x_ERROR 0
#define SAA716x_NOTICE 1
#define SAA716x_INFO 2
#define SAA716x_DEBUG 3
#define dprintk(x, y, z, format, arg...) do { \
if (z) { \
if ((x > SAA716x_ERROR) && (x > y)) \
printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\
else if ((x > SAA716x_NOTICE) && (x > y)) \
printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\
else if ((x > SAA716x_INFO) && (x > y)) \
printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\
else if ((x > SAA716x_DEBUG) && (x > y)) \
printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\
} else { \
if (x > y) \
printk(format, ##arg); \
} \
} while (0);
#define MAKE_ENTRY(subven, subdev, configptr) { \
.vendor = 0x1131, \
.device = 0x7162, \
.subvendor = (subven), \
.subdevice = (subdev), \
.driver_data = (unsigned long) (configptr) \
}
#define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr))
#define saa716x_read(addr) readl((saa716x->mmio)+(addr))
struct saa716x;
typedef int (*saa716x_load_config_t)(struct saa716x *saa716x);
struct saa716x_hwconfig {
char *model_name;
char *dev_type;
saa716x_load_config_t load_config;
};
struct saa716x_dma {
struct tasklet_struct dma_tasklet;
};
struct saa716x_dvb {
struct dvb_adapter adapter;
struct dvb_frontend *fe;
struct dvb_demux demux;
struct dmxdev dmxdev;
struct dmx_frontend fe_hw;
struct dmx_frontend fe_mem;
struct dvb_net dvbnet;
};
struct saa716x_i2c {
struct device *dev;
struct i2c_adapter adapter;
wait_queue_head_t i2c_queue;
};
struct saa716x {
/* dev priv */
unsigned int verbose;
unsigned int num;
struct saa716x_hwconfig *hwconfig;
/* PCI */
struct pci_dev *pdev;
void __iomem *mmio;
unsigned int irq;
/* I2C */
struct saa716x_i2c i2c_adapter_a;
struct saa716x_i2c i2c_adapter_b;
/* DMA */
struct saa716x_dma dma_device_a;
struct saa716x_dma dma_device_b;
/* DVB */
struct saa716x_dvb dvb_device_a;
struct saa716x_dvb dvb_device_b;
};
extern void saa716x_i2c_disable(struct saa716x *saa716x);
extern void saa716x_i2c_enable(struct saa716x *saa716x);
extern int saa716x_pcie_init(struct saa716x *saa716x);
extern void saa716x_pcie_exit(struct saa716x *saa716x);
#endif //__SAA716x_PRIV_H
> It looks so, from the logs. The only problem is i can't disable the
> interrupts, if i write "0" to 0x500, the interrupt/enable register, it
> gives me a solid freeze. If i read from the handler, commenting out the
> disable interrupts in init, that read also gives me a solid freeze. This
> lead me to think that there could be some problem with the MMIO block
> access.
OK, this looks reasonable:
> #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr))
although
a) your driver has no hope of working on a system with more than one
device of this type; and
b) there's really no point in obfuscating a simple use of writel()
this way.
Why does the device come up in a state where it generates a stream of
interrupts as soon as you enable the PCI device? That's somewhat
unusual behavior, although certainly not unheard of.
This really has the feel of a typical driver bug to me, not anything
related to general PCIe access. I've definitely wedged my system many
times while trying to poke a device the right way.
Also, where are you getting the offset of 0x500 from? Is it possible
that the offset is really being given to you in bits (so you should
use 0x500 / 8) or 32-bit words (so you should use an offset of 0x500 *
4)? Are the datasheet / programming docs available for this device?
I actually have:
02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162
in one of my systems so I'd be somewhat interested in getting a driver
working too.
- R.
Roland Dreier wrote:
> > It looks so, from the logs. The only problem is i can't disable the
> > interrupts, if i write "0" to 0x500, the interrupt/enable register, it
> > gives me a solid freeze. If i read from the handler, commenting out the
> > disable interrupts in init, that read also gives me a solid freeze. This
> > lead me to think that there could be some problem with the MMIO block
> > access.
>
> OK, this looks reasonable:
>
> > #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr))
>
> although
>
> a) your driver has no hope of working on a system with more than one
> device of this type; and
to make it working with more than one device shouldn't be hard once it
is going on.
> b) there's really no point in obfuscating a simple use of writel()
> this way.
>
> Why does the device come up in a state where it generates a stream of
> interrupts as soon as you enable the PCI device? That's somewhat
> unusual behavior, although certainly not unheard of.
Will ask the vendor, what's going on.
> This really has the feel of a typical driver bug to me, not anything
> related to general PCIe access. I've definitely wedged my system many
> times while trying to poke a device the right way.
Yeah, you seem to sound right.
> Also, where are you getting the offset of 0x500 from?
The register offset is according to the device specs. Of course i
already found some wrong offsets etc, maybe this one's wrong too, probably.
> Is it possible
> that the offset is really being given to you in bits (so you should
> use 0x500 / 8) or 32-bit words (so you should use an offset of 0x500 *
It says, the base address is currently 500h
> 4)? Are the datasheet / programming docs available for this device?
Working with this device, under NDA with the vendor.
> I actually have:
>
> 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162
>
> in one of my systems so I'd be somewhat interested in getting a driver
> working too.
Cool, won't be that long, just the bridge part remains, most other parts
are done or do exist.
Thanks,
Manu
Roland Dreier wrote:
> Why does the device come up in a state where it generates a stream of
> interrupts as soon as you enable the PCI device? That's somewhat
> unusual behavior, although certainly not unheard of.
>
In fact the device wasn't generating a stream of interrupts when loaded
(i guess). It was just that the shared handler was showing all the
interrupts that occurred, since i was not looking at the interrupt
mask/status.
But accessing any registers caused me a flood of interrupts, which froze
the system. excessive printing to the console caused a lockup.
I am now wondering whether the usage of MSI would help in this case and
that i should be using enable_msi before request_irq ?
> I am now wondering whether the usage of MSI would help in this case and
> that i should be using enable_msi before request_irq ?
MSI interrupts are never shared. So if pci_enable_msi() succeeds, you
can be sure that the interrupts you get with that IRQ number are
coming from your device.
But using MSI does not work on all systems, so your driver needs to
work with standard (possibly shared) INTx interrupts too. And you
should probably provide at least a module flag to disable the use of
MSI, to avoid problems on buggy systems.
- R.
Roland Dreier wrote:
> > I am now wondering whether the usage of MSI would help in this case and
> > that i should be using enable_msi before request_irq ?
>
> MSI interrupts are never shared. So if pci_enable_msi() succeeds, you
> can be sure that the interrupts you get with that IRQ number are
> coming from your device.
>
i presume then i shouldn't be using IRQF_SHARED, if using MSI.
Another question would be if the device supports multiple messages, MSIX
should be used ?
In such a context, if i request for say more than the messages that i
need, say i request 16 messages, but use only 1 or 2, that does bear any
consequences ?
> But using MSI does not work on all systems, so your driver needs to
> work with standard (possibly shared) INTx interrupts too. And you
> should probably provide at least a module flag to disable the use of
> MSI, to avoid problems on buggy systems.
I should probably look for CONFIG_PCI_MSI and check whether the system
supports MSI pci_enable_msi() ?
On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote:
> Roland Dreier wrote:
> > > I am now wondering whether the usage of MSI would help in this case and
> > > that i should be using enable_msi before request_irq ?
> >
> > MSI interrupts are never shared. So if pci_enable_msi() succeeds, you
> > can be sure that the interrupts you get with that IRQ number are
> > coming from your device.
> >
>
> i presume then i shouldn't be using IRQF_SHARED, if using MSI.
I'm not sure...but my guess is not. Who ever "just knows", could you
please submit a patch to Documentation/MSI-HOWTO.txt ?
> Another question would be if the device supports multiple messages, MSIX
> should be used ?
Yes. Assuming the device supports multiple MSI-X messages.
> In such a context, if i request for say more than the messages that i
> need, say i request 16 messages, but use only 1 or 2, that does bear any
> consequences ?
Yes. One is allocating IRQ vectors from a finite number of vectors.
But this normally isn't a problem until one gets to larger machines that
have more than 4-8 PCI-e or PCI-X slots.
Typically, one will limit the number of vectors to the number of CPUs
in the system or to how many different events the device can signal.
> > But using MSI does not work on all systems, so your driver needs to
> > work with standard (possibly shared) INTx interrupts too. And you
> > should probably provide at least a module flag to disable the use of
> > MSI, to avoid problems on buggy systems.
>
> I should probably look for CONFIG_PCI_MSI and check whether the system
> supports MSI pci_enable_msi() ?
pci_enable_msi() will fail if the system doesn't support MSI or something
else goes wrong with the call (e.g. already setup).
hth,
grant
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/kernel.h>
#include <linux/pci.h>
#include <asm/io.h>
#include <linux/ioport.h>
#include <asm/pgtable.h>
#include <asm/page.h>
#include <linux/types.h>
#include <linux/interrupt.h>
#include <linux/kmod.h>
#include <linux/vmalloc.h>
#include <linux/init.h>
#include "saa716x_priv.h"
#include "saa716x_regs.h"
#include "saa716x_budget.h"
#define DRIVER_NAME "SAA716x_CORE"
unsigned int verbose = 5;
module_param(verbose, int, 0644);
MODULE_PARM_DESC(verbose, "verbosity level");
static irqreturn_t saa716x_pcie_irq(int irq, void *dev_id)
{
struct saa716x *saa716x;
u32 i2c_stat1, i2c_stat2, mask;
if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) {
printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__);
return IRQ_NONE;
}
// i2c_stat1 = saa716x_read(0xbfe0);
// i2c_stat2 = saa716x_read(0xcfe0);
dprintk(verbose, SAA716x_DEBUG, 0, "=== Interrupts[Core A: %04x - Core B: %04x] [", i2c_stat1, i2c_stat2);
dprintk(verbose, SAA716x_DEBUG, 0, "] ==\n");
return IRQ_HANDLED;
}
static irqreturn_t saa716x_pcie_irq_msi(int irq, void *dev_id)
{
struct saa716x *saa716x;
if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) {
printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__);
return IRQ_NONE;
}
return IRQ_HANDLED;
}
static int saa716x_request_irq(struct saa716x *saa716x)
{
u32 flags;
int err;
flags = IRQF_SHARED;
#ifdef CONFIG_PCI_MSI
saa716x->have_msi = TRUE;
if ((err = pci_enable_msi(saa716x->pdev))) {
printk("%s ERROR(%d): unable to allocate MSI Interrupt\n", __func__, err);
saa716x->have_msi = FALSE;
}
if (saa716x->have_msi) {
flags &= ~IRQF_SHARED;
err = request_irq(saa716x->pdev->irq, &saa716x_pcie_irq_msi, flags, DRIVER_NAME, saa716x);
if (err)
printk("%s ERROR(%d): Unable to allocate Interrupt\n", __func__, err);
} else
#endif
if ((err = request_irq(saa716x->pdev->irq, &saa716x_pcie_irq, flags, DRIVER_NAME, saa716x)) != 0)
printk("%s ERROR(%d): Unable to allocate Interrupt\n", __func__, err);
return err;
}
static void saa716x_free_irq(struct saa716x *saa716x)
{
free_irq(saa716x->pdev->irq, saa716x);
#ifdef CONFIG_PCI_MSI
if (saa716x->have_msi)
pci_disable_msi(saa716x->pdev);
#endif
}
int saa716x_pcie_init(struct saa716x *saa716x)
{
struct pci_dev *pdev = saa716x->pdev;
int err = 0;
u8 latency, revision;
u32 i2c_stat, int_stat, flags, subsys;
unsigned long mmio_start, mmio_len;
printk(KERN_INFO "%s: found a %s device\n", __func__, saa716x->hwconfig->model_name);
pci_set_drvdata(pdev, saa716x);
if ((err = pci_enable_device(pdev)) != 0) {
printk(KERN_ERR "%s ERROR: pci enable failed (%i)\n", __func__, err);
goto fail0;
}
if (!(pci_resource_flags(pdev, BAR_0) & IORESOURCE_MEM)) {
printk(KERN_ERR "Cannot find proper PCIe device "
"base addrress, aborting.\n");
err = -ENODEV;
goto fail1;
}
if ((err = pci_request_region(pdev, BAR_0, DRIVER_NAME)) < 0) {
printk(KERN_ERR "%s ERROR: mem region request failed\n", __func__);
err = -ENOMEM;
goto fail1;
}
pci_set_master(pdev);
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
err = -EIO;
if (!(saa716x->mmio = ioremap(mmio_start, mmio_len)))
goto fail2;
saa716x->mmio_start = mmio_start;
saa716x->mmio_end = mmio_start + mmio_len;
err = saa716x_request_irq(saa716x);
if (err)
goto fail2;
pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency);
pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
dprintk(verbose, SAA716x_ERROR, 0, " SAA7162 Rev %d [%04x:%04x], ",
revision,
saa716x->pdev->subsystem_vendor,
saa716x->pdev->subsystem_device);
dprintk(verbose, SAA716x_ERROR, 0,
"irq: %d, latency: %d\n IOMEM: 0x%lx-0x%lx length:0x%lx\n",
saa716x->pdev->irq,
latency,
saa716x->mmio_start,
saa716x->mmio_end,
mmio_len);
dprintk(verbose, SAA716x_ERROR, 0, " MMIO: 0x%p\n", saa716x->mmio);
saa716x->verbose = verbose;
// init_waitqueue_head(&saa716x->i2c_queue);
/* Disable all interrupts here */
// saa716x_write(0, 0x500);
// i2c_stat = saa716x_read(0xb008);
// int_stat = saa716x_read(0x500);
// dprintk(verbose, SAA716x_ERROR, 1, "I2C Status=[0x%04x]", i2c_stat);
// dprintk(verbose, SAA716x_ERROR, 1, "INT Status=[0x%04x]", int_stat);
subsys = saa716x_read(0x00012000);
dprintk(verbose, SAA716x_ERROR, 1, "Subsys:0x%04x", subsys);
return 0;
fail2:
iounmap(saa716x->mmio);
release_mem_region(pci_resource_start(saa716x->pdev, 0),
pci_resource_len(saa716x->pdev, 0));
fail1:
pci_disable_device(pdev);
fail0:
pci_set_drvdata(pdev, NULL);
return err;
}
EXPORT_SYMBOL_GPL(saa716x_pcie_init);
void saa716x_pcie_exit(struct saa716x *saa716x)
{
struct pci_dev *pdev = saa716x->pdev;
u8 command;
dprintk(verbose, SAA716x_ERROR, 1, "Unloading .. ");
dprintk(verbose, SAA716x_ERROR, 1, "Disabling PCIe Bus Mastering ..");
pci_read_config_byte(pdev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MASTER;
pci_write_config_byte(pdev, PCI_COMMAND, command);
saa716x_free_irq(saa716x);
dprintk(verbose, SAA716x_NOTICE, 1, "SAA716x mem: 0x%p", saa716x->mmio);
iounmap(saa716x->mmio);
release_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
}
EXPORT_SYMBOL_GPL(saa716x_pcie_exit);
MODULE_DESCRIPTION("SAA716x PCIe bridge driver");
MODULE_AUTHOR("Manu Abraham");
MODULE_LICENSE("GPL");
From: Manu Abraham <[email protected]>
Date: Sat, 26 May 2007 19:03:12 +0400
> i presume then i shouldn't be using IRQF_SHARED, if using MSI.
That's actually a really good question.
It is likely architecture dependant whether the PCI controller wires
unique MSI interrupts to shared cpu interrupt lines.
I can imagine many systems where the cpu simply doesn't have enough
interrupt pins to uniquely identify every possible MSI interrupt
source.
David Miller wrote:
> From: Manu Abraham <[email protected]>
> Date: Sat, 26 May 2007 19:03:12 +0400
>
>> i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependant whether the PCI controller wires
> unique MSI interrupts to shared cpu interrupt lines.
>
> I can imagine many systems where the cpu simply doesn't have enough
> interrupt pins to uniquely identify every possible MSI interrupt
> source.
>
Ok, that explains it a bit, but i am pulling out a bit of hair on the
other aspects i wrote in this thread, of course i am a bit new to PCIe
and hence all my questions/doubts. Hope someone can clear them.
Thanks,
Manu
On Sat, May 26, 2007 at 03:49:10PM -0700, David Miller wrote:
> From: Manu Abraham <[email protected]>
> Date: Sat, 26 May 2007 19:03:12 +0400
>
> > i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependant whether the PCI controller wires
> unique MSI interrupts to shared cpu interrupt lines.
MSI (and MSI-X) vectors are required to be exclusive.
I submitted that change to pci.txt last year:
http://lkml.org/lkml/2006/12/25/2
and ISTR I've posted that bit of the PCI spec a few years ago.
But it probably was to linux-pci mailing list only.
> I can imagine many systems where the cpu simply doesn't have enough
> interrupt pins to uniquely identify every possible MSI interrupt
> source.
The cpus haven't been using interrupt pins for a long time now.
Anything with a Local-xAPIC is already using transactions to
signal interrupts even if the OS isn't aware of it.
hth,
grant
From: Grant Grundler <[email protected]>
Date: Sat, 26 May 2007 17:55:15 -0600
> MSI (and MSI-X) vectors are required to be exclusive.
> I submitted that change to pci.txt last year:
> http://lkml.org/lkml/2006/12/25/2
>
> and ISTR I've posted that bit of the PCI spec a few years ago.
> But it probably was to linux-pci mailing list only.
This requirement only extends to the PCI host controller,
how that interfaces to the cpu and it's limitations is
an entirely other matter.
> > I can imagine many systems where the cpu simply doesn't have enough
> > interrupt pins to uniquely identify every possible MSI interrupt
> > source.
>
> The cpus haven't been using interrupt pins for a long time now.
> Anything with a Local-xAPIC is already using transactions to
> signal interrupts even if the OS isn't aware of it.
I'm not talking about x86, x86_64, et al.
I'm talking about embedded ARM chips and the like, and yes they
very possibly will be using PCI-E controllers at some point.
On Sat, May 26, 2007 at 05:00:39PM -0700, David Miller wrote:
> From: Grant Grundler <[email protected]>
> Date: Sat, 26 May 2007 17:55:15 -0600
>
> > MSI (and MSI-X) vectors are required to be exclusive.
> > I submitted that change to pci.txt last year:
> > http://lkml.org/lkml/2006/12/25/2
> >
> > and ISTR I've posted that bit of the PCI spec a few years ago.
> > But it probably was to linux-pci mailing list only.
>
> This requirement only extends to the PCI host controller,
> how that interfaces to the cpu and it's limitations is
> an entirely other matter.
Are they really? The device is generating the transaction on the bus.
The PCI host controller (in general) will be routing that transaction
to wherever the "dest addr" of the MSI lives. It doesn't have to be
in the CPU but it will certainly be a proxy for that CPU if it's not.
We won't care if the proxy only have one IRQ line going to the CPU
as long as the de-muxing of the "data" portion results in a unique
identifier that can be mapped to exactly one interrupt handler.
> > The cpus haven't been using interrupt pins for a long time now.
> > Anything with a Local-xAPIC is already using transactions to
> > signal interrupts even if the OS isn't aware of it.
>
> I'm not talking about x86, x86_64, et al.
>
> I'm talking about embedded ARM chips and the like, and yes they
> very possibly will be using PCI-E controllers at some point.
It doesn't matter if it's embedded or not. Trying to share what
is the equivalent to an "edge triggered" interrupt is futile.
MSI "vectors" need to be exclusive.
thanks,
grant
From: Grant Grundler <[email protected]>
Date: Sat, 26 May 2007 18:16:31 -0600
> Are they really? The device is generating the transaction on the bus.
> The PCI host controller (in general) will be routing that transaction
> to wherever the "dest addr" of the MSI lives. It doesn't have to be
> in the CPU but it will certainly be a proxy for that CPU if it's not.
> We won't care if the proxy only have one IRQ line going to the CPU
> as long as the de-muxing of the "data" portion results in a unique
> identifier that can be mapped to exactly one interrupt handler.
True, on sparc64 PCI-E controllers, for example, the MSI vector is
received by the PCI-E host controller, and the host controller turns
this into a cpu format interrupt packet for the system bus.
I guess on IRQ pin starved systems, the PCI-E host controller or
something similar would get interrogated by the cpu for the MSI vector
number.
I don't want to be the person who has to code up support for
that, as it's not easy to shim mid-level vectoring into the
generic IRQ layer currently. I'd love to be able to do that
on sparc64 instead of what arch/sparc64/kernel/pci_sun4v.c's
pci_sun4v_msi_prehandler() is doing.
There is a lot of information and vectoring capabilities present
that I'm simply not taking advantage of yet :-)
David Miller wrote:
> From: Grant Grundler <[email protected]>
> Date: Sat, 26 May 2007 18:16:31 -0600
>
>> Are they really? The device is generating the transaction on the bus.
>> The PCI host controller (in general) will be routing that transaction
>> to wherever the "dest addr" of the MSI lives. It doesn't have to be
>> in the CPU but it will certainly be a proxy for that CPU if it's not.
>> We won't care if the proxy only have one IRQ line going to the CPU
>> as long as the de-muxing of the "data" portion results in a unique
>> identifier that can be mapped to exactly one interrupt handler.
>
> True, on sparc64 PCI-E controllers, for example, the MSI vector is
> received by the PCI-E host controller, and the host controller turns
> this into a cpu format interrupt packet for the system bus.
Err .. why would a PCIe controller be CPU specific ? Looking at Figure
1-6 of the spec, i think it should be CPU independent ?
Excuse me for my ignorance, just that my head has begun to reel after
reading through PCIe 1.0 and the device specs, still being inconclusive
how to proceed.
On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote:
> David Miller wrote:
> > True, on sparc64 PCI-E controllers, for example, the MSI vector is
> > received by the PCI-E host controller, and the host controller turns
> > this into a cpu format interrupt packet for the system bus.
>
> Err .. why would a PCIe controller be CPU specific ? Looking at Figure
> 1-6 of the spec, i think it should be CPU independent ?
To be pedantic, the PCIe controller isn't really CPU specific.
It's host bus specific. ie the PCI-e controller is a bridge between
whatever chipset defines the "cache coherency domain" and the PCI-e devices.
> Excuse me for my ignorance, just that my head has begun to reel after
> reading through PCIe 1.0 and the device specs, still being inconclusive
> how to proceed.
no problem...I suspect you need to figure out why DTL-MMIO isn't working.
I have never touched DTL and can't be of much help with that.
hth,
grant
David Miller wrote:
>
>> i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependant whether the PCI controller wires
> unique MSI interrupts to shared cpu interrupt lines.
>
> I can imagine many systems where the cpu simply doesn't have enough
> interrupt pins to uniquely identify every possible MSI interrupt
> source.
There are systems which only get a single bit indication that an MSI has
happened.
Presumably we need something like IRQF_MSI which can be set as
appropriate depending on the architecture?
-hpa
From: "H. Peter Anvin" <[email protected]>
Date: Sat, 26 May 2007 19:34:26 -0700
> There are systems which only get a single bit indication that an MSI has
> happened.
>
> Presumably we need something like IRQF_MSI which can be set as
> appropriate depending on the architecture?
Although I don't want to make the IRQ handling subsystems any more
complicated than they already are, one idea I floated around is that
we could seperate CPU irq numbers (the things we pass around today)
and MSI vector numbers.
But I immediately understand how that is unnecessary to some extent,
any platform which needs to deal with that kind of distinction can use
virtual IRQ numbers like sparc64 and powerpc do.
Sparc64 PCI-E controllers, for example, allow you to group several
MSIs into a 'group', and the interrupt source is for the group rather
than the individual MSIs. When the MSI group interrupt arrives, you
get a descriptor in a per-MSI-group ring buffer that describes the MSI
that arrived.
This descriptor in fact passes on a ton of interesting information,
see arch/sparc64/kernel/pci_sun4v.c:pci_sun4v_msiq_entry.
It gives you the type, the system TSC value at the time of interrupt
arrival (so you could do incredibly cool profiling with this),
the PCI bus/device/fn that generated the MSI vector, the MSI address
that was signalled, the MSI data field, and full information for PCI-E
MSG packets including bus/dev/fn of target, the message routing code,
and the message code.
But we use none of these facilities currently because it's either
impossible or too cumbersome to be useful at the moment.
Grant Grundler wrote:
> On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote:
>> David Miller wrote:
>>> True, on sparc64 PCI-E controllers, for example, the MSI vector is
>>> received by the PCI-E host controller, and the host controller turns
>>> this into a cpu format interrupt packet for the system bus.
>> Err .. why would a PCIe controller be CPU specific ? Looking at Figure
>> 1-6 of the spec, i think it should be CPU independent ?
>
> To be pedantic, the PCIe controller isn't really CPU specific.
> It's host bus specific. ie the PCI-e controller is a bridge between
> whatever chipset defines the "cache coherency domain" and the PCI-e devices.
>
>> Excuse me for my ignorance, just that my head has begun to reel after
>> reading through PCIe 1.0 and the device specs, still being inconclusive
>> how to proceed.
>
> no problem...I suspect you need to figure out why DTL-MMIO isn't working.
> I have never touched DTL and can't be of much help with that.
>
Have been reading a bit about DTL and so on. Haven't reached anything
much solid yet. Will have something soon i presume.
Thanks for the comments.
Regards,
Manu
David Miller wrote:
> From: "H. Peter Anvin" <[email protected]>
> Date: Sat, 26 May 2007 19:34:26 -0700
>
>> There are systems which only get a single bit indication that an MSI has
>> happened.
>>
>> Presumably we need something like IRQF_MSI which can be set as
>> appropriate depending on the architecture?
>
> Although I don't want to make the IRQ handling subsystems any more
> complicated than they already are, one idea I floated around is that
> we could seperate CPU irq numbers (the things we pass around today)
> and MSI vector numbers.
>
> But I immediately understand how that is unnecessary to some extent,
> any platform which needs to deal with that kind of distinction can use
> virtual IRQ numbers like sparc64 and powerpc do.
>
> Sparc64 PCI-E controllers, for example, allow you to group several
> MSIs into a 'group', and the interrupt source is for the group rather
> than the individual MSIs. When the MSI group interrupt arrives, you
> get a descriptor in a per-MSI-group ring buffer that describes the MSI
> that arrived.
>
> This descriptor in fact passes on a ton of interesting information,
> see arch/sparc64/kernel/pci_sun4v.c:pci_sun4v_msiq_entry.
>
> It gives you the type, the system TSC value at the time of interrupt
> arrival (so you could do incredibly cool profiling with this),
> the PCI bus/device/fn that generated the MSI vector, the MSI address
> that was signalled, the MSI data field, and full information for PCI-E
> MSG packets including bus/dev/fn of target, the message routing code,
> and the message code.
>
> But we use none of these facilities currently because it's either
> impossible or too cumbersome to be useful at the moment.
>
I think it is better to use IRQF_MSI as HPA suggested, since IRQF_SHARED
is a bit confusing thing altogether since MSI doesn't share interrupts.
> > i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependant whether the PCI controller wires
> unique MSI interrupts to shared cpu interrupt lines.
Yes, but current Linux drivers assume that MSI interrupts are
non-shared. Certainly in my drivers I make that assumption, and from
a quick look neither tg3 nor e1000 sets IRQF_SHARED if they enable
MSI.
I think that if we run on a system where MSI interrupts may be shared,
then we should just have pci_enable_msi() fail. If drivers have to
allow for shared MSI interrupts, then they lose most of the advantage
of MSI -- if I get an MSI but I don't know it came from my device, I
probably have to do an MMIO read to find out if it's mine or not and
also to preserve DMA ordering, which kills the main advantage of MSI.
And since MSIs are basically edge triggered, sharing vectors is going
to lead to all sorts of hassles.
> I can imagine many systems where the cpu simply doesn't have enough
> interrupt pins to uniquely identify every possible MSI interrupt
> source.
I have a hard time imagining a PCI host bus controller that converts
MSI interrupts back to wire interrupts that go to pins on the CPU.
For one thing it would be hard to maintain the guarantee that
MSI interrupts can't pass DMAs. And it would be an absolutely silly
architecture too.
- R.
> Presumably we need something like IRQF_MSI which can be set as
> appropriate depending on the architecture?
Unfortunately I don't think it's that simple -- drivers would have to
do something like
if (IRQF_MSI == IRQF_SHARED) {
// lose MSI optimizations, do an MMIO read, etc.
} else...
As I said I think that if we're running on a system where MSI
interrupts might be shared, we should just have pci_enable_msi() fail
so drivers fall back to their usual interrupt handler.
> I'm talking about embedded ARM chips and the like, and yes they
> very possibly will be using PCI-E controllers at some point.
As an example the AMCC PowerPC 440SPe, which is an embedded SoC with
an onboard PCIe controller that supports three ports, has 24 MSI
interrupts that external PCIe devices can raise.
> >> Another question would be if the device supports multiple messages, MSIX
> >> should be used ?
> >
> > Yes. Assuming the device supports multiple MSI-X messages.
At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
so that's not an option for you. The current Linux implementation
does not support more than one MSI interrupt, so you just get one
interrupt with pci_enable_msi().
I think it's probably simplest for you to forget about MSI until you
have the basic driver working.
> Ok. Alongwith this, i am a bit confused with the mailbox approach of
> sending messages, every register type has it's own set of interrupt
> registers (for example I2C, say I2C has it's own set of 32 STATUS
> bitfields for it's interrupt, the same goes for the others)
>
> Another aspect is the DTL-MMIO interface, which isn't defined any place.
> Using the base addresses as an offset to the normal MMIO obtained using
> pci_resource_*/ioremap() doesn't seem to work at all.
> [etc....]
All this is device-specific stuff ... not sure how much anyone can
help you if you can't share the docs.
- R.
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an option for you. The current Linux implementation
> does not support more than one MSI interrupt, so you just get one
> interrupt with pci_enable_msi().
>
> I think it's probably simplest for you to forget about MSI until you
> have the basic driver working.
Damn. The NXP guys don't want me to go ahead with the generic registers.
What they said :
> And if you really use the SAA7162 in the PC application,
> pls ignore the 0x520 .....
> That's not a good decision to use that.
Might need to ask them why it would not be a good decision then. :-(
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an option for you. The current Linux implementation
> does not support more than one MSI interrupt, so you just get one
> interrupt with pci_enable_msi().
This would mean MSI or MSI-X ? A bit confused now.
? MSI capability
- 32 different messages
- programmable ID in MSI message data field
- programmable TC in MSI message address field
> > At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> > so that's not an option for you. The current Linux implementation
> > does not support more than one MSI interrupt, so you just get one
> > interrupt with pci_enable_msi().
>
> This would mean MSI or MSI-X ? A bit confused now.
As I said, the device I have in my system:
02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162
Subsystem: Animation Technologies Inc. Unknown device 0820
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at 90200000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable-
Capabilities: [50] Express Endpoint IRQ 0
Capabilities: [74] Power Management version 2
Capabilities: [80] Vendor Specific Information
...has only an MSI capability (the "[40] Message Signalled Interrupts"
line). So MSI-X is not possible, since the device cannot do it. And
that means you can at most do pci_enable_msi(). The current Linux MSI
support only handles a single interrupt, just like you get normally
(no matter how many MSI interrupts a device can handle). To get
multiple interrupts from a single device under Linux, you must use
MSI-X and pci_enable_msix -- but for this to work, your device must
support MSI-X of course.
A device that supports both MSI and MSI-X would look like:
0b:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] (rev 20)
Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA]
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fc600000 (64-bit, non-prefetchable) [size=1M]
Memory at d8800000 (64-bit, prefetchable) [size=8M]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable-
Capabilities: [84] MSI-X: Enable- Mask- TabSize=32
Capabilities: [60] Express Endpoint IRQ 0
with both "Message Signalled Interrupts" and "MSI-X" capabilities.
However, as I said before I think you shouldn't worry about MSI right
now. Since there are many systems where MSI doesn't work, you'll need
to get the driver working with legacy (INTx) interrupts anyway. And
you seem to be in a bit over your head just doing that without adding
the complexity of MSI on top, hence my recommendation to just focus on
the basic driver.
- R.
Roland Dreier wrote:
> > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> > > so that's not an option for you. The current Linux implementation
> > > does not support more than one MSI interrupt, so you just get one
> > > interrupt with pci_enable_msi().
> >
> > This would mean MSI or MSI-X ? A bit confused now.
>
> As I said, the device I have in my system:
>
> 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162
> Subsystem: Animation Technologies Inc. Unknown device 0820
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at 90200000 (64-bit, non-prefetchable) [size=1M]
> Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable-
> Capabilities: [50] Express Endpoint IRQ 0
> Capabilities: [74] Power Management version 2
> Capabilities: [80] Vendor Specific Information
>
> ...has only an MSI capability (the "[40] Message Signalled Interrupts"
> line). So MSI-X is not possible, since the device cannot do it. And
> that means you can at most do pci_enable_msi(). The current Linux MSI
> support only handles a single interrupt, just like you get normally
> (no matter how many MSI interrupts a device can handle). To get
> multiple interrupts from a single device under Linux, you must use
> MSI-X and pci_enable_msix -- but for this to work, your device must
> support MSI-X of course.
>
> A device that supports both MSI and MSI-X would look like:
>
> 0b:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] (rev 20)
> Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA]
> Flags: bus master, fast devsel, latency 0, IRQ 16
> Memory at fc600000 (64-bit, non-prefetchable) [size=1M]
> Memory at d8800000 (64-bit, prefetchable) [size=8M]
> Capabilities: [40] Power Management version 2
> Capabilities: [48] Vital Product Data
> Capabilities: [90] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable-
> Capabilities: [84] MSI-X: Enable- Mask- TabSize=32
> Capabilities: [60] Express Endpoint IRQ 0
>
> with both "Message Signalled Interrupts" and "MSI-X" capabilities.
>
Thanks for the explanation.
> However, as I said before I think you shouldn't worry about MSI right
> now. Since there are many systems where MSI doesn't work, you'll need
> to get the driver working with legacy (INTx) interrupts anyway. And
> you seem to be in a bit over your head just doing that without adding
> the complexity of MSI on top, hence my recommendation to just focus on
> the basic driver.
True, compatibility would be important.
Thanks,
Manu
From: Roland Dreier <[email protected]>
Date: Sun, 27 May 2007 18:03:29 -0700
> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI interrupts can't pass DMAs. And it would be an absolutely silly
> architecture too.
We are definitely going to see systems like this, and the DMA issue
will be taken care of by the PCI host controller, it will either pull
out all queued up DMA writes by the device in question itself
(somehow) or require the driver for the PCI host controller do a dummy
read out to the device before servicing an interrupt handler to
guanentee this semantic.
We already have pre-PCI-E controllers on sparc64 where I have to do a
dummy config space read to pull out all the pending DMA requests
before servicing an interrupt, so this kind of scheme would be nothing
new.
People are going to use PCI-E on very inexpensive and primitive cpu
platforms.
The thing to do for such platforms is the use virtual IRQ numbers and
interrogate the PCI-E controller for the MSI number when the CPU level
interrupt arrives and translate that into the appropriate virtual IRQ.
On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote:
...
> > I can imagine many systems where the cpu simply doesn't have enough
> > interrupt pins to uniquely identify every possible MSI interrupt
> > source.
>
> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI interrupts can't pass DMAs.
Whatever converts the MSI back to CPU IRQ pins would have to participate
in the "cache coherency domain". This would avoid issues around DMA ordering.
It _could_ be on the same silicon as the PCI Host bus controller as long
as the above is true.
> And it would be an absolutely silly architecture too.
While I agree it's silly, it might be cheaper if any patents are
involved, it reduces complexity, power consumption or anything
else that costs time/money.
thanks,
grant
Roland Dreier wrote:
>
> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI interrupts can't pass DMAs. And it would be an absolutely silly
> architecture too.
>
Well, on pretty much all CPUs interrupts sooner or later are combined to
an interrupt signal (not necessarily an external pin) on the CPU
indicating that an interrupt has happened. On many CPUs demultiplex is
then done in software.
As I said, I have seen at least one architecture where MSIs are treated
as nothing other than another PCI interrupt -- you get five status bits
from the PCI unit -- INTA, INTB, INTC, INTD, MSI. Needless to say, I
didn't bother enabling MSI on that platform. Even if it had worked
correctly, which I kind of doubt, it would probably have been a net loss.
-hpa
Grant Grundler wrote:
> On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote:
> ...
>> > I can imagine many systems where the cpu simply doesn't have enough
>> > interrupt pins to uniquely identify every possible MSI interrupt
>> > source.
>>
>> I have a hard time imagining a PCI host bus controller that converts
>> MSI interrupts back to wire interrupts that go to pins on the CPU.
>> For one thing it would be hard to maintain the guarantee that
>> MSI interrupts can't pass DMAs.
>
> Whatever converts the MSI back to CPU IRQ pins would have to participate
> in the "cache coherency domain". This would avoid issues around DMA ordering.
> It _could_ be on the same silicon as the PCI Host bus controller as long
> as the above is true.
>
Also, don't forget that a lot of platforms provide *no* hardware cache
coherency.
-hpa