Re: [patch 1/6] pci-quirks: unhide 'Overflow' device on i828{6,7}5P/PE chipsets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux