From owner-cvs-sys  Thu Mar 30 17:00:44 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA05673 for cvs-sys-outgoing; Thu, 30 Mar 1995 17:00:44 -0800
Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA05639; Thu, 30 Mar 1995 17:00:31 -0800
Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA08971; Thu, 30 Mar 1995 18:04:10 -0700
Date: Thu, 30 Mar 1995 18:04:10 -0700
From: Nate Williams <nate@trout.sri.MT.net>
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)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: se@MI.Uni-Koeln.DE (Stefan Esser)
Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP
Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 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