RE: Problems with EDAC coexisting with BIOS

Gross, Mark
2006-04-24T18:14:15Z

>-----Original Message-----
>From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
>Sent: Monday, April 24, 2006 10:50 AM
>To: Gross, Mark
>Cc: bluesmoke-devel@lists.sourceforge.net; LKML; Carbonari, Steven;
Ong,
>Soo Keong; Wang, Zhenyu Z
>Subject: RE: Problems with EDAC coexisting with BIOS
>
>On Llu, 2006-04-24 at 08:57 -0700, Gross, Mark wrote:
>> I think what I'm saying is pretty clear and I don't think it is
related
>> to whatever workarounds where done earlier.
>
>Ok. I was concerned as I seem to remember an earlier errata fix enabled
>the memory controller temporarily to do a workaround on one bridge. We
>hit this because it unconditionally disabled it afterwards and Intel
>sent fixes for RHEL4. I don't believe the workaround in question is in
>the current tree as it was fixed elsewhere.
>
>Just worried that if that is the case an SMI the wrong moment might
fail
>to apply the workaround.
>
>
>> >Why did Intel bother implementing this functionality and then
screwing
>> >it up so that OS vendors can't use it ? It seems so bogus.
>> >
>>
>> It was just a screw up not to have identified this issue sooner.
>
>Ok. So the intention was that the OS should also be able to access this
>material.
>

The E752x Si is made to allow access to the device / Function. However;
when it's integrated onto a MoBo with BIOS there can be implementations
where we get into this coordination issue.

>> >At the very least we should print a warning advising the user that
the
>> >BIOS is incompatible and to ask the BIOS vendor for an update so
that
>> >they can enable error detection and management support.
>>
>> I would place the warning in the probe or init code.
>
>Agreed, and then bale out. Customer pressure should do the rest if the
>BIOS needs updating, or ACPI or similar need to grow a 'shared' API for
>this so the BIOS and OS can co-operate.
>

Yes and yes.

I'm having trouble getting the dev0:fun1 hidden by bios test into the
e752x_init code. It seems to be a shame having to fail the probe1 and
leave the driver loaded in memory. Are there any recommendations on a
good way to do this?

--mgross