2.6.20 PCI Cannot allocate resource region 2

2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Hi,

I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
the message is slightly different in 2.6.17.7)

PCI Cannot allocate resource region 2 of device 0000:02:0a.0
PCI Error while updating region 000:02:0a.0/5 (f3e00004 != 0200)
PCI Error while updating region 000:02:0a.0/5 (high 00000000 != 4e351)

lspci shows me a bit weird status BIST is running (on 2.6.17.7)
on 2.6.20, the line which says BIST is running, does not exist.

I have attached the lspci outputs on both 2.6.17.7 and 2.6.20

The device is a PCI 2.2 compliant device a multimedia bridge device
called Mantis.
The card is a plain 32 bit PCI card in a 32 bit PCI slot on an Asus
P4C800 motherboard.

looking at lspci output, the last 3 PCI devices are using the same chip.

The last 2 devices are Rev 1 chips, whereas the one which is acting a
bit strange is a newer version from the same vendor.

Any ideas as to why it could not allocate the region ?

Thanks,
Manu

[-- Attachment #2: lspci-2.6.17.7.txt --]
[-- Type: text/plain, Size: 10324 bytes --]

00:00.0 0600: 8086:2578 (rev 02)
	Subsystem: 1043:80f6
	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
	Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [e4] Vendor Specific Information
	Capabilities: [a0] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 0604: 8086:2579 (rev 02)
	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: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	Memory behind bridge: f1d00000-f3dfffff
	Prefetchable memory behind bridge: d9b00000-e9afffff
	Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:1d.0 0c03: 8086:24d2 (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef00 [size=32]

00:1d.1 0c03: 8086:24d4 (rev 02)
	Subsystem: 1043:80a6
	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 23
	Region 4: I/O ports at ef20 [size=32]

00:1d.2 0c03: 8086:24d7 (rev 02)
	Subsystem: 1043:80a6
	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 17
	Region 4: I/O ports at ef40 [size=32]

00:1d.3 0c03: 8086:24de (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef80 [size=32]

00:1d.7 0c03: 8086:24dd (rev 02) (prog-if 20)
	Subsystem: 1043:80a6
	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 D routed to IRQ 22
	Region 0: Memory at f7fffc00 (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 c2)
	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=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: f3e00000-f7efffff
	Prefetchable memory behind bridge: e9b00000-e9bfffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR+
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 0601: 8086:24d0 (rev 02)
	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

00:1f.1 0101: 8086:24db (rev 02) (prog-if 8a)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at <unassigned>
	Region 1: I/O ports at <unassigned>
	Region 2: I/O ports at <unassigned>
	Region 3: I/O ports at <unassigned>
	Region 4: I/O ports at fc00 [size=16]
	Region 5: Memory at 30000000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 0101: 8086:24d1 (rev 02) (prog-if 8f)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at efe0 [size=8]
	Region 1: I/O ports at efac [size=4]
	Region 2: I/O ports at efa0 [size=8]
	Region 3: I/O ports at efa8 [size=4]
	Region 4: I/O ports at ef60 [size=16]

00:1f.3 0c05: 8086:24d3 (rev 02)
	Subsystem: 1043:80a6
	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 4: I/O ports at 0400 [size=32]

00:1f.5 0401: 8086:24d5 (rev 02)
	Subsystem: 1043:80f3
	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 21
	Region 0: I/O ports at e800 [size=256]
	Region 1: I/O ports at ee80 [size=64]
	Region 2: Memory at f7fff800 (32-bit, non-prefetchable) [size=512]
	Region 3: Memory at f7fff400 (32-bit, non-prefetchable) [size=256]
	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-

01:00.0 0300: 10de:0181 (rev c1)
	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: 64 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at f3de0000 [disabled] [size=128K]
	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: [44] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10)
	Subsystem: 1043:808a
	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: 64 (8000ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at f7eff800 (32-bit, non-prefetchable) [size=2K]
	Region 1: I/O ports at dc00 [size=128]
	Capabilities: [50] 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-

02:04.0 0104: 105a:3373 (rev 02)
	Subsystem: 1043:80f5
	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: 96 (1000ns min, 4500ns max), Cache Line Size 90
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at df00 [size=64]
	Region 1: I/O ports at dfa0 [size=16]
	Region 2: I/O ports at d880 [size=128]
	Region 3: Memory at f7efe000 (32-bit, non-prefetchable) [size=4K]
	Region 4: Memory at f7ec0000 (32-bit, non-prefetchable) [size=128K]
	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-

02:05.0 0200: 10b7:1700 (rev 12)
	Subsystem: 1043:80eb
	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: 64 (5750ns min, 7750ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at f7ef8000 (32-bit, non-prefetchable) [size=16K]
	Region 1: I/O ports at d400 [size=256]
	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] Vital Product Data

02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
	Subsystem: 002c:c200
	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, Cache Line Size 0c
	BIST is running
	Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] [size=4K]
	Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] [size=4K]
	Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
	Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
	Region 5: Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled]
	Expansion ROM at e9b01000 [disabled] [size=4K]

02:0c.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0014
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at e9bfe000 (32-bit, prefetchable) [size=4K]

02:0d.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0024
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 20
	Region 0: Memory at e9bfd000 (32-bit, prefetchable) [size=4K]


[-- Attachment #3: lspci-2.6.20.txt --]
[-- Type: text/plain, Size: 10321 bytes --]

00:00.0 0600: 8086:2578 (rev 02)
	Subsystem: 1043:80f6
	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
	Region 0: Memory at ec000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [e4] Vendor Specific Information
	Capabilities: [a0] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 0604: 8086:2579 (rev 02)
	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: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	Memory behind bridge: f1d00000-f3dfffff
	Prefetchable memory behind bridge: d9b00000-e9afffff
	Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:1d.0 0c03: 8086:24d2 (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef00 [size=32]

00:1d.1 0c03: 8086:24d4 (rev 02)
	Subsystem: 1043:80a6
	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 19
	Region 4: I/O ports at ef20 [size=32]

00:1d.2 0c03: 8086:24d7 (rev 02)
	Subsystem: 1043:80a6
	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 17
	Region 4: I/O ports at ef40 [size=32]

00:1d.3 0c03: 8086:24de (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef80 [size=32]

00:1d.7 0c03: 8086:24dd (rev 02) (prog-if 20)
	Subsystem: 1043:80a6
	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 D routed to IRQ 18
	Region 0: Memory at f7fffc00 (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 c2)
	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=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: f3e00000-f7efffff
	Prefetchable memory behind bridge: e9b00000-e9bfffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR+
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 0601: 8086:24d0 (rev 02)
	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

00:1f.1 0101: 8086:24db (rev 02) (prog-if 8a)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at 01f0 [size=8]
	Region 1: I/O ports at 03f4 [size=1]
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374 [size=1]
	Region 4: I/O ports at fc00 [size=16]
	Region 5: Memory at 30000000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 0101: 8086:24d1 (rev 02) (prog-if 8f)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at efe0 [size=8]
	Region 1: I/O ports at efac [size=4]
	Region 2: I/O ports at efa0 [size=8]
	Region 3: I/O ports at efa8 [size=4]
	Region 4: I/O ports at ef60 [size=16]

00:1f.3 0c05: 8086:24d3 (rev 02)
	Subsystem: 1043:80a6
	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 20
	Region 4: I/O ports at 0400 [size=32]

00:1f.5 0401: 8086:24d5 (rev 02)
	Subsystem: 1043:80f3
	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 0: I/O ports at e800 [size=256]
	Region 1: I/O ports at ee80 [size=64]
	Region 2: Memory at f7fff800 (32-bit, non-prefetchable) [size=512]
	Region 3: Memory at f7fff400 (32-bit, non-prefetchable) [size=256]
	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-

01:00.0 0300: 10de:0181 (rev c1)
	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: 64 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at f3de0000 [disabled] [size=128K]
	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: [44] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10)
	Subsystem: 1043:808a
	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: 64 (8000ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at f7eff800 (32-bit, non-prefetchable) [size=2K]
	Region 1: I/O ports at dc00 [size=128]
	Capabilities: [50] 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-

02:04.0 0104: 105a:3373 (rev 02)
	Subsystem: 1043:80f5
	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: 96 (1000ns min, 4500ns max), Cache Line Size 90
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at df00 [size=64]
	Region 1: I/O ports at dfa0 [size=16]
	Region 2: I/O ports at d880 [size=128]
	Region 3: Memory at f7efe000 (32-bit, non-prefetchable) [size=4K]
	Region 4: Memory at f7ec0000 (32-bit, non-prefetchable) [size=128K]
	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-

02:05.0 0200: 10b7:1700 (rev 12)
	Subsystem: 1043:80eb
	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: 64 (5750ns min, 7750ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at f7ef8000 (32-bit, non-prefetchable) [size=16K]
	Region 1: I/O ports at d400 [size=256]
	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] Vital Product Data

02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
	Subsystem: 002c:4200
	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, Cache Line Size 0c
	Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] [size=4K]
	Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] [size=4K]
	Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
	Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
	Region 5: Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled] [size=32]
	Expansion ROM at e9b01000 [disabled] [size=4K]

02:0c.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0014
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at e9bfe000 (32-bit, prefetchable) [size=4K]

02:0d.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0024
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e9bfd000 (32-bit, prefetchable) [size=4K]

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

On 2/5/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Hi,
>
> I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
> the message is slightly different in 2.6.17.7)
>
> PCI Cannot allocate resource region 2 of device 0000:02:0a.0
Just did a search about this message around the kernel source tree.
The interesting thing is that I see the following comments at several
different arch/drivers files. Is it related to your problem?

 *  Known BIOS problems we have to work around:
 *      - I/O or memory regions not configured
 *      - regions configured, but not enabled in the command register
 *      - bogus I/O addresses above 64K used
  *      - expansion ROMs left enabled (this may sound harmless, but given
  *        the fact the PCI specs explicitly allow address decoders to be
  *        shared between expansion ROMs and other resource regions, it's
 *        at least dangerous)

Re: 2.6.20 PCI Cannot allocate resource region 2

[H. Peter Anvin]

Luming Yu wrote:
> 
> *  Known BIOS problems we have to work around:
> *      - bogus I/O addresses above 64K used

