RE: Problems with EDAC coexisting with BIOS

Gross, Mark
2006-04-25T18:20:09Z

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

>-----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 #2: edac.patch --]
[-- Type: application/octet-stream, Size: 1097 bytes --]

===================================================================
RCS file: /opt/CVS/linux/drivers/edac/e752x_edac.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 e752x_edac.c
--- drivers/edac/e752x_edac.c 21 Apr 2006 02:58:32 -0000 1.1.1.1
+++ drivers/edac/e752x_edac.c 25 Apr 2006 13:26:33 -0000
@@ -755,10 +755,16 @@
debugf0("MC: " __FILE__ ": %s(): mci\n", __func__);
debugf0("Starting Probe1\n");

- /* enable device 0 function 1 */
+ /* check to see if device 0 function 1 is enbaled if it isn't we assume
+ * the BIOS has reserved it for a reason and is expecting exclusive
+ * access, we take care to not violate that assumption and fail the
+ * probe. */
pci_read_config_byte(pdev, E752X_DEVPRES1, &stat8);
- stat8 |= (1 << 5);
- pci_write_config_byte(pdev, E752X_DEVPRES1, stat8);
+ if (!(stat8 & (1 << 5))) {
+ printk(KERN_WARNING "contact your bios vendor to see if the "
+ "E752x error registers can be safely un-hidden\n");
+ goto fail;
+ }

/* need to find out the number of channels */
pci_read_config_dword(pdev, E752X_DRC, &drc);