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 Thu, 2/12/09, Michał Mirosław <mirq-linux@xxxxxxxxxxxx> wrote:

> From: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
> Subject: Re: [patch 1/6] pci-quirks: unhide 'Overflow' device on i828{6,7}5P/PE chipsets
> To: "Tim Small" <tim@xxxxxxxxxxxxxxxx>
> Cc: "Bjorn Helgaas" <bjorn.helgaas@xxxxxx>, linux-pci@xxxxxxxxxxxxxxx, "Andrew Morton" <akpm@xxxxxxxxxxxxxxxxxxxx>, bluesmoke-devel@xxxxxxxxxxxxxxxxxxxxx, jbarnes@xxxxxxxxxxxxxxxx, norsk5@xxxxxxxxx
> Date: Thursday, February 12, 2009, 4:23 PM
> On Thu, Feb 12, 2009 at 06:24:29PM +0000, Tim Small wrote:
> > Bjorn Helgaas wrote:
> > >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.
> > My understanding is that since EDAC drivers have been
> missing from OS 
> > for so long (the only one I've ever seen is a
> Compaq written one for 
> > Windows in Pentium-II era machines), that they believe
> that EDAC 
> > functionality should be the job of the BIOS, and thus
> hidden from the OS...
> 
> It might be that Intel did not trust the OS writers enough
> to not do stupid
> things with memory controller settings. ;)

One of the reasons they desire to "hide" such devices is that their model is to have the BIOS receive the errors and then funnel the events out via the IPMI interfaces or some such. The BIOS then has control of the device, by hiding it, by turning it on, extracting data and then turning it off. In this way they abstract the memory controllers into a "common" yet limited abstract type of error bus

I believe though, that by going thru this abstraction we lose information on the error events and possibly lose the actual events. I prefer the per memory controller driver model, which is what EDAC follows, as it provides fast error mapping to a DIMM FRU (field replaceable unit) which what we really care about: Which DIMM is failing on a given mobo?

doug thompson
--
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