On non-x86 architectures this might be just fine.

	-hpa

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/5/07, Luming Yu <luming.yu@gmail.com> wrote:
> On 2/5/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> > Hi,
> >
> > I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
> > the message is slightly different in 2.6.17.7)
> >
> > PCI Cannot allocate resource region 2 of device 0000:02:0a.0
> Just did a search about this message around the kernel source tree.
> The interesting thing is that I see the following comments at several
> different arch/drivers files. Is it related to your problem?
>
>  *  Known BIOS problems we have to work around:
>  *      - I/O or memory regions not configured
>  *      - regions configured, but not enabled in the command register
>  *      - bogus I/O addresses above 64K used
>   *      - expansion ROMs left enabled (this may sound harmless, but given
>   *        the fact the PCI specs explicitly allow address decoders to be
>   *        shared between expansion ROMs and other resource regions, it's
>  *        at least dangerous)
>

The card supports I/O addresses above 64k, i think. It has a PCMCIA
slot as well on it, allowing access to the same

I have put my dmesg over here http://kromtek.com/dvb/dmesg.txt It
looks like lot of workarounds in my BIOS to me probably, couldn't
really make out much in there

The bridge features from the vendor are like this ..

PCI 2.2 Compatible
DVB Common Interface EN50221 Compliant
Philips I2C 2.0 Compliant
Master mode
UART – RS232
Receiver mode
Support PTC PT2225
TSMC 0.25um 5M1P CMOS Technology
PQFP 144 Package

2.5V Core / 3.3V IO
2660x2560 um2
100K Gate
4 Clock Domains
99.6% ATPG Test Coverage
32 scan chains

Implementation
Logical
Logic synthesis – Synopsys 2003.12-SP1
Test synthesis – Synopsys DFTC 2003.12-SP1
Physical
P&R – Synopsys Astro 2003.06-SP2

Verification
Logical
Simulation – Cadence NCsim 5.1
Physical
DRC/LVS – Synopsys Hercules 2003.12


DVB Common Interface EN50221 Compliant
Memory Mode
CIS
Support 8/16 bit
IO Mode
Indirect Read/Write
Issue address and data thru PCI local register
Pseudo GPIO Pins
A12/A13/A14

Common Access (CA)
Card reader – 7816 compliant
DVB CSA / B-CAS Multi2
PID/session filters

UART
Receiver mode only – 6 bits data
Configurable BAUD rate
9600 to 115.2K
16 Word FIFO
I2C
Master mode only
400k/s default



One of the things that really confused me was, on 2.6.17.7 in lspci it
always shows BIST is running. on 2.6.20, it is not there at all.

If this is a bug in the BIOS, i am wondering how the older revisions
of the same bridge works. The last two devices in that lspci output
are Rev 01 devices


Regards,
Manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Mon, Feb 05, 2007 at 05:09:01AM +0400, Manu Abraham wrote:
> Hi,
> 
> I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
> the message is slightly different in 2.6.17.7)
> 
> PCI Cannot allocate resource region 2 of device 0000:02:0a.0
> PCI Error while updating region 000:02:0a.0/5 (f3e00004 != 0200)
> PCI Error while updating region 000:02:0a.0/5 (high 00000000 != 4e351)

...
> The last 2 devices are Rev 1 chips, whereas the one which is acting a
> bit strange is a newer version from the same vendor.

> Any ideas as to why it could not allocate the region ?

Looks like the HW is broken.


This bridge:

> 00:1e.0 0604: 8086:244e (rev c2)
> 	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=02, subordinate=02, sec-latency=64
> 	I/O behind bridge: 0000d000-0000dfff
> 	Memory behind bridge: f3e00000-f7efffff
> 	Prefetchable memory behind bridge: e9b00000-e9bfffff
> 	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR+
> 	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

will only route 0xf3e... to 0xf7efff... 
The attempt to assign f3e00004 is just trying to put a valid value in the BAR.
So I think linux is _trying_ to DTRT.

> 02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
> 	Subsystem: 002c:c200
> 	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, Cache Line Size 0c
> 	BIST is running

BIST is required to complete in 2 seconds. Either with success or failure.
I expect BIOS to have complained before launching grub/lilo.
You might look for that on the next reboot and if possible use a
serial console to log all output or look for BIOS warnings or
logged "events".

But all bets are off regarding programming the device as
long as BIST is running. The only PCI requirement is the device
not interfere with "operation of other devices on the bus".


> 	Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] [size=4K]
> 	Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] [size=4K]
> 	Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> 	Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> 	Region 5: Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled]

This is obviously garbage. 64-bit registers can only be represented with
two consecutive "BAR" and region 5 is the last one.
There is no way this can be a 64-bit BAR.
Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
again if that's just convention or a requirement)

hth,
grant

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
...
> > 	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, Cache Line Size 0c
> > 	BIST is running
> 
> BIST is required to complete in 2 seconds. Either with success or failure.
> I expect BIOS to have complained before launching grub/lilo.

Gregkh,
I just realized linux-pci bus scan should ignore devices (print a warning)
which have BIST set.  Want a patch for this?

Slight risk some previously "working" device which violates the
spec might get ignored...but I hope there aren't too many of those.

grant

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Mon, Feb 05, 2007 at 05:09:01AM +0400, Manu Abraham wrote:
> > Hi,
> >
> > I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
> > the message is slightly different in 2.6.17.7)
> >
> > PCI Cannot allocate resource region 2 of device 0000:02:0a.0
> > PCI Error while updating region 000:02:0a.0/5 (f3e00004 != 0200)
> > PCI Error while updating region 000:02:0a.0/5 (high 00000000 != 4e351)
>
> ...
> > The last 2 devices are Rev 1 chips, whereas the one which is acting a
> > bit strange is a newer version from the same vendor.
>
> > Any ideas as to why it could not allocate the region ?
>
> Looks like the HW is broken.


ah, was thinking about this. :-)


> This bridge:
>
> > 00:1e.0 0604: 8086:244e (rev c2)
> >       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=02, subordinate=02, sec-latency=64
> >       I/O behind bridge: 0000d000-0000dfff
> >       Memory behind bridge: f3e00000-f7efffff
> >       Prefetchable memory behind bridge: e9b00000-e9bfffff
> >       Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR+
> >       BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
>
> will only route 0xf3e... to 0xf7efff...
> The attempt to assign f3e00004 is just trying to put a valid value in the BAR.
> So I think linux is _trying_ to DTRT.
>
> > 02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
> >       Subsystem: 002c:c200
> >       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, Cache Line Size 0c
> >       BIST is running
>
> BIST is required to complete in 2 seconds. Either with success or failure.
> I expect BIOS to have complained before launching grub/lilo.


BIOS didn't say anything at all.


> You might look for that on the next reboot and if possible use a
> serial console to log all output or look for BIOS warnings or
> logged "events".
> But all bets are off regarding programming the device as
> long as BIST is running. The only PCI requirement is the device
> not interfere with "operation of other devices on the bus".
>

BIST is supposed to terminate before, say the OS kernel is loaded ? or
does it mean that it  can keep running still ?

>
> >       Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] [size=4K]
> >       Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] [size=4K]
> >       Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> >       Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> >       Region 5: Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled]
>
> This is obviously garbage. 64-bit registers can only be represented with
> two consecutive "BAR" and region 5 is the last one.
> There is no way this can be a 64-bit BAR.
> Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
> again if that's just convention or a requirement)
>

was just wondering how it could be a 64 bit device.

> hth,
> grant
>


Thanks a lot for the valuable info. I had not ruled out the option
that it could be broken.
I will try the device in the other OS also, to confirm this. Will post
the status after that.
But most probably as you said, could be broken.

Thanks,
Manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Andrew Morton]

On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:

> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> ...
> > > 	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, Cache Line Size 0c
> > > 	BIST is running
> > 
> > BIST is required to complete in 2 seconds. Either with success or failure.
> > I expect BIOS to have complained before launching grub/lilo.
> 
> Gregkh,
> I just realized linux-pci bus scan should ignore devices (print a warning)
> which have BIST set.  Want a patch for this?
> 
> Slight risk some previously "working" device which violates the
> spec might get ignored...but I hope there aren't too many of those.

Should we wait two seconds before declaring the device dead?  To see whether
it will come back?

Re: 2.6.20 PCI Cannot allocate resource region 2

[Greg KH]

On Mon, Feb 05, 2007 at 10:03:31PM -0700, Grant Grundler wrote:
> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> ...
> > > 	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, Cache Line Size 0c
> > > 	BIST is running
> > 
> > BIST is required to complete in 2 seconds. Either with success or failure.
> > I expect BIOS to have complained before launching grub/lilo.
> 
> Gregkh,
> I just realized linux-pci bus scan should ignore devices (print a warning)
> which have BIST set.  Want a patch for this?

Yes, that would be good.

> Slight risk some previously "working" device which violates the
> spec might get ignored...but I hope there aren't too many of those.

Odds are there are probably _way_ too many devices, but it can't hurt to
at least flag them as a broken card so that they can be fixed in the
future...

thanks,

greg k-h

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
>
> > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > ...
> > > >   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, Cache Line Size 0c
> > > >   BIST is running
> > >
> > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > I expect BIOS to have complained before launching grub/lilo.
> >
> > Gregkh,
> > I just realized linux-pci bus scan should ignore devices (print a warning)
> > which have BIST set.  Want a patch for this?
> >
> > Slight risk some previously "working" device which violates the
> > spec might get ignored...but I hope there aren't too many of those.
>
> Should we wait two seconds before declaring the device dead?  To see whether
> it will come back?
>


Wonders !

I was about to give the card it's last rites. I thought well let me
try under the other OS

I didn't have any drivers for the same, since the demodulator driver
doesn't exist in the other OS also, but the bridge device does have
the driver.

I plugged the card in, the OS searched for drivers, since i didn't
have any didn't load any..
So it went under a question mark.

Looking under Resources,

It showed the PCI information string like this ..

PCI\VEN_1822&DEV_4E35&SUBSYS_00311822&REV_01\4&2E98101C&0&10F0

then i thought try with the driver eventhough support for the
demodulator doesn't exist ..

Downloaded and installed drivers ..

Lo ..!

Memory Range: F87FF000 - F87FFFFF
IRQ : 17

it got assigned a memory region indeed.

