Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Aug 2000 00:37:24 +0200 (CEST)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
To:        Wilko Bulte <wkb@freebie.demon.nl>
Cc:        John Hay <jhay@icomtek.co.za>, Peter Wemm <peter@netplex.com.au>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/release/scripts dokern.sh
Message-ID:  <Pine.LNX.4.10.10008140024350.1362-100000@linux.local>
In-Reply-To: <20000813232620.A907@freebie.demon.nl>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 13 Aug 2000, Wilko Bulte wrote:

> On Sun, Aug 13, 2000 at 07:45:30PM +0200, G=E9rard Roudier wrote:
> >=20
> > On Sat, 29 Jul 2000, John Hay wrote:
> >=20
> > > > >   * Remove the `ncr' driver in the Alpha case -- the `sym' driver=
 works with
> > > > >     every known Alpha.
> > > >=20
> > > > I think it is time to switch -current to sym-only.  No disrespect t=
owards the
> > > > ncr driver writer intended, but the sym driver is well maintained, =
robust,
> > > > up-to-date, not implicated in the recurring fxp+ncr bugs, and suppo=
rts all
> > > > the hardware.
> > >=20
> > > It does not support all hardware yet. I have an old 810 card that don=
't
> > > even want to boot using the sym driver. It just go into a loop of pri=
nting
> > > errors at the stage where it should probe the disks. The same machine
> > > works just fine with the ncr driver.
> >=20
> > The PCI status reported by the device indicates a PCI parity error.=20
> >=20
> > > sym0: PCI STATUS =3D 0x8100
> >                        ^bit 0x8000 -> Signaled PCI parity error.
> >=20
> > On the other hand, the chip reported a MASTER DATA PARITY ERROR detecte=
d.
> >=20
> > > sym0:0: ERROR (c0:0) (8-0-0) (0/3) @ (scripta 170:720d0000).
> >                  ^DSTAT bit 0x40 -> Master Data Parity Error.
> >=20
> > It means that the NCR device detected such an error when acting as a
> > master, either in some data it tried to read, or the error has been
> > signaled by the PCI target while the NCR was writing data to that PCI
> > target.
> >=20
> > So, it is not the driver that failed, but the PCI hardware, given that =
PCI
> > parity checking is mandatory for PCI-SCSI controllers as we know.
>=20
> Be careful. While this is true, there are combinations of Alpha hardware
> with specific PCI exp cards where DEC/CPQ recommends/insists on disabling
> PCI parity checking via the SRM console.

Having PCI parity errors silently ignored seems far less critical with
Network devices as long as a CRC is checked by software. With PCI-SCSI
controllers we don't have such a software CRC.

> I don't remember ever having seen this requirement for the ncr/sym 810s
> though.

I don't remember ever having seen a ncr/sym device that comes from boot
with PCI parity error signaling enabled in the PCI COMMAND register.
Neither I have ever seen any other driver for these devices being careful
about really enabling PCI parity error checking and reporting. This may
explain that.

Is there some way for the driver to know about the hardware PCI parity
brokenness?

  Gerard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10008140024350.1362-100000>