[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    [W:0.032 / U:30.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site