From owner-cvs-all Sun Aug 13 15:56:58 2000 Delivered-To: cvs-all@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id 9A79E37B745; Sun, 13 Aug 2000 15:56:48 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from nas27-213.vlt.club-internet.fr (nas27-213.vlt.club-internet.fr [195.36.224.213]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA11237; Mon, 14 Aug 2000 00:56:19 +0200 (MET DST) Date: Mon, 14 Aug 2000 00:37:24 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Wilko Bulte Cc: John Hay , Peter Wemm , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/release/scripts dokern.sh In-Reply-To: <20000813232620.A907@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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