[lkml]   [2006]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Problems with EDAC coexisting with BIOS

>-----Original Message-----
>From: Gross, Mark
>Sent: Monday, April 24, 2006 11:14 AM
>To: 'Alan Cox'
>Cc:; LKML; Carbonari, Steven;
>Soo Keong; Wang, Zhenyu Z
>Subject: RE: Problems with EDAC coexisting with BIOS
>>-----Original Message-----
>>From: Alan Cox []
>>Sent: Monday, April 24, 2006 10:50 AM
>>To: Gross, Mark
>>Cc:; LKML; Carbonari, Steven;
>>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
>>> to whatever workarounds where done earlier.
>>Ok. I was concerned as I seem to remember an earlier errata fix
>>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
>>to apply the workaround.
>>> >Why did Intel bother implementing this functionality and then
>>> >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
>The E752x Si is made to allow access to the device / Function.
>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
>>> >BIOS is incompatible and to ask the BIOS vendor for an update so
>>> >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
>>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
>way to do this?

Patch to work around this problem is attached.

Signed-off-by: Mark Gross

[unhandled content-type:application/octet-stream]
 \ /
  Last update: 2006-04-25 20:22    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean