Date: Sun, 09 Jan 2000 22:44:03 +0800 From: Peter Wemm <peter@netplex.com.au> To: Gerard Roudier <groudier@club-internet.fr> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, 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: <20000109144403.E6D8E1CCE@overcee.netplex.com.au> In-Reply-To: Message from Gerard Roudier <groudier@club-internet.fr> of "Sun, 09 Jan 2000 16:00:35 %2B0100." <Pine.LNX.3.95.1000109141844.352A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerard Roudier wrote:
>
>
> On Sun, 9 Jan 2000, Rodney W. Grimes wrote:
>
> > > On Sat, Jan 08, 2000 at 08:14:55PM -0500, Chris D. Faulhaber wrote:
> > > > > Add the `sym' SCSI driver. Commented out in GENERIC as I have no w
ay of
> > > > > testing if `ncr' and `sym' can co-exist in a 3.x machine. Uncommen
ted of
> > > > > course in LINT.
> > > >
> > > > FWIW, with both
> > > > controller ncr0
> > > > controller sym0
> > > > in the kernel config, the machine boots successfully, attaching:
> > >
> > > Are you able to test this kernel in a machine with a SCSI card that only
> > > `ncr' supports?
> >
> > I just built a -stable kernel with both ncr0 and sym0 in it (the comment
> > is wrong, they do not conflict with each other) and booted the
> > same kernel twice , once with a 53C825 and once with a 53C875, everything
> > worked just fine.
> >
> > Please uncomment the sym0 driver in GENERIC and remove the bogus
> > coment about it conflicting with ncr0
>
> Depends on what 'conflict' means in that context. On 3.X system, the PCI
> device drivers are seen from the `pcidevice_set' kernel data section and
> the code that attaches PCI device drivers is (seems?) careful about not
> allowing the same PCI device to be attached by 2 different drivers.
[..]
> Under 3.X, the PCI driver probe routines donnot return a priority but just
> a pointer to some name of the device when they accept this device (NULL
> otherwise). So, the trick above cannot be back-ported.
Actually, it works because of the conf/files file order. sym gets probed
first, then ncr.. always.
I likes the hack where ncr was modified with:
#if NSYM > 0
if (chip_has_scripts)
fail_probe;
#endif
This means that if sym and ncr go in the other order for some reason so that
ncr comes first, it will see chips with scripts and if sym is compiled in then
it will refuse the probe. This was a perfectly adequate hack and should be in
3.x if it is not already.
[..]
> We probably want to have something better for 3.5, but thanks to David,
> 4.0 is clean about the issue. Solutions for 4.0 release could be the
> following:
Yep, I made the old-style pci device wrapper use a low priority so that both
got a chance to probe and sym could take it if it was supported and leave it
for ncr if not.
> A) Let the 'sym' take precedence over 'ncr' (default)
Yes!
Anyway, lets get the hack for allowing sym to be the default regardless of the
probe order into 3.x. (ie: the ncr.c modification).
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20000109144403.E6D8E1CCE>