Date: Thu, 30 Mar 1995 18:04:10 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: se@MI.Uni-Koeln.DE (Stefan Esser) Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP Message-ID: <199503310104.SAA08971@trout.sri.MT.net> In-Reply-To: se@MI.Uni-Koeln.DE (Stefan Esser) "Re: cvs commit: src/sys/i386/conf BOOTFLP" (Mar 31, 2:43am)
next in thread | raw e-mail | index | archive | help
> hardware. So I guess it is not necesseraly a bad thing, if > the installation isn't totally smooth for a VERY small number > of systems, if the result is problem reports that let us put > in a workaround for buggy devices (some DAT tapes and CDROMs > are already taken care of). Well, I don't necessarily agree. > We found, that having a polled mode available, lead to people > use the driver without PCI interrupts configured correctly. Hey, I know that one. :-) > Of course the performance suffers, but is still in the range > of what an Adaptec 1542 is capable of. Oh, it's well beyond the range of my box. I get 1.2MB/sec on a good day with a tail wind, and when I had the NCR box running in Polled mode I was getting 2.4MB/sec. :) > If the system is too forgiving, then such misconfigurations > will never be found. And at least for the SNAP distributions, > I'd prefer to have the GENERIC kernel enable FAST/WIDE/Tags > by default. Else we'll get the problem reports only when the > 2.1R CD is out for a few weeks and people start to experiment > with NCR performance options ... I doubt we'll get many complaints if people do things to tweak performance and it doesn't work. If hackers modify their system and it doesn't work, they generally don't blame the SW but hardware at that time. But, if it doesn't work the first time then SW is generally blamed since 'it worked under DOS and Linux fine'. > 1) The SNAP's GENERIC kernels should be built with all SCSI > performance options enabled, IMHO. Again, I disagree, but it's not for me to decide. It's easier to add something to the kernel config file to get better performance than it is to remove something which might cause problems. > 2) To decide, whether the RELEASE's GENERIC kernel ought to > be more forgiving in case of configuration problems (e.g. > bad cables/terminators) is up to the Release Engineer ... See above. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503310104.SAA08971>