On Tuesday, January 16, 2007 11:28 am, Olivier Galibert wrote: > > But won't the bridge register value control what actually gets > > decoded? If so, it sounds like this BIOS is buggy wrt mmconfig > > mapping in general; good thing I'm not using any PCIe devices I > > guess... > > Yeah. I've checked the docs, I think I know what's going on. On one > hand, if the chipset is configured to have the range somewhere, it is > decoded before anything external to the chipset, be it ram or mmaped > i/o. So the information you get from the chipset should not be able > to conflict with anything by definition, it's the anything that > wouldn't be visible. > > But in your case of a f0000000-ffffffff mapping, something else > interesting is going on: it's conflicting with other internal > registers of the chipset, which, being fixed address, probably have > priority. So you probably have to either reduce the range so that > the chipset registers aren't touched, or drop mmconfig if the address > is f0000000. > > Technically, we can have the exact same problem with the other > chipsets. BIOSen suck.
Ouch. It doesn't seem like there's a sane general way to fix this up, aside from some sort of blacklist. Maybe it's best to leave this particular bridge unsupported for now... 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/
