On Monday 16 November 2009 04:41:27 pm Ira W. Snyder wrote: > On Mon, Nov 16, 2009 at 03:07:40PM -0800, Ira W. Snyder wrote: > > [ big snip ] > > > > > > > This looks like legacy IDE stuff for a device that is probably built into > > > the southbridge. Since it lives on PCI bus 0, I suppose these regions > > > should somehow be added as apertures that the host bridge claims. This > > > is all the sort of stuff that firmware is supposed to handle for you > > > when it builds the host bridge _CRS (if you have ACPI). > > > > > > I can't think of anything better than just adding these as hard-coded > > > apertures. > > > > > > > Ok. This makes sense, they are part of the IDE device, a function of the > > south bridge. Interestingly, they do not show up on the Force computer > > at all, only on the Trenton. > > > > ===== Force: ===== > > iws@labslcor4 ~ $ lspci -vvv -s 00:0f.1 > > 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) > > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > Latency: 64 > > Region 4: I/O ports at 1400 [size=16] > > Kernel driver in use: Serverworks_IDE > > > > These I/O ports *do* show up on Bridge 0, where I decoded them to be. > > They are 1000-140c. All of the I/O ports show up correctly in the bridge > > on the Force. > > > > iws@labslcor4 ~ $ lspci -vvv | grep 'I/O ports' > > Region 1: I/O ports at 1080 [size=64] > > Region 1: I/O ports at 10c0 [size=64] > > Region 1: I/O ports at 1000 [size=128] > > Region 4: I/O ports at 1400 [size=16] > > > > > > ===== Trenton: ===== > > iws@labslcor3 ~ $ lspci -vvv -s 00:0f.1 > > 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) > > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > Latency: 64 > > Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] > > Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] > > Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] > > Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1] > > Region 4: I/O ports at ffa0 [size=16] > > Kernel driver in use: pata_serverworks > > > > These I/O ports *do not* show up on Bridge 0, where I decoded them to > > be. Bridge #0 shows: d000-dffc. Bridge #1 shows: e000-effc. All of the > > I/O ports in the system are: > > > > iws@labslcor3 ~ $ lspci -vvv | grep 'I/O ports' > > Region 1: I/O ports at de80 [size=64] > > Region 1: I/O ports at df00 [size=64] > > Region 4: I/O ports at ffa0 [size=16] > > > > So the Trenton's BIOS missed the ffa0-ffac range, I guess. Since the > > ranges do not seem to be identical between my two boards, what should I > > do here? The legacy IDE I/O ports don't even show up on the Force. Sorry I haven't responded here; I got busy with something else this week, and I'll be on vacation all next week. My guess is there's a bit somewhere in the chipset that enables the embedded IDE controller, so maybe one machine has it enabled and the other doesn't. Might be hard to find that, unless there's a BIOS setup function to toggle it and you can compare before/after dumps or something. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
