Date: Fri, 31 Mar 1995 02:43:43 +0200 From: se@MI.Uni-Koeln.DE (Stefan Esser) To: Nate Williams <nate@trout.sri.MT.net> Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP Message-ID: <199503310043.AA09671@FileServ1.MI.Uni-Koeln.DE> In-Reply-To: Nate Williams <nate@trout.sri.MT.net> "Re: cvs commit: src/sys/i386/conf BOOTFLP" (Mar 30, 17:03)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 30, 17:03, Nate Williams wrote: } Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP } [ Synch transfers with the ncr-scsi driver ] } 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. Yes. This is what we did in earlier releases of the driver. } IMHO, leaving the default to ASYNC is better because even broken } hardware works with it. Don't think this is necessary. We got all of 3 bug reports related to synchronous SCSI. It was always the same drive series, that lead to problems, and it is not bad cables, but looks like a violation of the synch. negotiation process. (The drive and the NCR driver seem to have different ideas about whether the negotiation succeeded.) If we get a report of the BOOTFLP kernel working and the GENERIC failing, then we point to a "cpio.flp" prepared for this particular situation, that has additional debug output enabled (e.g. prints all messages dealing with synch./wide negotiation). We want to be able to automatically deal with this situation and need cooperation of the owner of such 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). We found, that having a polled mode available, lead to people use the driver without PCI interrupts configured correctly. Of course the performance suffers, but is still in the range of what an Adaptec 1542 is capable of. 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 ... So: 1) The SNAP's GENERIC kernels should be built with all SCSI performance options enabled, IMHO. 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 ... Regards, STefan -- Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE> Zentrum fuer Paralleles Rechnen Tel: +49 221 4706019 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503310043.AA09671>