On Thu, Dec 20, 2007 at 07:28:00AM -0500, Tony Camuso wrote: > > > -------- Original Message -------- > Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG > Date: Wed, 19 Dec 2007 19:33:45 -0500 > From: Tony Camuso <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Greg KH <[EMAIL PROTECTED]> > References: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > Greg KH wrote: >> On Wed, Dec 19, 2007 at 05:17:46PM -0500, [EMAIL PROTECTED] wrote: >>> There exist devices that do not respond correctly to PCI >>> MMCONFIG accesses in x86 platforms. >> What devices are these? Do you have reports of them somewhere? > There are the AMD 8131 and 8132, the Serverworks HT1000 bridge chips > and the 830M/MG graphics. Not all versions of these chips present > this pathology, but there are perhaps tens of thousands of systems > out there that have the broken versions of these chipsets.
Why haven't we gotten reports about this before if this is a common problem? And why hasn't the vendor fixed the bios on these to work properly? > RedHat have been maintaining a blacklist of systems having these > devices. Systems in the blacklist are confined to legacy PCI > access. Do you have a pointer to this blacklist anywhere so that everyone can benifit from this knowledge? >> That sounds like this patchset can cause bad side affects on hardware >> that currently works just fine. That is not a good thing to be adding >> to the kernel, right? > No, the patch set tries to obviate this without requiring endusers to > write customized scripts with "pci=nommconf" and without requiring the > RH folks to add another platform (usually belatedly) to the blacklist. > > If a device is going to machine check when you touch it with an mmconfig > access, it will happen with or without this patch-set. > > However, the patch-set does cover most of the devices that don't respond > well to mmconfig access. Such devices almost alway7s return garbage when > you read from them. > > The one device we know about that throws exceptions is the 830M/MG > graphics chip. This chip passes the read-compare test, so the code > merrily advances to bus sizing. When the bus sizing code writes the > BAR at offset 0x18 in this device, the system hangs. So it doesn't work at all, with or without this patch? Does the vendor know about this? thanks, greg k-h -- 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/