Date: Mon, 22 Jan 1996 17:07:47 +0100 From: Helmut Wirth <wirth@zerberus.hai.siemens.co.at> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-bugs@freebsd.org, wirth@zerberus.hai.siemens.co.at Subject: Re: Bug with NCR810 driver: Corrections, Additions and a Solution, see previous message Message-ID: <9601221607.AA11304@zerberus.hai.siemens.co.at> In-Reply-To: Your message of "Tue, 23 Jan 1996 01:00:40 %2B1100." <199601221400.BAA01173@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>The problem may be worse for concurrent opens of the same drive. There is >a known problem with initial concurrent opens. Concurrent initialization >of the slice table is unsafe (previously, concurrent initialization of the >label was unsafe). This problem is usually avoided by initially opening >mosts drives while there is only one active process. fsck -p may cause it. >Bruce I don't know about other side effects, but to give an unit more than one START_SCSI commands tagged in its command cache invites trouble. Some units don't mind like my Quantum ATLAS, but the IBM disks are confused. This is probably a question of the disks firmware; some disks may tolerate it and others not. I think we should get rid of this start unit command. There certainly is a need of such a command while *probing* for the disks. Both IBM disks could be jumpered to spin up with such a start unit command. Maybe the solution is to use it only once at *the first open* and to reset a flag with the *last close*, this regardless if the open is caused by an access via the block device (during mount) or by the character device (with dump, fsck, et.al.). Helmut Wirth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9601221607.AA11304>