Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Mar 1995 01:38:45 +0200
From:      se@MI.Uni-Koeln.DE (Stefan Esser)
To:        Poul-Henning Kamp <phk@ref.tfs.com>
Cc:        CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject:   Re: cvs commit: src/sys/i386/conf BOOTFLP
Message-ID:  <199503302338.AA24579@FileServ1.MI.Uni-Koeln.DE>
In-Reply-To: Poul-Henning Kamp <phk@ref.tfs.com> "Re: cvs commit: src/sys/i386/conf BOOTFLP" (Mar 30, 11:12)

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 30, 11:12, Poul-Henning Kamp wrote:
} Subject: Re: cvs commit: src/sys/i386/conf BOOTFLP
} >   Modified:    sys/i386/conf BOOTFLP
} >   Log:
} >   Do not try to negotiate synchronous SCSI transfers in the Boot Kernel.
} 
} 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 ...

I put this change in, since there seems to be one series 
of Toshiba 3.5" disk drives, that has problems to negotiate 
synch. transfers.

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.

There is the "ncrcontrol" utility, that lets you set the 
max. synch. transfer rate and number of tags to use (with 
asynch. and NO tags being valid options) per target and LUN 
(or for all devices on the SCSI bus).

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.

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 ...

Anyway. This makes a difference for the Toshiba MK537 and 
MK538 drives only, and there were 3 people upto now, that 
reported problems with them (BTW: these drives don't seem 
to work under BSD/OS, neither).

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?199503302338.AA24579>