Date: Wed, 12 Jan 2000 23:47:45 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: Matthew Jacob <mjacob@feral.com>, Peter Wemm <peter@netplex.com.au>, obrien@NUXI.com, "Chris D. Faulhaber" <jedgar@fxp.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT Message-ID: <Pine.LNX.3.95.1000112232143.335B-100000@localhost> In-Reply-To: <200001120210.SAA26406@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000112232143.335B-100000>