Date: Thu, 13 Feb 1997 00:41:31 +0100 From: se@freebsd.org (Stefan Esser) To: helbig@mx.ba-stuttgart.de (Wolfgang Helbig) Cc: se@freebsd.org (Stefan Esser), hackers@freebsd.org Subject: Re: CMD640b workaround - final(?) version Message-ID: <19970213004131.DV50639@x14.mi.uni-koeln.de> In-Reply-To: <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Feb 13, 1997 00:02:34 %2B0100 References: <19970212213157.YA20116@x14.mi.uni-koeln.de> <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 13, helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) wrote: > What I wanted to be achieved by changing /sys/conf/files is: > If you put > options "CMD640" > in your kernel configuration file you will automatically get the pci-code > included and started in the kernel, even if you don't put the > controller pci0 > line in the configuration file. > Since I do not grasp the workings of /sys/conf/files and > /sys/i386/conf/files.i386, I don't know whether this is possible. No. The "options" lines just generate #defines, which will be put into some opt_xxx.h file (prefered method) or just be made part of the kernel Makefile (as -Dxxx). > Now suppose a newbie has installed successfully FreeBSD on a machine > with the CMD640b-controller, (because the generic kernel does have > options "CMD640" and controller pci0). He does not even know, that > he has something special, because he used the same machine with Windos > and LINUX before and didn't have any trouble. (ok, the newbie is me :-) ) > > Now he want's to build a customized kernel. He will find out that he needs > the CMD640b option (as I would have found out) and that he does not need > the pci-controller code, because it does not do any good. (That is the > way I proceeded. I did not have the pci-code in my kernel.) You have PCI chips in your system (at least the chip-set, and most probably your VGA card) and should not expect the kernel to work at all, unless "pci0" is included in the kernel config file. > So now if you leave the definition of cmd640_detected in pci.c our newbie > will get a link error. Yes. This is expected behaviour. He will learn something, this way :) > If you put this definition in wd.c, our newbie will not get a link > error but the kernel will freeze after the first attempt to use both > ide-channels simultaneously. Well, it will just behave like the kernel without that option, since there is no way, the driver will find out about the CMD 640 chip, if the PCI probe is not there. > I believe the second perspective is worse, because it is harder to > recover and early detected errors are less harmful in general. Its true, that an error should be signaled as early as possible, but this does not make the second workaround "worse", IMHO. This EIDE controller is just broken, and it is possible to work around (some of) its hardware defeciencies. > > The CMD640 option obviously makes no sense on a system > > without a PCI bus. But I agree, that it violates the > > But a kernel w/o pci-support *does* make sense on a system with PCI bus, > because the pci-code is simply overhead if no pci-drivers get installed. How about your VGA card ? The PCI code is very little overhead, and you just should not expect your PCI system to work at all, if you do not have pci0 defined. > > BTW: I do heavily dislike the way you introduced the PCI > > ID of the CMD640 into pci.c, and will not accept it! > > > > There is NO device specific code in pci.c for a reason! > > BTW: My solution is simpler. For a reason! > I do heavily dislike complicated code if there is a simpler way! Well, and believe in layering, to make it easy to deal with complex situations. (The world happens to be complex at times.) For that reason, there will not be a test for a particular PCI device ID in the device independent PCI code. > Do whatever you want with it, I will accept it! Well, I don't have any way to test the WD driver, since I do not own any (E)IDE drives. It is trivial to add a clean CMD640 probe/attach, and it will add only a few instructions over the code you suggested. I still prefer my second suggested way to deal with the CMD640 option, and you just have to understand, that the option will have no effect, if you did not include the PCI bus code into the kernel, and thus prevented the detection of the CMD 640 chip ... Since just about every EIDE chip currently used seems to have severe bugs, we should just have one probe, that calls into the WD driver with an appropriate chip ID param, IMHO. This should also be done in order to allow to add support for EIDE DMA transfer modes, which may need chip specific driver support. Gruss, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970213004131.DV50639>