RE: Problems with EDAC coexisting with BIOS

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

>-----Original Message-----
>From: Gross, Mark
>Sent: Monday, April 24, 2006 11:14 AM
>To: 'Alan Cox'
>Cc: bluesmoke-devel@lists.sourceforge.net; LKML; Carbonari, Steven;
Ong,
>Soo Keong; Wang, Zhenyu Z
>Subject: RE: Problems with EDAC coexisting with BIOS
>
>
>
>>-----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?
>


Patch to work around this problem is attached.

Signed-off-by: Mark Gross

--mgross

Attachment: edac.patch
Description: edac.patch