Re: Problems with EDAC coexisting with BIOS

Tim Small
2006-05-04T09:44:35Z

thockin@hockin.org wrote:

>On Wed, May 03, 2006 at 09:25:01PM +0100, Tim Small wrote:
>
>
>>existing BIOSs, but the EDAC module could reprogram the chipset
>>error-signalling registers, so that an ECC error no longer triggers an
>>
>>
>
>This is key, I think.
>
>
>
>>SMI. The BIOS SMI handler could then read the signalling registers, and
>>leave the ECC registers well alone if ECC errors are not set to generate
>>an SMI.
>>
>>
>
>The fundamental problem with SMI is that we CAN'T know what it is doing.
>I've seen systems which trigger SMI from a GPIO toggled by a clock. I've
>seen systems trigger SMI from a chipset-internal periodic timer. I've
>seen chipsets route NMI->SMI or even MCE->SMI. If the BIOS is polling the
>error status registers from a periodic SMI, we're GOING to lose data.
>
>The big hammer - turn off SMI - is probably OK on some systems, but is not
>a general solution. More and more hardware workarounds and features are
>SMI based. There are some rather interesting things that can be done in
>SMM, *iff* we could get the BIOS out of the way.
>
>
Agreed - I have had experience of a system (Intel 855GME chipset based,
AMI BIOS) which emulates the i8042 in the BIOS at SMI time. Mmm nice.
When the Linux i8042 driver can polled the (pretend) i8042, the system
spent ages in the BIOS, and general interrupt latency on the system fell
apart... Oh what a mess.

A limited solution is probably to modify the existing EDAC drivers so
that they ensure SMI generation is disabled (for the specific errors
that the EDAC drivers are designed to handle). The OS is then at least
doing the right thing, even if the BIOS isn't... This should improve
upon the current behaviour on some systems, and shouldn't (as far as I
can see) break any others. The EDAC code also probably needs to be
toughened up (at least on some chipsets) so that it doesn't fall over
when the BIOS steps on its toes.

Tim.