Date: Sun, 9 Jan 2000 16:00:35 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: 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.1000109141844.352A-100000@localhost> In-Reply-To: <200001091120.DAA18721@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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= way of > > > > testing if `ncr' and `sym' can co-exist in a 3.x machine. Uncomm= ented of > > > > course in LINT. > > > > > > FWIW, with both > > > controller ncr0 > > > controller sym0 > > > in the kernel config, the machine boots successfully, attaching: > >=20 > > Are you able to test this kernel in a machine with a SCSI card that onl= y > > `ncr' supports? >=20 > 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. >=20 > 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.=20 In fact, this 'conflict' is just a harmless war with an immediate winner, but since user has no clear means for selecting the driver it desires when= =20 both are configured, he just loses if he gets the driver he doesn't want for a device (or just for a single one if the system has several 53c8xx devices supported by both drivers). Under 4.X, the 'sym' takes precedence over the ncr unless user tells it to do differently by setting a driver option in the the kernel configuration file as follows:=20 /* * Low priority probe map. *=20 * This option is used as a bitmap to tell the driver=20 * about chips that are to be claimed with a low priority=20 * (-2000) by the probe method. This allows any other driver=20 * that may return some higher priority value for the same=20 * chips to take precedence over this driver (sym). * This option may be used when both the ncr driver and this=20 * driver are configured. * * Bits are to be coded as follows: * 1 -> 810a, 860 * 2 -> 825a, 875, 885, 895 * 4 -> 895a, 896, 1510d * 8 -> 1010 * * For example, value 5 tells the driver to claim support=20 * for 810a, 860, 895a, 896 and 1510d with low priority,=20 * allowing the ncr driver to take precedence if configured. */ There is not 1 bit per device type but 1 bit per chip core category. Each category have a common set of features on which user may want to base the choice of a driver over the other one for a device. This is not perfect, but it is simple. 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.=20 Based on the sym having won for a 875 when both ncr and sym had been configured, it is possible that the resulting ordering of probes makes 'sym' the winner in all situations for now under 3.X. But nothing proves this will stay so for ever, given all the parts (i386/conf/files, config, linker, kernel, ...) that are involved in this ordering.=20 Based on the fact that the ncr has been quite able to install 3.X systems for 8XX devices it supports (Btw, the 895A should be added to the ncr device table), the need of the sym for installing a system is only useful for the new 1010 device. After installation, user can do what he desires with his kernel configuration, but if both drivers are configured/needed and it happens that the ncr is trusted by the kernel for double-probed devices (both sym and ncr), user who wanted to switch to 'sym' for some device may get disappointed. ;-)=20 All that to say that the configuration of both 'ncr' and 'sym' in 3.X should be considered as 'not supported', in my opinion, as long as it will be not possible to guarantee which driver will be selected for each 8XX device when both ncr and sym drivers are configured.=20 We probably want to have something better for 3.5, but thanks to David,=20 4.0 is clean about the issue. Solutions for 4.0 release could be the following: A) Let the 'sym' take precedence over 'ncr' (default) B) Let the sym only return from probe with high priority for the new C1010 (driver low priority probe map set to 1+2+4=3D7) By the way, it seems that Linux packagers only configure the ncr53c8xx (generic as the ncr) in their installation stuff. But the C1010 has been announced to be available on January the 10'th and the 'sym' gets needed for that one. I expect some noise under Linux from users that will not be able to install their system with a C1010, but SYMBIOS/LSI will cope. I would be glad FreeBSD 4.0-RELEASE users to succeed their system installation=20 without any glitch in the same situation. ;) 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.1000109141844.352A-100000>