From owner-cvs-all Wed Jan 12 14:21:14 2000 Delivered-To: cvs-all@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id D7C551500B; Wed, 12 Jan 2000 14:21:05 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-109-88.villette.club-internet.fr [194.158.109.88]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA28171; Wed, 12 Jan 2000 23:20:00 +0100 (MET) Date: Wed, 12 Jan 2000 23:47:45 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: "Rodney W. Grimes" Cc: Matthew Jacob , Peter Wemm , obrien@NUXI.com, "Chris D. Faulhaber" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT In-Reply-To: <200001120210.SAA26406@gndrsh.dnsmgr.net> 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 On Tue, 11 Jan 2000, Rodney W. Grimes wrote: [ ... ] > > Changing the default 53C8XXX driver for 3.X in GENERIC may make > > unacceptable differences on some systems due to the `sym' applying the > > user settings from NVRAM. The below untested patch (I will test it if i= t > > is accepted and add additionnal comments to involved files) adds the > > 53C895A and 53C1510D Ultra-2 chips to the ncr device table and let the = sym > > only attach chips the ncr is unable to handle (C1010 Ultra-3 chip only = for > > now).=20 >=20 > Has the support for 895A/1510D been added to ncr in -current and been > given some time to be tested? If so then it's just a MFC to add that > to the ncr table. If not, well, it needs to be done in -current first. For now, the ncr does not know about these chips and will have to handle them like a 896. > Other than that issue this looks good... I don't see the issue given that the ncr never had seen any of these chips for the moment, but I will make changes in -current first. Btw, I haven't any of these chips, but both have been reported to work using the linux driver. By the way, I will also add the chip balancing between ncr and sym in PCI-COMPAT mode under -current and test it prior to moving the changes to releng_3 (the sym has a compilation option to use PCI-COMPAT under 4.0).=20 > > Index: ncr.c > This can't go in to -stable until it goes into -current: Hmmm... depends on the feature being still available in compatible form=20 in -current or not, and probably on size and triviality/dangerousity of changes. By the way, releng_3 (from last week-end) did crash when I attempted to write to a write-protected diskette: panic: vinvalbuf: dirty buffer Has this one been caught? Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message