lkml.org 
[lkml]   [2006]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: Problems with EDAC coexisting with BIOS
From
Date
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.

> >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.

Alan

-
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/

\
 
 \ /
  Last update: 2006-04-24 19:42    [W:0.032 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site