On Thu, Feb 12, 2009 at 10:37:51AM -0700, Bjorn Helgaas wrote: > 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? I used a bad observation method. After some more guesses I made a script that logged register 0xF4 from PCI dev 0:00:00.0 (the one disabling dev6) and it turned out that the device did not get disabled later after manually enabling it. > 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. I took another pass at i865 and i875 chipset datasheets and I think that there's nothing to hide actually in the dev6 - all it has documented (and that is all the EDAC drivers only read) are four DRAM control registers. It would be playing with fire if BIOS/SMM code changed those registers behind OS's back (unless the system supports memory hot-plug and it's somehow coordinated/transparent to the OS). After all, this device is useful only to people who like to know everything they can about their hardware - in this case: memory organization and timings, and to have an easy point to attach EDAC driver. I'll prepare a version with the quirk normally disabled if you consider the latter point a good one. Best Regards, Michał Mirosław -- 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
