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>
index | next in thread | previous in thread | raw e-mail
>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 Wirthhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9601221607.AA11304>