Subject: Re: NMI on Compaq 1850R
To: None <current-users@NetBSD.org>
From: Chris Ross <cross+netbsd@distal.com>
List: current-users
Date: 01/20/2007 12:35:37
--Apple-Mail-2--118706979
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Jan 20, 2007, at 12:12, Chris Ross wrote:
> The aforementioned "patch" I am now running with simply removes
> the PCI_PRODUCT_INTEL_82443BX_AGP & PCI_PRODUCT_INTEL_82443BX_AGP
> case starting near line 193 of pchbattach(). This is noted to be a
> "BIOS BUG WORKAROUND". But, at least for my machine (pchb0: Intel
> 82443BX Host Bridge/Controller (AGP disabled) (rev. 0x03)), this
> "workaround" causes the machine to get an NMI fairly easily.
Ahh! I think I figured this out. According to a specification
update from Intel (available from http://www.intel.com/design/
chipsets/specupdt/290639.htm ), it looks like this "issue" was
present in steppings A0, B0, and B1, but *not* C0 or C1. (ref.
'IPDTL Bit Setting' in table on PDF doc page #9) So, "rev 0x03",
which my machine has, is stepping C1, and therefore the recommended
workaround should not apply.
I would like to propose the attached diff be committed to trunk.
(Apologies for the many lines of diff output due to re-spacing. It's
only the addition of the outer "if()" that is the change.) If this
looks reasonable to everyone, then we can get it in, and I'll ask for
some pullups. (This reasonable to pull into netbsd-3 and/or
netbsd-3-1? Or is it not important enough?)
Thanks...
- Chris
--Apple-Mail-2--118706979
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
x-unix-mode=0644;
name=pchb.c.diff
Content-Disposition: attachment;
filename=pchb.c.diff
Index: pchb.c
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.55.4.1
diff -u -r1.55.4.1 pchb.c
--- pchb.c 14 Feb 2006 20:39:35 -0000 1.55.4.1
+++ pchb.c 20 Jan 2007 17:29:29 -0000
@@ -191,23 +191,29 @@
break;
case PCI_PRODUCT_INTEL_82443BX_AGP:
case PCI_PRODUCT_INTEL_82443BX_NOAGP:
- /*
- * BIOS BUG WORKAROUND! The 82443BX
- * datasheet indicates that the only
- * legal setting for the "Idle/Pipeline
- * DRAM Leadoff Timing (IPLDT)" parameter
- * (bits 9:8) is 01. Unfortunately, some
- * BIOSs do not set these bits properly.
- */
- bcreg = pci_conf_read(pa->pa_pc, pa->pa_tag,
- I82443BX_SDRAMC_REG);
- if ((bcreg & 0x0300) != 0x0100) {
- printf("%s: fixing Idle/Pipeline DRAM "
- "Leadoff Timing\n", self->dv_xname);
- bcreg &= ~0x0300;
- bcreg |= 0x0100;
- pci_conf_write(pa->pa_pc, pa->pa_tag,
- I82443BX_SDRAMC_REG, bcreg);
+ if (PCI_REVISION(pa->pa_class) <= 0x02) {
+ /*
+ * BIOS BUG WORKAROUND! The 82443BX
+ * datasheet indicates that the only
+ * legal setting for the "Idle/Pipeline
+ * DRAM Leadoff Timing (IPLDT)" parameter
+ * (bits 9:8) is 01. Unfortunately, some
+ * BIOSs do not set these bits properly.
+ * nb: This bug in the chip only affects
+ * steppings A0, B0, and B1. At of stepping
+ * C0 (aka rev 0x03), this should not be
+ * necessary.
+ */
+ bcreg = pci_conf_read(pa->pa_pc, pa->pa_tag,
+ I82443BX_SDRAMC_REG);
+ if ((bcreg & 0x0300) != 0x0100) {
+ printf("%s: fixing Idle/Pipeline DRAM "
+ "Leadoff Timing\n", self->dv_xname);
+ bcreg &= ~0x0300;
+ bcreg |= 0x0100;
+ pci_conf_write(pa->pa_pc, pa->pa_tag,
+ I82443BX_SDRAMC_REG, bcreg);
+ }
}
break;
--Apple-Mail-2--118706979--