From owner-freebsd-commit Thu Mar 30 16:09:01 1995 Return-Path: commit-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA03339 for commit-outgoing; Thu, 30 Mar 1995 16:09:01 -0800 Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA03326 for cvs-sys-outgoing; Thu, 30 Mar 1995 16:08:58 -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 QAA03320; Thu, 30 Mar 1995 16:08:53 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA08748; Thu, 30 Mar 1995 17:03:40 -0700 Date: Thu, 30 Mar 1995 17:03:40 -0700 From: Nate Williams Message-Id: <199503310003.RAA08748@trout.sri.MT.net> In-Reply-To: se@MI.Uni-Koeln.DE (Stefan Esser) "Re: cvs commit: src/sys/i386/conf BOOTFLP" (Mar 31, 1:38am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: se@MI.Uni-Koeln.DE (Stefan Esser), Poul-Henning Kamp Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Sender: commit-owner@FreeBSD.org Precedence: bulk [ Synch transfers with the ncr-scsi driver ] > } How about controling this with the flags argument, and default it to off ? > } > } This way people can boot the boot.flp, but not from their harddisk... > > Yes. But then we know, there is something severely wrong > with their system ... But it's better to have something that works that could go faster than something that doesn't work. IMHO, we should err on the side of working, vs. making it obvious that something is wrong. Too often someone will assume that it's something wrong with FreeBSD instead of something wrong with their hardware. > We had the NCR driver restricted to asynch. transfers in > earlier GENERIC kernels, but found that most people don't > ever enable synchronous transfers later. I prefer it this way. We need to make it more obvious on how to enable synchronous transfers and why. > We thought that it was best, if problems with cables or > terminators, which are the most likely reasons for problems > with FAST SCSI, showed up as early as possible, i.e. before > remounting the root partition R/W. Agreed. > For this reason we considered switching on FAST SCSI from > rc.local or some other startup file might be not so good an > idea. But we could go back to asynch as the default in the > GENERIC kernel, too ... I think you should add a comment to the GENERIC kernel above the ncr driver line which explains how to make the drive use SYNC mode. Anyone who builds a custom kernel will then be informed how to get SYNC mode. IMHO, leaving the default to ASYNC is better because even broken hardware works with it. Nate