On Thursday 12 February 2009 03:30:38 am Michał Mirosław wrote: > On Wed, Feb 11, 2009 at 04:22:29PM -0800, Andrew Morton wrote: > > On Wed, 11 Feb 2009 23:02:52 +0100 > > Michał Mirosław <mirq-linux@xxxxxxxxxxxx> wrote: > > > Hello, > > > > > > Please use the following version of the patch. This version has shorter > > > function names and message, and most importantly, better explanation > > > of problem I encountered. > > > > > > [patch starts below] > > > > > > Some BIOSes hide 'overflow' device (dev #6) for i82875P/PE chipsets. > > > The same happens for i82865P/PE. Add a quirk to enable this device. > > > This allows i82875 EDAC driver to bind to chipset's dev #6 and not > > > dev #0 as the latter is used by AGP driver. > > > > > > On my laptop (i82865P based) ACPI code is disabling this device > > > again in \_SB.PCI0._CRS method (called at least at PNP init time). > > > This can be easily worked around by patching DSDT. > > > > > > Signed-off-by: Michał Mirosław <mirq-linux@xxxxxxxxxxxx> > [patch cut] > > Where do we stand with Jesse's earlier comment? > > > > On Fri, 9 Jan 2009 13:40:02 -0800 > > Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > > > > > This one already got a NAK until Michal can figure out a way to prevent the > > > SMM code on his machine from hiding this device periodically. > > I'm running with this patch since I first created it and after patching > DSDT the device is not being hidden again. No other bad things happen. > The biggest concern is that it requires the user to modify ACPI DSDT > table if the BIOS is hiding the device (ie. Bjorn Helgaas comment). I really don't think we want to encourage people to run modified DSDTs. If somebody goes to all the trouble of modifying the DSDT, it's not much more trouble to patch the kernel with this change, so I'm not convinced there's much value in including it upstream. Originally, with the unmodified DSDT, it seemed that device 6 was getting disabled at random times. Now it sounds like you've traced that to the \_SB.PCI0._CRS method. But Linux should only execute that method at PNP init time, not at random times. Have you figured out anything more there? Is the _CRS method being called from some other ACPI method that is executed at random times? The comment in the patch says Intel recommends disabling device 6, but the link (http://www.x86-secret.com/articles/tweak/pat/patsecrets-2.htm) looks like French, which I can't read. Does it have more details about why they recommend it be disabled? Presumably they'd like to have the EDAC functionality (maybe on Windows?), so I would think that they'd only recommend disabling the device if it were broken or there were some other avenue for supporting EDAC. 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