So, to wrap it up, the device is not dead .. We have something wrong
in the PCI subsystem probably.


Regards,
Manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote:
> On 2/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler 
> ><grundler@parisc-linux.org> wrote:
> >
> >> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> >> ...
> >> > >   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, Cache Line Size 0c
> >> > >   BIST is running
> >> >
> >> > BIST is required to complete in 2 seconds. Either with success or 
> >failure.
> >> > I expect BIOS to have complained before launching grub/lilo.
> >>
> >> Gregkh,
> >> I just realized linux-pci bus scan should ignore devices (print a 
> >warning)
> >> which have BIST set.  Want a patch for this?
> >>
> >> Slight risk some previously "working" device which violates the
> >> spec might get ignored...but I hope there aren't too many of those.
> >
> >Should we wait two seconds before declaring the device dead?  To see 
> >whether
> >it will come back?
> >
> 
> 
> Wonders !
> 
> I was about to give the card it's last rites. I thought well let me
> try under the other OS

Could you be more specific? Which OS? FreeBSD? :)


> I didn't have any drivers for the same, since the demodulator driver
> doesn't exist in the other OS also, but the bridge device does have
> the driver.
> 
> I plugged the card in, the OS searched for drivers, since i didn't
> have any didn't load any..
> So it went under a question mark.
> 
> Looking under Resources,
> 
> It showed the PCI information string like this ..
> 
> PCI\VEN_1822&DEV_4E35&SUBSYS_00311822&REV_01\4&2E98101C&0&10F0
> 
> then i thought try with the driver eventhough support for the
> demodulator doesn't exist ..
> 
> Downloaded and installed drivers ..
> 
> Lo ..!
> 
> Memory Range: F87FF000 - F87FFFFF
> IRQ : 17
> 
> it got assigned a memory region indeed.

Excellent.

> So, to wrap it up, the device is not dead .. We have something wrong
> in the PCI subsystem probably.

Hrm maybe but not likely. I'm more inclined to believe PCI subsystem
is missing hacks needed for that device and/or BIOS.

grant

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote:
> > On 2/6/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler
> > ><grundler@parisc-linux.org> wrote:
> > >
> > >> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > >> ...
> > >> > >   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, Cache Line Size 0c
> > >> > >   BIST is running
> > >> >
> > >> > BIST is required to complete in 2 seconds. Either with success or
> > >failure.
> > >> > I expect BIOS to have complained before launching grub/lilo.
> > >>
> > >> Gregkh,
> > >> I just realized linux-pci bus scan should ignore devices (print a
> > >warning)
> > >> which have BIST set.  Want a patch for this?
> > >>
> > >> Slight risk some previously "working" device which violates the
> > >> spec might get ignored...but I hope there aren't too many of those.
> > >
> > >Should we wait two seconds before declaring the device dead?  To see
> > >whether
> > >it will come back?
> > >
> >
> >
> > Wonders !
> >
> > I was about to give the card it's last rites. I thought well let me
> > try under the other OS
>
> Could you be more specific? Which OS? FreeBSD? :)
>


Hehe, we don't get question marks and stuff like that for those OS 's .. ;-)

M$ XP SP2


>
> > I didn't have any drivers for the same, since the demodulator driver
> > doesn't exist in the other OS also, but the bridge device does have
> > the driver.
> >
> > I plugged the card in, the OS searched for drivers, since i didn't
> > have any didn't load any..
> > So it went under a question mark.
> >
> > Looking under Resources,
> >
> > It showed the PCI information string like this ..
> >
> > PCI\VEN_1822&DEV_4E35&SUBSYS_00311822&REV_01\4&2E98101C&0&10F0
> >
> > then i thought try with the driver eventhough support for the
> > demodulator doesn't exist ..
> >
> > Downloaded and installed drivers ..
> >
> > Lo ..!
> >
> > Memory Range: F87FF000 - F87FFFFF
> > IRQ : 17
> >
> > it got assigned a memory region indeed.
>
> Excellent.
>
> > So, to wrap it up, the device is not dead .. We have something wrong
> > in the PCI subsystem probably.
>
> Hrm maybe but not likely. I'm more inclined to believe PCI subsystem
> is missing hacks needed for that device and/or BIOS.
>

I have access to the source there, but there are no PCI specific
stuff, i think the NT HAL just handles all the PCI stuff over there.

It would be great , if we could have the missing hacks under Linux as well.

> grant
>

regards,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
...
> >BIST is required to complete in 2 seconds. Either with success or failure.
> >I expect BIOS to have complained before launching grub/lilo.
...
> BIST is supposed to terminate before, say the OS kernel is loaded?

Yes - that's what I was trying to imply above.

> or does it mean that it can keep running still ?

Don't know. Either it's still running (for much longer that 2 seconds),
linux is causing it run _again_, or linux is has terribly confused the
device somehow. More on this in an email I'm still working on...will
send that out in a bit.

> >>       Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] 
> >[size=4K]
> >>       Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] 
> >[size=4K]
> >>       Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> >>       Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> >>       Region 5: Memory at <invalid-64bit-slot> (64-bit, 
> >non-prefetchable) [disabled]
> >
> >This is obviously garbage. 64-bit registers can only be represented with
> >two consecutive "BAR" and region 5 is the last one.
> >There is no way this can be a 64-bit BAR.
> >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
> >again if that's just convention or a requirement)
> >
> 
> was just wondering how it could be a 64 bit device.

64-bit BAR is seperate from 64-bit Device (data path).

PCI has three different 32 vs 64-bit areas:
o BARs
o DMA 
o HW/data path width.

"32-bit device" generally only refers to the latter.
The three attributes are generally all "32-bit" for "32-bit device".

That's less likely to be true for "64-bit devices". Several "64-bit
devices" can only DMA to 32-bit host memory and at least a few only
support 32-bit BARs (even if the device claims it has a 64-bit BAR).

hth,
grant

> 
> >hth,
> >grant
> >
> 
> 
> Thanks a lot for the valuable info. I had not ruled out the option
> that it could be broken.
> I will try the device in the other OS also, to confirm this. Will post
> the status after that.
> But most probably as you said, could be broken.
> 
> Thanks,
> Manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> 
> > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > ...
> > > > 	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, Cache Line Size 0c
> > > > 	BIST is running
> > > 
> > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > I expect BIOS to have complained before launching grub/lilo.
> > 
> > Gregkh,
> > I just realized linux-pci bus scan should ignore devices (print a warning)
> > which have BIST set.  Want a patch for this?
> > 
> > Slight risk some previously "working" device which violates the
> > spec might get ignored...but I hope there aren't too many of those.
> 
> Should we wait two seconds before declaring the device dead?
> To see whether it will come back?

Hrm...my thought was BIOS should already be doing that...but I just
realised 2 seconds have elapsed if Manu can collect "lspci" output showing
"BIST is running". I think the fact that BIST is not "running" in the
2.6.20-rc7 lspci output is just coincidental. The config space for that
device is full of similar garbage in both cases regardless how long
it took.

Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
register and BIOS is not being careful to clear or disable the other
bytes in that same 32-bit word?

PCI is by nature a 32-bit wide config space and "byte enables"
are used to mask off bytes we want to ignore.  If the chipset
or BIOS config access routines aren't careful, they could accidentally
modify other values in the same 32-bit word when only one byte was
intended to be changed.

The code in pci_set_cacheline_size() uses byte enables but is only
called by pci_set_mwi(). 82 different .c files (124 instances) access
PCI_LATENCY_TIMER.  Of those, 68 are pci_write_config_byte() calls.
But I really only care about the calls what would apply get invoked
for 1822:4e35. My guess is this one always gets invoked:
  ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);

since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
(http://pci-ids.ucw.cz/iii/?i=1822)
pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().

Manu, can you add code to pci_enable_bridges() to dump information about
which bridges are getting enabled _before_ pci_set_master() is called?

I'm interested in a hex dump of the first 8  32-bit words of
PCI config space for each device.


BTW, I wasn't planning declaring the device as dead. I just wanted to
pretend it didn't exist and then let something else (user space? timeout?)
trigger a rescan of that bus/"slot". That trigger could come in a successive
patch which also removes the 2 second polling loop.

grant

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
> ...
> > >BIST is required to complete in 2 seconds. Either with success or failure.
> > >I expect BIOS to have complained before launching grub/lilo.
> ...
> > BIST is supposed to terminate before, say the OS kernel is loaded?
>
> Yes - that's what I was trying to imply above.
>
> > or does it mean that it can keep running still ?
>
> Don't know. Either it's still running (for much longer that 2 seconds),
> linux is causing it run _again_, or linux is has terribly confused the
> device somehow. More on this in an email I'm still working on...will
> send that out in a bit.

i think probably, Linux is causing it to run again .. ?


> > >>       Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled]
> > >[size=4K]
> > >>       Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled]
> > >[size=4K]
> > >>       Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> > >>       Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> > >>       Region 5: Memory at <invalid-64bit-slot> (64-bit,
> > >non-prefetchable) [disabled]
> > >
> > >This is obviously garbage. 64-bit registers can only be represented with
> > >two consecutive "BAR" and region 5 is the last one.
> > >There is no way this can be a 64-bit BAR.
> > >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
> > >again if that's just convention or a requirement)
> > >
> >
> > was just wondering how it could be a 64 bit device.
>
> 64-bit BAR is seperate from 64-bit Device (data path).
>
> PCI has three different 32 vs 64-bit areas:
> o BARs
> o DMA
> o HW/data path width.
>
> "32-bit device" generally only refers to the latter.
> The three attributes are generally all "32-bit" for "32-bit device".


According to the information i have on this device ..

Configuration Register 00H : Device_ID / Vendor_ID Register
Bit [31:16] R Device_ID Device ID = 16'h4e35
Bit [15:0] R Vendor_ID Vendor ID = 16'h1822

