On Wednesday, May 2, 2007 4:45 pm Robert Hancock wrote: > Jesse Barnes wrote: > > On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote: > >> Jesse Barnes wrote: > >>> On Tuesday, May 01, 2007, Jesse Barnes wrote: > >>>>> I'm testing it now on my 965... > >>>> > >>>> Bah... nevermind Robert, I see you're doing this already in > >>>> pci_mmcfg_reject_broken. I'm about to reboot & test now. > >>> > >>> Ok, I've tested a bit on my 965 (after re-adding my old patch to > >>> support it) and the new checks are more complete, but my BIOS > >>> still appears to be buggy. > >>> > >>> The extended config space (as defined by the register) is at > >>> 0xf0000000 (full value is 0xf0000003 indicating 128M enabled). > >>> The ACPI MCFG table has this space reserved according to Robert's > >>> new code, but the machine hangs due to the address space aliasing > >>> Olivier mentioned awhile back. I don't have a PCIe card to test > >>> with (or any devices that require extended config space that I > >>> know of) so I can't really tell if Windows supports PCIe on this > >>> platform, but if it does I don't see how it would w/o having a > >>> full bridge driver and sophisticated address space allocation > >>> builtin. > >> > >> Windows XP doesn't use MMCONFIG or any extended configuration > >> space. I believe Vista is supposed to, though. Not sure how they > >> are handling this issue. > > > > Oh right... Vista will be the first to fully support PCIe & mcfg... > > > >> Can you post what your board has for PNPACPI reserved resources (I > >> believe they're in /sys/devices/pnp0/*/resources IIRC, don't have > >> a Linux box handy right now). Full dmesg would also be useful, I > >> think it dumps out those reservations at boot nowadays.. > > > > BIOS update didn't help. Here's the boot log and a dump of the > > pnp0 resources. > > Curious.. It looks like the ACPI resources have the correct > reservation for the MMCONFIG window according to what the register > says the location should be. There's no other reservations that > overlap with that range (f000000-f7ffffff), and according to the 965 > datasheet there's nothing that's hard-coded to occupy that memory > range. I can't really see what this range could be conflicting with.
Yeah, it's strange. Even /proc/iomem from a working boot looks ok: d0700000-d07fffff : PCI Bus #04 d0800000-d08fffff : PCI Bus #05 f0000000-f7ffffff : pnp 00:01 fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 > What happens if you take out the chipset register detection, does the > MCFG table give you the same result? Wonder if they're doing > something funny with start/end bus values or something in their > table. There's some code in my patch that prints out the important > data from the MCFG table, can you tell me what that shows with the > chipset detection taken out? Yeah, I'll look a little more closely. It could also be that another register needs tweaking somewhere to actually get the bridge to decode the space. > If that doesn't provide any useful information, I think we may need > some assistance from Intel chipset/motherboard people to figure out > what is going on here.. I'm talking with them now, hopefully they'll shed some light on it. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/