RE: Problems with EDAC coexisting with BIOS

["Gross, Mark" <mark.gross@intel.com>]

>-----Original Message-----
>From: Tim Small [mailto:tim@buttersideup.com]
>Sent: Saturday, April 22, 2006 11:32 AM
>To: Gross, Mark
>Cc: Doug Thompson; Ong, Soo Keong; Carbonari, Steven; Wang, Zhenyu Z;
>bluesmoke-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
>Subject: Re: Problems with EDAC coexisting with BIOS
>
>Gross, Mark wrote:
>
>>You can never predict when a SMI will bubble through the system.  Even
>>if you handle case where the BIOS re-hides Dev0:Fun1 and not panic how
>>do you deal with the race between the BIOS SMI based handling and the
>>driver?  Who will end up reading (and clearing) the error registers
>>first?  There is no good way to share today.
>>
>>
>You could (at least from memory, on certain chipsets) modify the error
>reporting registers so that an SMI is no longer generated as a result
of
>MC ECC errors.  True, this doesn't fix many of the other problems
>related to this issue, but would be useful in a "modprobe xyz_edac
>force_unhide_MC_PCI=1" case.

You can get SMI's for more than just ECC events, suppressing the ECC
SMI's won't save you from the other SMI events that could happen.  

We need to work something out with the bios guys to do this right.
Today we don't have a good way of coordinating between the payload OS
and the BIOS for this type of platform level stuff.

>
>Closed-source BIOSes eh?  Who needs em ;-p.
No comment.

--mgross
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/