Configuration Register 04H : Status / Command Register
Bit 31 R Detpar_rpt Detect Parity Report
Bit 30 W/R System_err Indicate System Error
Bit 29 R Master_abort Indicate Master Abort
Bit 28 R Target_abort Indicate Target Abort
Bit [27:25] Default = 3'b001
Bit 24 R Datapar_rpt Data Parity Report
Bit [23:20] Default = 4'b0000
Bit [19:16] Default = 4'b0000
Bit [15:9] Default = 7'h0
Bit 8 W/R Pci_serr_en PCI system error enable
Bit 7 Default = 1'b0
Bit 6 W/R Pci_perr_en PCI parity error enable
Bit [5:3] Default = 3'h0
Bit 2 W/R Pci_master_en PCI master mode enable
Bit 1 W/R Pci_target_en PCI target mode enable
Bit 0 Default = 1'b0

Configuration Register 08H : Class_Code / Revision_ID Register
Bit [31:8] R Class_Code Class_Code = 24'h048000
Bit [7:0] R Revision_ID Revision_ID = 8'h01

Configuration Register 0CH : Latency Timer Register
Bit [31:16] Default = 16'h0
Bit [15:11] W/R Pci_lat_timer Indicate PCI latency timer
Bit [10:8] Default = 3'h0
Bit [7:0] Default = 8'b0

Configuration Register 10H : Base_Address / Memory&Prep Register
Bit [31:12] W/R Pci_base_addr Indicate PCI Base Address
Bit [31:0] R Default = 12'h008

Configuration Register 2CH : I2C Subsystem_ID / Subsystem_Vendor_ID Register
Bit [31:0] W/R I2c_ssid_ssvid Indicate I2C subsystem_ID / subsystem_vendor_ID

Configuration Register 38H : Test PCI Connection Register
Bit [31:0] W/R Test_pci_conn Indicate to test PCI connection

Configuration Register 3CH : Max_Latency / Min_Gnt / Int_Pin / Int_Line Register
Bit [31:24] W Max_lat Default = 8'hFF
Bit [23:16] W Min_gnt Default = 8'h08
Bit [15:8] W Int_pin Default = 8'h01
Bit [7:0] W/R Int_line Indicate interrupt line



> That's less likely to be true for "64-bit devices". Several "64-bit
> devices" can only DMA to 32-bit host memory and at least a few only
> support 32-bit BARs (even if the device claims it has a 64-bit BAR).
>


AFAIK, the device does 32 bit DMA, but it is not completely hardware driven DMA.
it just uses a RISC core which just jumps to the pointer allocated in software.

The other devices using the same chip, works that way.

> hth,
> grant


thanks,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> >
> > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > > ...
> > > > >         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, Cache Line Size 0c
> > > > >         BIST is running
> > > >
> > > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > > I expect BIOS to have complained before launching grub/lilo.
> > >
> > > Gregkh,
> > > I just realized linux-pci bus scan should ignore devices (print a warning)
> > > which have BIST set.  Want a patch for this?
> > >
> > > Slight risk some previously "working" device which violates the
> > > spec might get ignored...but I hope there aren't too many of those.
> >
> > Should we wait two seconds before declaring the device dead?
> > To see whether it will come back?
>
> Hrm...my thought was BIOS should already be doing that...but I just
> realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> "BIST is running". I think the fact that BIST is not "running" in the
> 2.6.20-rc7 lspci output is just coincidental. The config space for that
> device is full of similar garbage in both cases regardless how long
> it took.
>

waited for more than 30 mins as well, well almost the entire night,
BIST didn't stop


> Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> register and BIOS is not being careful to clear or disable the other
> bytes in that same 32-bit word?
>


If the BIOS is clobbering the BIST, then the same should happen in the
other OS as well ?
Just plugging in the card, without any drivers, got me the PCI vendor info.


> PCI is by nature a 32-bit wide config space and "byte enables"
> are used to mask off bytes we want to ignore.  If the chipset
> or BIOS config access routines aren't careful, they could accidentally
> modify other values in the same 32-bit word when only one byte was
> intended to be changed.
>
> The code in pci_set_cacheline_size() uses byte enables but is only
> called by pci_set_mwi(). 82 different .c files (124 instances) access
> PCI_LATENCY_TIMER.  Of those, 68 are pci_write_config_byte() calls.
> But I really only care about the calls what would apply get invoked
> for 1822:4e35. My guess is this one always gets invoked:
>   ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
>
> since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> (http://pci-ids.ucw.cz/iii/?i=1822)
> pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
>
> Manu, can you add code to pci_enable_bridges() to dump information about
> which bridges are getting enabled _before_ pci_set_master() is called?
> I'm interested in a hex dump of the first 8  32-bit words of
> PCI config space for each device.
>

let me give it a shot.


> BTW, I wasn't planning declaring the device as dead. I just wanted to
> pretend it didn't exist and then let something else (user space? timeout?)
> trigger a rescan of that bus/"slot". That trigger could come in a successive
> patch which also removes the 2 second polling loop.

maybe the driver can do a rescan ?

>
> grant
>


thanks,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

[-- Attachment #1: Type: text/plain, Size: 3703 bytes --]

On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> > >
> > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > > > ...
> > > > > >         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, Cache Line Size 0c
> > > > > >         BIST is running
> > > > >
> > > > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > > > I expect BIOS to have complained before launching grub/lilo.
> > > >
> > > > Gregkh,
> > > > I just realized linux-pci bus scan should ignore devices (print a warning)
> > > > which have BIST set.  Want a patch for this?
> > > >
> > > > Slight risk some previously "working" device which violates the
> > > > spec might get ignored...but I hope there aren't too many of those.
> > >
> > > Should we wait two seconds before declaring the device dead?
> > > To see whether it will come back?
> >
> > Hrm...my thought was BIOS should already be doing that...but I just
> > realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> > "BIST is running". I think the fact that BIST is not "running" in the
> > 2.6.20-rc7 lspci output is just coincidental. The config space for that
> > device is full of similar garbage in both cases regardless how long
> > it took.
> >
>
> waited for more than 30 mins as well, well almost the entire night,
> BIST didn't stop
>
>
> > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> > register and BIOS is not being careful to clear or disable the other
> > bytes in that same 32-bit word?
> >
>
>
> If the BIOS is clobbering the BIST, then the same should happen in the
> other OS as well ?
> Just plugging in the card, without any drivers, got me the PCI vendor info.
>
>
> > PCI is by nature a 32-bit wide config space and "byte enables"
> > are used to mask off bytes we want to ignore.  If the chipset
> > or BIOS config access routines aren't careful, they could accidentally
> > modify other values in the same 32-bit word when only one byte was
> > intended to be changed.
> >
> > The code in pci_set_cacheline_size() uses byte enables but is only
> > called by pci_set_mwi(). 82 different .c files (124 instances) access
> > PCI_LATENCY_TIMER.  Of those, 68 are pci_write_config_byte() calls.
> > But I really only care about the calls what would apply get invoked
> > for 1822:4e35. My guess is this one always gets invoked:
> >   ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> >
> > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> > (http://pci-ids.ucw.cz/iii/?i=1822)
> > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
> >
> > Manu, can you add code to pci_enable_bridges() to dump information about
> > which bridges are getting enabled _before_ pci_set_master() is called?
> > I'm interested in a hex dump of the first 8  32-bit words of
> > PCI config space for each device.
> >
>
> let me give it a shot.



dang !

rebooted it into 2.6.17.7

no errors, during a bootup, BIST isn't running anymore
running M$ did change the status from dead to alive ??? shocked !!

attached lspci output in the very same setup as earlier, no difference
in anything, except that it was rebooted into windows.

the PCI config dump would help ?


regards,
manu

[-- Attachment #2: lspci_working.txt --]
[-- Type: text/plain, Size: 9220 bytes --]

00:00.0 0600: 8086:2578 (rev 02)
	Subsystem: 1043:80f6
	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
	Region 0: Memory at f4000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [e4] Vendor Specific Information
	Capabilities: [a0] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 0604: 8086:2579 (rev 02)
	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: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	Memory behind bridge: fc900000-fe9fffff
	Prefetchable memory behind bridge: dfe00000-efdfffff
	Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:1d.0 0c03: 8086:24d2 (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef00 [size=32]

00:1d.1 0c03: 8086:24d4 (rev 02)
	Subsystem: 1043:80a6
	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 19
	Region 4: I/O ports at ef20 [size=32]

00:1d.2 0c03: 8086:24d7 (rev 02)
	Subsystem: 1043:80a6
	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 17
	Region 4: I/O ports at ef40 [size=32]

00:1d.3 0c03: 8086:24de (rev 02)
	Subsystem: 1043:80a6
	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 16
	Region 4: I/O ports at ef80 [size=32]

00:1d.7 0c03: 8086:24dd (rev 02) (prog-if 20)
	Subsystem: 1043:80a6
	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 D routed to IRQ 18
	Region 0: Memory at febffc00 (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 c2)
	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=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fea00000-feafffff
	Prefetchable memory behind bridge: efe00000-efefffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 0601: 8086:24d0 (rev 02)
	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

00:1f.1 0101: 8086:24db (rev 02) (prog-if 8a)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at 01f0 [size=8]
	Region 1: I/O ports at 03f4 [size=1]
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374 [size=1]
	Region 4: I/O ports at fc00 [size=16]
	Region 5: Memory at 30000000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 0101: 8086:24d1 (rev 02) (prog-if 8f)
	Subsystem: 1043:80a6
	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 17
	Region 0: I/O ports at efe0 [size=8]
	Region 1: I/O ports at efac [size=4]
	Region 2: I/O ports at efa0 [size=8]
	Region 3: I/O ports at efa8 [size=4]
	Region 4: I/O ports at ef60 [size=16]

00:1f.3 0c05: 8086:24d3 (rev 02)
	Subsystem: 1043:80a6
	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 20
	Region 4: I/O ports at 0400 [size=32]

00:1f.5 0401: 8086:24d5 (rev 02)
	Subsystem: 1043:80f3
	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 0: I/O ports at e800 [size=256]
	Region 1: I/O ports at ee80 [size=64]
	Region 2: Memory at febff800 (32-bit, non-prefetchable) [size=512]
	Region 3: Memory at febff400 (32-bit, non-prefetchable) [size=256]
	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-

01:00.0 0300: 10de:0181 (rev c1)
	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: 64 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at fe9e0000 [disabled] [size=128K]
	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: [44] AGP version 3.0
		Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10)
	Subsystem: 1043:808a
	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: 64 (8000ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at feaff800 (32-bit, non-prefetchable) [size=2K]
	Region 1: I/O ports at dc00 [size=128]
	Capabilities: [50] 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-

02:05.0 0200: 10b7:1700 (rev 12)
	Subsystem: 1043:80eb
	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: 64 (5750ns min, 7750ns max), Cache Line Size 04
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at feaf8000 (32-bit, non-prefetchable) [size=16K]
	Region 1: I/O ports at d800 [size=256]
	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] Vital Product Data

02:0a.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0031
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at efeff000 (32-bit, prefetchable) [size=4K]

02:0c.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0014
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at efefe000 (32-bit, prefetchable) [size=4K]

02:0d.0 0480: 1822:4e35 (rev 01)
	Subsystem: 1822:0024
	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: 64 (2000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at efefd000 (32-bit, prefetchable) [size=4K]

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> >
> > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > > ...
> > > > >         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, Cache Line Size 0c
> > > > >         BIST is running
> > > >
> > > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > > I expect BIOS to have complained before launching grub/lilo.
> > >
> > > Gregkh,
> > > I just realized linux-pci bus scan should ignore devices (print a warning)
> > > which have BIST set.  Want a patch for this?
> > >
> > > Slight risk some previously "working" device which violates the
> > > spec might get ignored...but I hope there aren't too many of those.
> >
> > Should we wait two seconds before declaring the device dead?
> > To see whether it will come back?
>
> Hrm...my thought was BIOS should already be doing that...but I just
> realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> "BIST is running". I think the fact that BIST is not "running" in the
> 2.6.20-rc7 lspci output is just coincidental. The config space for that
> device is full of similar garbage in both cases regardless how long
> it took.
>
> Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> register and BIOS is not being careful to clear or disable the other
> bytes in that same 32-bit word?
>
> PCI is by nature a 32-bit wide config space and "byte enables"
> are used to mask off bytes we want to ignore.  If the chipset
> or BIOS config access routines aren't careful, they could accidentally
> modify other values in the same 32-bit word when only one byte was
> intended to be changed.
>
> The code in pci_set_cacheline_size() uses byte enables but is only
> called by pci_set_mwi(). 82 different .c files (124 instances) access
> PCI_LATENCY_TIMER.  Of those, 68 are pci_write_config_byte() calls.
> But I really only care about the calls what would apply get invoked
> for 1822:4e35. My guess is this one always gets invoked:
>   ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
>
> since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> (http://pci-ids.ucw.cz/iii/?i=1822)
> pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
>
> Manu, can you add code to pci_enable_bridges() to dump information about
> which bridges are getting enabled _before_ pci_set_master() is called?
>
> I'm interested in a hex dump of the first 8  32-bit words of
> PCI config space for each device.
>

attaching a dump of the regs (on 2.6.17.7) as well as the diff

regards,
manu

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 21624 bytes --]

[17179569.184000] Linux version 2.6.17.7 (root@testbox) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #4 SMP PREEMPT Tue Feb 6 14:58:19 GST 2007
[17179569.184000] BIOS-provided physical RAM map:
[17179569.184000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[17179569.184000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[17179569.184000]  BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
[17179569.184000]  BIOS-e820: 0000000000100000 - 000000001ff30000 (usable)
[17179569.184000]  BIOS-e820: 000000001ff30000 - 000000001ff40000 (ACPI data)
[17179569.184000]  BIOS-e820: 000000001ff40000 - 000000001fff0000 (ACPI NVS)
[17179569.184000]  BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
[17179569.184000]  BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
[17179569.184000] 511MB LOWMEM available.
[17179569.184000] found SMP MP-table at 000ff780
[17179569.184000] On node 0 totalpages: 130864
[17179569.184000]   DMA zone: 4096 pages, LIFO batch:0
[17179569.184000]   Normal zone: 126768 pages, LIFO batch:31
[17179569.184000] DMI 2.3 present.
[17179569.184000] ACPI: RSDP (v002 ACPIAM                                ) @ 0x000f9e30
[17179569.184000] ACPI: XSDT (v001 A M I  OEMXSDT  0x01000428 MSFT 0x00000097) @ 0x1ff30100
[17179569.184000] ACPI: FADT (v003 A M I  OEMFACP  0x01000428 MSFT 0x00000097) @ 0x1ff30290
[17179569.184000] ACPI: MADT (v001 A M I  OEMAPIC  0x01000428 MSFT 0x00000097) @ 0x1ff30390
[17179569.184000] ACPI: OEMB (v001 A M I  OEMBIOS  0x01000428 MSFT 0x00000097) @ 0x1ff40040
[17179569.184000] ACPI: DSDT (v001  P4C81 P4C81100 0x00000100 INTL 0x02002026) @ 0x00000000
[17179569.184000] ACPI: PM-Timer IO Port: 0x808
[17179569.184000] ACPI: Local APIC address 0xfee00000
[17179569.184000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[17179569.184000] Processor #0 15:2 APIC version 20
[17179569.184000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[17179569.184000] Processor #1 15:2 APIC version 20
[17179569.184000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[17179569.184000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[17179569.184000] ACPI: IRQ0 used by override.
[17179569.184000] ACPI: IRQ2 used by override.
[17179569.184000] ACPI: IRQ9 used by override.
[17179569.184000] Enabling APIC mode:  Flat.  Using 1 I/O APICs
[17179569.184000] Using ACPI (MADT) for SMP configuration information
[17179569.184000] Allocating PCI resources starting at 30000000 (gap: 20000000:dfb80000)
[17179569.184000] Built 1 zonelists
[17179569.184000] Kernel command line: ro root=LABEL=/ rhgb quiet video=nvidiafb:1280x1024-24@72
[17179569.184000] mapped APIC to ffffd000 (fee00000)
[17179569.184000] mapped IOAPIC to ffffc000 (fec00000)
[17179569.184000] Enabling fast FPU save and restore... done.
[17179569.184000] Enabling unmasked SIMD FPU exception support... done.
[17179569.184000] Initializing CPU#0
[17179569.184000] PID hash table entries: 2048 (order: 11, 8192 bytes)
[17179569.184000] Detected 2799.216 MHz processor.
[17179569.184000] Using pmtmr for high-res timesource
[17179569.184000] Console: colour VGA+ 80x25
[17179570.752000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[17179570.752000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[17179570.760000] Memory: 513624k/523456k available (2219k kernel code, 9248k reserved, 1071k data, 212k init, 0k highmem)
[17179570.760000] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[17179570.840000] Calibrating delay using timer specific routine.. 5602.98 BogoMIPS (lpj=11205967)
[17179570.840000] Mount-cache hash table entries: 512
[17179570.840000] CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
[17179570.840000] CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
[17179570.840000] CPU: Trace cache: 12K uops, L1 D cache: 8K
[17179570.840000] CPU: L2 cache: 512K
[17179570.840000] CPU: Physical Processor ID: 0
[17179570.840000] CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
[17179570.840000] Intel machine check architecture supported.
[17179570.840000] Intel machine check reporting enabled on CPU#0.
[17179570.840000] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
[17179570.840000] CPU0: Thermal monitoring enabled
[17179570.840000] Checking 'hlt' instruction... OK.
[17179570.856000] Freeing SMP alternatives: 16k freed
[17179570.860000] CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
[17179570.860000] Booting processor 1/1 eip 2000
[17179570.868000] Initializing CPU#1
[17179570.952000] Calibrating delay using timer specific routine.. 5597.72 BogoMIPS (lpj=11195443)
[17179570.952000] CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
[17179570.952000] CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
[17179570.952000] CPU: Trace cache: 12K uops, L1 D cache: 8K
[17179570.952000] CPU: L2 cache: 512K
[17179570.952000] CPU: Physical Processor ID: 0
[17179570.952000] CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
[17179570.952000] Intel machine check architecture supported.
[17179570.952000] Intel machine check reporting enabled on CPU#1.
[17179570.952000] CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
[17179570.952000] CPU1: Thermal monitoring enabled
[17179570.952000] CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
[17179570.952000] Total of 2 processors activated (11200.70 BogoMIPS).
[17179570.952000] ENABLING IO-APIC IRQs
[17179570.952000] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[17179571.096000] checking TSC synchronization across 2 CPUs: passed.
[17179571.100000] Brought up 2 CPUs
[17179571.148000] migration_cost=4000
[17179571.148000] checking if image is initramfs... it is
[17179571.224000] Freeing initrd memory: 859k freed
[17179571.224000] NET: Registered protocol family 16
[17179571.224000] ACPI: bus type pci registered
[17179571.224000] PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
[17179571.224000] Setting up standard PCI resources
[17179571.236000] ACPI: Subsystem revision 20060127
[17179571.248000] ACPI: Interpreter enabled
[17179571.248000] ACPI: Using IOAPIC for interrupt routing
[17179571.248000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[17179571.248000] PCI: Probing PCI hardware (bus 00)
[17179571.256000] PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
[17179571.256000] PCI quirk: region 0480-04bf claimed by ICH4 GPIO
[17179571.256000] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
[17179571.256000] Boot video device is 0000:01:00.0
[17179571.256000] PCI: Transparent bridge - 0000:00:1e.0
[17179571.256000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[17179571.280000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
[17179571.296000] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[17179571.296000] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[17179571.296000] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[17179571.296000] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[17179571.296000] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[17179571.300000] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[17179571.300000] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[17179571.300000] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[17179571.300000] Linux Plug and Play Support v0.97 (c) Adam Belay
[17179571.300000] pnp: PnP ACPI init
[17179571.312000] pnp: PnP ACPI: found 15 devices
[17179571.312000] SCSI subsystem initialized
[17179571.312000] PCI: Using ACPI for IRQ routing
[17179571.312000] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[17179571.316000] pnp: 00:0b: ioport range 0x680-0x6ff has been reserved
[17179571.316000] pnp: 00:0b: ioport range 0x290-0x297 has been reserved
[17179571.320000] PCI: Bridge: 0000:00:01.0
[17179571.320000]   IO window: disabled.
[17179571.320000]   MEM window: fc900000-fe9fffff
[17179571.320000]   PREFETCH window: dfe00000-efdfffff
[17179571.320000] PCI: Bridge: 0000:00:1e.0
[17179571.320000]   IO window: d000-dfff
[17179571.320000]   MEM window: fea00000-feafffff
[17179571.320000]   PREFETCH window: efe00000-efefffff
[17179571.320000] pci_enable_bridges: devfn=0x0008, vendor=0x8086, device=0x2579, sub_vendor=0x00, sub_device=0x00
[17179571.320000] pci_enable_bridges: cfg_size=0x100, irq=0x00, hdr_type=0x01, rom_base_reg=0x38, pin=0x00
[17179571.320000] pci_enable_bridges: i=0x00, Reg=0x25798086
[17179571.320000] pci_enable_bridges: i=0x01, Reg=0x25798086
[17179571.320000] pci_enable_bridges: i=0x02, Reg=0x25798086
[17179571.320000] pci_enable_bridges: i=0x03, Reg=0x25798086
[17179571.320000] pci_enable_bridges: i=0x04, Reg=0x00a00107
[17179571.320000] pci_enable_bridges: i=0x05, Reg=0x00a00107
[17179571.320000] pci_enable_bridges: i=0x06, Reg=0x00a00107
[17179571.320000] pci_enable_bridges: i=0x07, Reg=0x00a00107
[17179571.320000] pci_enable_bridges: i=0x08, Reg=0x06040002
[17179571.320000] pci_enable_bridges: devfn=0x00f0, vendor=0x8086, device=0x244e, sub_vendor=0x00, sub_device=0x00
[17179571.320000] pci_enable_bridges: cfg_size=0x100, irq=0x00, hdr_type=0x01, rom_base_reg=0x38, pin=0x00
[17179571.320000] pci_enable_bridges: i=0x00, Reg=0x244e8086
[17179571.320000] pci_enable_bridges: i=0x01, Reg=0x244e8086
[17179571.320000] pci_enable_bridges: i=0x02, Reg=0x244e8086
[17179571.320000] pci_enable_bridges: i=0x03, Reg=0x244e8086
[17179571.320000] pci_enable_bridges: i=0x04, Reg=0x00800107
[17179571.320000] pci_enable_bridges: i=0x05, Reg=0x00800107
[17179571.320000] pci_enable_bridges: i=0x06, Reg=0x00800107
[17179571.320000] pci_enable_bridges: i=0x07, Reg=0x00800107
[17179571.320000] pci_enable_bridges: i=0x08, Reg=0x060400c2
[17179571.320000] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[17179571.320000] NET: Registered protocol family 2
[17179571.368000] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[17179571.368000] TCP established hash table entries: 16384 (order: 5, 196608 bytes)
[17179571.368000] TCP bind hash table entries: 8192 (order: 4, 98304 bytes)
[17179571.368000] TCP: Hash tables configured (established 16384 bind 8192)
[17179571.368000] TCP reno registered
[17179571.368000] Machine check exception polling timer started.
[17179571.368000] audit: initializing netlink socket (disabled)
[17179571.368000] audit(1170774029.368:1): initialized
[17179571.372000] Initializing Cryptographic API
[17179571.372000] io scheduler noop registered
[17179571.372000] io scheduler anticipatory registered (default)
[17179571.372000] io scheduler deadline registered
[17179571.372000] io scheduler cfq registered
[17179571.372000] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[17179571.372000] nvidiafb: PCI id - 10de0181
[17179571.372000] nvidiafb: Actual id - 10de0181
[17179571.372000] nvidiafb: nVidia device/chipset 10DE0181
[17179571.388000] nvidiafb: CRTC0 analog found
[17179571.404000] nvidiafb: CRTC1 analog not found
[17179571.520000] nvidiafb: EDID found from BUS1
[17179571.536000] nvidiafb: CRTC 0 appears to have a CRT attached
[17179571.536000] nvidiafb: Using CRT on CRTC 0
[17179571.536000] nvidiafb: MTRR set to ON
[17179571.548000] Console: switching to colour frame buffer device 160x64
[17179571.548000] nvidiafb: PCI nVidia NV18 framebuffer (64MB @ 0xE0000000)
[17179571.548000] ACPI: Power Button (FF) [PWRF]
[17179571.548000] ACPI: Power Button (CM) [PWRB]
[17179571.628000] Linux agpgart interface v0.101 (c) Dave Jones
[17179571.628000] agpgart: Detected an Intel i875 Chipset.
[17179571.632000] agpgart: AGP aperture is 64M @ 0xf4000000
[17179571.632000] [drm] Initialized drm 1.0.1 20051102
[17179571.632000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
[17179571.632000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[17179571.632000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[17179571.632000] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[17179571.632000] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[17179571.636000] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
[17179571.636000] loop: loaded (max 8 devices)
[17179571.636000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[17179571.636000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[17179571.636000] ICH5: IDE controller at PCI slot 0000:00:1f.1
[17179571.636000] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
[17179571.636000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 17
[17179571.636000] ICH5: chipset revision 2
[17179571.636000] ICH5: not 100% native mode: will probe irqs later
[17179571.636000]     ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
[17179571.636000]     ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio
[17179571.636000] Probing IDE interface ide0...
[17179571.928000] hda: ST340810A, ATA DISK drive
[17179572.600000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[17179572.600000] Probing IDE interface ide1...
[17179572.892000] hdc: ST3160212A, ATA DISK drive
[17179573.564000] ide1 at 0x170-0x177,0x376 on irq 15
[17179573.564000] hda: max request size: 128KiB
[17179573.564000] hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
[17179573.564000] hda: cache flushes not supported
[17179573.564000]  hda: hda1 hda2 hda3 hda4 < hda5 >
[17179573.592000] hdc: max request size: 512KiB
[17179573.628000] hdc: 312581808 sectors (160041 MB) w/2048KiB Cache, CHS=19457/255/63, UDMA(33)
[17179573.652000] hdc: cache flushes supported
[17179573.652000]  hdc: hdc1
[17179573.676000] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
[17179573.676000] serio: i8042 AUX port at 0x60,0x64 irq 12
[17179573.680000] serio: i8042 KBD port at 0x60,0x64 irq 1
[17179573.680000] mice: PS/2 mouse device common for all mice
[17179573.680000] oprofile: using NMI interrupt.
[17179573.680000] ip_conntrack version 2.4 (4089 buckets, 32712 max) - 172 bytes per conntrack
[17179573.704000] input: AT Translated Set 2 keyboard as /class/input/input0
[17179573.796000] TCP bic registered
[17179573.796000] NET: Registered protocol family 1
[17179573.796000] NET: Registered protocol family 17
[17179573.796000] Starting balanced_irq
[17179573.796000] Using IPI Shortcut mode
[17179573.796000] Freeing unused kernel memory: 212k freed
[17179573.876000] logips2pp: Detected unknown logitech mouse model 90
[17179574.340000] input: ImExPS/2 Logitech Explorer Mouse as /class/input/input1
[17179574.484000] libata version 1.20 loaded.
[17179574.484000] ata_piix 0000:00:1f.2: version 1.05
[17179574.484000] ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
[17179574.484000] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17
[17179574.484000] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[17179574.484000] ata1: SATA max UDMA/133 cmd 0xEFE0 ctl 0xEFAE bmdma 0xEF60 irq 17
[17179574.484000] ata2: SATA max UDMA/133 cmd 0xEFA0 ctl 0xEFAA bmdma 0xEF68 irq 17
[17179574.752000] ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:207f
[17179574.752000] ata1: dev 0 ATA-7, max UDMA/133, 625142448 sectors: LBA48
[17179574.760000] ata1: dev 0 configured for UDMA/133
[17179574.760000] scsi0 : ata_piix
[17179574.864000] ata2: SATA port has no device.
[17179574.864000] scsi1 : ata_piix
[17179574.864000]   Vendor: ATA       Model: ST3320620AS       Rev: 3.AA
[17179574.864000]   Type:   Direct-Access                      ANSI SCSI revision: 05
[17179575.188000] kjournald starting.  Commit interval 5 seconds
[17179575.188000] EXT3-fs: mounted filesystem with ordered data mode.
[17179576.708000] usbcore: registered new driver usbfs
[17179576.708000] usbcore: registered new driver hub
[17179580.228000] ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 22 (level, low) -> IRQ 18
[17179580.228000] skge 1.5 addr 0xfeaf8000 irq 18 chip Yukon rev 1
[17179580.228000] skge eth0: addr 00:0e:a6:90:c2:82
[17179581.196000] ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 19
[17179581.196000] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[17179581.448000]  0:0:0:0: Attached scsi generic sg0 type 0
[17179581.556000] AC'97 0 analog subsections not ready
[17179581.624000] intel8x0_measure_ac97_clock: measured 55480 usecs
[17179581.624000] intel8x0: clocking to 48000
[17179581.656000] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[17179581.656000] sda: Write Protect is off
[17179581.656000] sda: Mode Sense: 00 3a 00 00
[17179581.660000] SCSI device sda: drive cache: write back
[17179581.664000] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[17179581.664000] sda: Write Protect is off
[17179581.664000] sda: Mode Sense: 00 3a 00 00
[17179581.668000] SCSI device sda: drive cache: write back
[17179581.668000]  sda: sda1 < sda5 sda6 >
[17179581.732000] sd 0:0:0:0: Attached scsi disk sda
[17179581.840000] USB Universal Host Controller Interface driver v3.0
[17179581.840000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
[17179581.840000] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[17179581.840000] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[17179581.840000] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
[17179581.840000] uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000ef00
[17179581.840000] usb usb1: configuration #1 chosen from 1 choice
[17179581.840000] hub 1-0:1.0: USB hub found
[17179581.840000] hub 1-0:1.0: 2 ports detected
[17179581.944000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
[17179581.944000] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[17179581.944000] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[17179581.944000] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
[17179581.944000] uhci_hcd 0000:00:1d.1: irq 20, io base 0x0000ef20
[17179581.944000] usb usb2: configuration #1 chosen from 1 choice
[17179581.944000] hub 2-0:1.0: USB hub found
[17179581.944000] hub 2-0:1.0: 2 ports detected
[17179582.048000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
[17179582.048000] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[17179582.048000] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[17179582.048000] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
[17179582.048000] uhci_hcd 0000:00:1d.2: irq 17, io base 0x0000ef40
[17179582.048000] usb usb3: configuration #1 chosen from 1 choice
[17179582.048000] hub 3-0:1.0: USB hub found
[17179582.048000] hub 3-0:1.0: 2 ports detected
[17179582.152000] ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16
[17179582.152000] PCI: Setting latency timer of device 0000:00:1d.3 to 64
[17179582.152000] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[17179582.152000] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
[17179582.152000] uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000ef80
[17179582.152000] usb usb4: configuration #1 chosen from 1 choice
[17179582.152000] hub 4-0:1.0: USB hub found
[17179582.152000] hub 4-0:1.0: 2 ports detected
[17179582.256000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 21
[17179582.256000] PCI: Setting latency timer of device 0000:00:1d.7 to 64
[17179582.256000] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[17179582.256000] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
[17179582.256000] ehci_hcd 0000:00:1d.7: debug port 1
[17179582.256000] PCI: cache line size of 128 is not supported by device 0000:00:1d.7
[17179582.256000] ehci_hcd 0000:00:1d.7: irq 21, io mem 0xfebffc00
[17179582.260000] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[17179582.260000] usb usb5: configuration #1 chosen from 1 choice
[17179582.260000] hub 5-0:1.0: USB hub found
[17179582.260000] hub 5-0:1.0: 8 ports detected
[17179582.724000] Floppy drive(s): fd0 is 1.44M
[17179582.744000] FDC 0 is a post-1991 82077
[17179582.884000] parport: PnPBIOS parport detected.
[17179582.884000] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[17179583.012000] lp0: using parport0 (interrupt-driven).
[17179585.324000] EXT3 FS on hda2, internal journal
[17179585.572000] kjournald starting.  Commit interval 5 seconds
[17179585.576000] EXT3 FS on hda1, internal journal
[17179585.576000] EXT3-fs: mounted filesystem with ordered data mode.
[17179585.604000] kjournald starting.  Commit interval 5 seconds
[17179585.604000] EXT3 FS on hda5, internal journal
[17179585.604000] EXT3-fs: mounted filesystem with ordered data mode.
[17179585.636000] kjournald starting.  Commit interval 5 seconds
[17179585.636000] EXT3 FS on sda5, internal journal
[17179585.636000] EXT3-fs: mounted filesystem with ordered data mode.
[17179585.672000] kjournald starting.  Commit interval 5 seconds
[17179585.672000] EXT3 FS on sda6, internal journal
[17179585.672000] EXT3-fs: mounted filesystem with ordered data mode.
[17179650.332000] skge eth0: enabling interface
[17179652.040000] skge eth0: Link is up at 100 Mbps, full duplex, flow control tx and rx

[-- Attachment #3: bus.diff --]
[-- Type: application/octet-stream, Size: 1043 bytes --]

--- bus.c.orig	2006-07-25 07:36:01.000000000 +0400
+++ bus.c	2007-02-06 14:57:46.000000000 +0400
@@ -140,11 +140,23 @@ void __devinit pci_bus_add_devices(struc
 void pci_enable_bridges(struct pci_bus *bus)
 {
 	struct pci_dev *dev;
-	int retval;
+	int retval, i;
+	u32 reg;
 
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		if (dev->subordinate) {
 			retval = pci_enable_device(dev);
+/* my debug	*/
+			printk("%s: devfn=0x%04x, vendor=0x%02x, device=0x%02x, sub_vendor=0x%02x, sub_device=0x%02x\n", 
+			       __func__, dev->devfn, dev->vendor, dev->device, dev->subsystem_vendor, dev->subsystem_device);
+			printk("%s: cfg_size=0x%02x, irq=0x%02x, hdr_type=0x%02x, rom_base_reg=0x%02x, pin=0x%02x\n", 
+			       __func__, dev->cfg_size, dev->irq, dev->hdr_type, dev->rom_base_reg, dev->pin);
+			
+			for (i = 0; i < 9; i++) {
+				pci_read_config_dword(dev, i, &reg);
+				printk("%s: i=0x%02x, Reg=0x%08x\n", __func__, i, reg);
+			}			
+/* my debug	*/
 			pci_set_master(dev);
 			pci_enable_bridges(dev->subordinate);
 		}

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> > >
> > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > > > ...
> > > > > >         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, Cache Line Size 0c
> > > > > >         BIST is running
> > > > >
> > > > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > > > I expect BIOS to have complained before launching grub/lilo.
> > > >
> > > > Gregkh,
> > > > I just realized linux-pci bus scan should ignore devices (print a warning)
> > > > which have BIST set.  Want a patch for this?
> > > >
> > > > Slight risk some previously "working" device which violates the
> > > > spec might get ignored...but I hope there aren't too many of those.
> > >
> > > Should we wait two seconds before declaring the device dead?
> > > To see whether it will come back?
> >
> > Hrm...my thought was BIOS should already be doing that...but I just
> > realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> > "BIST is running". I think the fact that BIST is not "running" in the
> > 2.6.20-rc7 lspci output is just coincidental. The config space for that
> > device is full of similar garbage in both cases regardless how long
> > it took.
> >
> > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> > register and BIOS is not being careful to clear or disable the other
> > bytes in that same 32-bit word?
> >
> > PCI is by nature a 32-bit wide config space and "byte enables"
> > are used to mask off bytes we want to ignore.  If the chipset
> > or BIOS config access routines aren't careful, they could accidentally
> > modify other values in the same 32-bit word when only one byte was
> > intended to be changed.
> >
> > The code in pci_set_cacheline_size() uses byte enables but is only
> > called by pci_set_mwi(). 82 different .c files (124 instances) access
> > PCI_LATENCY_TIMER.  Of those, 68 are pci_write_config_byte() calls.
> > But I really only care about the calls what would apply get invoked
> > for 1822:4e35. My guess is this one always gets invoked:
> >   ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> >
> > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> > (http://pci-ids.ucw.cz/iii/?i=1822)
> > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
> >
> > Manu, can you add code to pci_enable_bridges() to dump information about
> > which bridges are getting enabled _before_ pci_set_master() is called?
> >
> > I'm interested in a hex dump of the first 8  32-bit words of
> > PCI config space for each device.
> >
>
> attaching a dump of the regs (on 2.6.17.7) as well as the diff
>


The device now works, used the demodulator driver alongwith the bridge driver.

inlined the log

regards,
manu


[17181623.040000] gpif status: 6000  irqcfg: 0000
[17181623.040000] irq: 18, latency: 64
[17181623.040000]  memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000] found a UNKNOWN PCI UNKNOWN device on (02:0a.0),
[17181623.040000]     Mantis Rev 1 [1822:0031], irq: 18, latency: 64
[17181623.040000]     memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000]         mantis_i2c_write: Address=[0x50] <W>[ 08 ]
[17181623.040000]         mantis_i2c_read:  Address=[0x50] <R>[ 00 00
00 00 00 00 ]
[17181623.044000]     MAC Address=[00:00:00:00:00:00]
[17181623.044000] mantis_alloc_buffers (0): DMA=0x186b0000
cpu=0xd86b0000 size=65536
[17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000
cpu=0xdc3af000 size=1000
[17181623.044000] DVB: registering new adapter (Mantis dvb adapter).
[17181623.564000] mantis_frontend_init (0): Probing for STB0899
(DVB-S/DSS/DVB-S2)
[17181623.564000] stb0899_write_regs [0xf1b6]: 02
[17181623.564000]         mantis_i2c_write: Address=[0x68] <W>[ f1 b6 02 ]
[17181623.564000] stb0899_write_regs [0xf1c2]: 00
[17181623.564000]         mantis_i2c_write: Address=[0x68] <W>[ f1 c2 00 ]
[17181623.568000] stb0899_write_regs [0xf1c3]: 00
[17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f1 c3 00 ]
[17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f0 00 ]
[17181623.568000]         mantis_i2c_read:  Address=[0x68] <R>[ 82 ]
[17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82
[17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2]
[17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.572000]         mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.572000]         mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.576000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf334], Data=[0x444d4431]
[17181623.576000]         mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.576000]         mantis_i2c_write: Address=[0x68] <W>[ f3 00 ]
[17181623.576000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000]         mantis_i2c_write: Address=[0x68] <W>[ f3 3c ]
[17181623.580000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf33c], Data=[0x00000001]
[17181623.580000] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1]
[17181623.580000]         mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.584000]         mantis_i2c_write: Address=[0x68] <W>[ fa 00 ]
[17181623.584000]         mantis_i2c_read:  Address=[0x68] <R>[ 4c 00 00 00 ]
[17181623.588000]         mantis_i2c_write: Address=[0x68] <W>[ fa 2c ]
[17181623.588000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 43 45 46 ]
[17181623.588000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa2c], Data=[0x46454331]
[17181623.588000]         mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.592000]         mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.592000]         mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.596000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa34], Data=[0x00000001]
[17181623.596000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1]
[17181623.596000] stb0899_attach: Attaching STB0899
[17181623.596000] mantis_frontend_init (0): found STB0899
DVB-S/DSS/DVB-S2 frontend @0x68
[17181623.596000] mantis_frontend_init (0): Probing for STB6100 tuner
[17181623.596000] stb6100_attach: Attaching
[17181623.596000] mantis_frontend_init (0): found STB6100 tuner @0x60
[17181623.596000] mantis_frontend_init (0): Probing for LNBP21 SEC
[17181623.596000]         mantis_i2c_write: Address=[0x08] <W>[ 40 ]
[17181623.596000] DVB: registering frontend 0 (STB0899 Multistandard)...

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

> dang !
>
> rebooted it into 2.6.17.7
>
> no errors, during a bootup, BIST isn't running anymore
> running M$ did change the status from dead to alive ??? shocked !!

Interesting!  does windows driver fixes the broken firmware/flash on this card?

>
> attached lspci output in the very same setup as earlier, no difference
> in anything, except that it was rebooted into windows.
>
> the PCI config dump would help ?
>

I guess you would never reproduce this issue again unless you can
restore the broken firmware/flash on this card. :-)

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Luming Yu <luming.yu@gmail.com> wrote:
> > dang !
> >
> > rebooted it into 2.6.17.7
> >
> > no errors, during a bootup, BIST isn't running anymore
> > running M$ did change the status from dead to alive ??? shocked !!
>
> Interesting!  does windows driver fixes the broken firmware/flash on this card?


No firmware/flash on the card.


>
> >
> > attached lspci output in the very same setup as earlier, no difference
> > in anything, except that it was rebooted into windows.
> >
> > the PCI config dump would help ?
> >
>
> I guess you would never reproduce this issue again unless you can
> restore the broken firmware/flash on this card. :-)
>

none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
vendor information, that's all


regards,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 2/6/07, Luming Yu <luming.yu@gmail.com> wrote:
> > > dang !
> > >
> > > rebooted it into 2.6.17.7
> > >
> > > no errors, during a bootup, BIST isn't running anymore
> > > running M$ did change the status from dead to alive ??? shocked !!
> >
> > Interesting!  does windows driver fixes the broken firmware/flash on this card?
>
>
> No firmware/flash on the card.
>
>
> >
> > >
> > > attached lspci output in the very same setup as earlier, no difference
> > > in anything, except that it was rebooted into windows.
> > >
> > > the PCI config dump would help ?
> > >
> >
> > I guess you would never reproduce this issue again unless you can
> > restore the broken firmware/flash on this card. :-)
> >
>
> none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> vendor information, that's all
>

You can see the same from this picture

regards,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> > On 2/6/07, Luming Yu <luming.yu@gmail.com> wrote:
> > > > dang !
> > > >
> > > > rebooted it into 2.6.17.7
> > > >
> > > > no errors, during a bootup, BIST isn't running anymore
> > > > running M$ did change the status from dead to alive ??? shocked !!
> > >
> > > Interesting!  does windows driver fixes the broken firmware/flash on this card?
> >
> >
> > No firmware/flash on the card.
> >
> >
> > >
> > > >
> > > > attached lspci output in the very same setup as earlier, no difference
> > > > in anything, except that it was rebooted into windows.
> > > >
> > > > the PCI config dump would help ?
> > > >
> > >
> > > I guess you would never reproduce this issue again unless you can
> > > restore the broken firmware/flash on this card. :-)
> > >
> >
> > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> > vendor information, that's all
> >
>
> You can see the same from this picture

http://abraham.manu.googlepages.com/p3130016.jpg


>
> regards,
> manu
>

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

> none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> vendor information, that's all

Ok, sounds like windows driver can fix the broken EEPROM  on you card.
Otherwise, I can not explain how windows driver can fix the problem for linux.
Anyway, this issue is NOT linux problem. right?

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/7/07, Luming Yu <luming.yu@gmail.com> wrote:
> > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> > vendor information, that's all
>
> Ok, sounds like windows driver can fix the broken EEPROM  on you card.
> Otherwise, I can not explain how windows driver can fix the problem for linux.


I have the windows driver sources for the device, it does _not_ write
anything to the EEPROM under any circumstance.

moreover the EEPROM is write protected in hardware by a jumper. So no
application can write to it, AFAICS

> Anyway, this issue is NOT linux problem. right?
>

I am not very sure about that.

really i am thinking this way .. On booting up windows, it could have
changed some BIOS stuff (written something to NVRAM or something like
that ?).. that's the only possibility that i can see here.

really lost on this one.

regards,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Grant Grundler]

On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> >attaching a dump of the regs (on 2.6.17.7) as well as the diff
> 
> The device now works, used the demodulator driver alongwith the bridge 
> driver.

Ok - thanks for the dmesg output and log. I suspect you've already
tried cycling power on the machine (If not, please do).
I have no idea what M$ XP was doing that might "fix" the problem.

I was just suspicious of our byte accesses to the same dword.
To answer you previous question, it's possible that M$ only
uses dword accesses. I don't know.

> inlined the log

excellent - sounds like you are making forward progress even
if we can not reproduce the problem...worst case other users
(or customers) have a "work around" :^/

thanks,
grant

ps. I'll be unavailable until this weekend when I want to look at
the old and new logs a bit more.

> 
> regards,
> manu
> 
> 
> [17181623.040000] gpif status: 6000  irqcfg: 0000
> [17181623.040000] irq: 18, latency: 64
> [17181623.040000]  memory: 0xefeff000, mmio: 0xe18f4000
> [17181623.040000] found a UNKNOWN PCI UNKNOWN device on (02:0a.0),
> [17181623.040000]     Mantis Rev 1 [1822:0031], irq: 18, latency: 64
> [17181623.040000]     memory: 0xefeff000, mmio: 0xe18f4000
> [17181623.040000]         mantis_i2c_write: Address=[0x50] <W>[ 08 ]
> [17181623.040000]         mantis_i2c_read:  Address=[0x50] <R>[ 00 00
> 00 00 00 00 ]
> [17181623.044000]     MAC Address=[00:00:00:00:00:00]
> [17181623.044000] mantis_alloc_buffers (0): DMA=0x186b0000
> cpu=0xd86b0000 size=65536
> [17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000
> cpu=0xdc3af000 size=1000
> [17181623.044000] DVB: registering new adapter (Mantis dvb adapter).
> [17181623.564000] mantis_frontend_init (0): Probing for STB0899
> (DVB-S/DSS/DVB-S2)
> [17181623.564000] stb0899_write_regs [0xf1b6]: 02
> [17181623.564000]         mantis_i2c_write: Address=[0x68] <W>[ f1 b6 02 ]
> [17181623.564000] stb0899_write_regs [0xf1c2]: 00
> [17181623.564000]         mantis_i2c_write: Address=[0x68] <W>[ f1 c2 00 ]
> [17181623.568000] stb0899_write_regs [0xf1c3]: 00
> [17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f1 c3 00 ]
> [17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f0 00 ]
> [17181623.568000]         mantis_i2c_read:  Address=[0x68] <R>[ 82 ]
> [17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82
> [17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2]
> [17181623.568000]         mantis_i2c_write: Address=[0x68] <W>[ f3 fc
> 00 04 00 00 ]
> [17181623.572000]         mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
> [17181623.572000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 44 4d 44 
> ]
> [17181623.572000]         mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
> [17181623.572000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 44 4d 44 
> ]
> [17181623.576000] stb0899_read_s2reg Device=[0xf3fc], Base
> address=[0x00000400], Offset=[0xf334], Data=[0x444d4431]
> [17181623.576000]         mantis_i2c_write: Address=[0x68] <W>[ f3 fc
> 00 04 00 00 ]
> [17181623.576000]         mantis_i2c_write: Address=[0x68] <W>[ f3 00 ]
> [17181623.576000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 
> ]
> [17181623.580000]         mantis_i2c_write: Address=[0x68] <W>[ f3 3c ]
> [17181623.580000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 
> ]
> [17181623.580000] stb0899_read_s2reg Device=[0xf3fc], Base
> address=[0x00000400], Offset=[0xf33c], Data=[0x00000001]
> [17181623.580000] stb0899_get_dev_id: Demodulator Core ID=[DMD1], 
> Version=[1]
> [17181623.580000]         mantis_i2c_write: Address=[0x68] <W>[ fa fc
> 00 08 00 00 ]
> [17181623.584000]         mantis_i2c_write: Address=[0x68] <W>[ fa 00 ]
> [17181623.584000]         mantis_i2c_read:  Address=[0x68] <R>[ 4c 00 00 00 
> ]
> [17181623.588000]         mantis_i2c_write: Address=[0x68] <W>[ fa 2c ]
> [17181623.588000]         mantis_i2c_read:  Address=[0x68] <R>[ 31 43 45 46 
> ]
> [17181623.588000] stb0899_read_s2reg Device=[0xfafc], Base
> address=[0x00000800], Offset=[0xfa2c], Data=[0x46454331]
> [17181623.588000]         mantis_i2c_write: Address=[0x68] <W>[ fa fc
> 00 08 00 00 ]
> [17181623.592000]         mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
> [17181623.592000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 
> ]
> [17181623.592000]         mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
> [17181623.592000]         mantis_i2c_read:  Address=[0x68] <R>[ 01 00 00 00 
> ]
> [17181623.596000] stb0899_read_s2reg Device=[0xfafc], Base
> address=[0x00000800], Offset=[0xfa34], Data=[0x00000001]
> [17181623.596000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1]
> [17181623.596000] stb0899_attach: Attaching STB0899
> [17181623.596000] mantis_frontend_init (0): found STB0899
> DVB-S/DSS/DVB-S2 frontend @0x68
> [17181623.596000] mantis_frontend_init (0): Probing for STB6100 tuner
> [17181623.596000] stb6100_attach: Attaching
> [17181623.596000] mantis_frontend_init (0): found STB6100 tuner @0x60
> [17181623.596000] mantis_frontend_init (0): Probing for LNBP21 SEC
> [17181623.596000]         mantis_i2c_write: Address=[0x08] <W>[ 40 ]
> [17181623.596000] DVB: registering frontend 0 (STB0899 Multistandard)...

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/7/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >attaching a dump of the regs (on 2.6.17.7) as well as the diff
> >
> > The device now works, used the demodulator driver alongwith the bridge
> > driver.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).

I did power cycling on the machine .. did try pulling out the power
cord out for a while as well, to check whether it is some "fix that
just evaporated"


> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.
>


someone who has access to NT HAL inside ideas (maybe a too far deam) ,
could probably explain ?


> > inlined the log
>
> excellent - sounds like you are making forward progress even
> if we can not reproduce the problem...worst case other users
> (or customers) have a "work around" :^/

Sounds like a horrible workaround . :-)

I am thinking more in the direction of something wrong in the BIOS, as
that is the only dark area, where i can't see/understand anything.


regards,
manu

Re: 2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

On 2/7/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >attaching a dump of the regs (on 2.6.17.7) as well as the diff
> >
> > The device now works, used the demodulator driver alongwith the bridge
> > driver.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).
> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.

Does it sound too weird, if our PCI accesses could accidentally
overwrite EEPROM contents on cards that have the EEPROM, R/W ?

we came across with lot of issues on the same unfortunately under
Linux only this issues comes up, we used to sling mud at each other,
probably for bad I2C communications on a BT878 based chip.

Recently, somebody came across a strange case where, booting into
Windows , fixed his EEPROM contents. Since i have the driver sources
for the described card from the vendor for windows, i don't see how
any way in which the Windows driver does rewriting the EEPROM.

http://thread.gmane.org/gmane.linux.drivers.dvb/23911/focus=31185

Does this have any relation to the current situation ?

regards,
manu