From owner-freebsd-bugs  Mon Jan 22 06:02:51 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA13030
          for bugs-outgoing; Mon, 22 Jan 1996 06:02:51 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA13009
          for <freebsd-bugs@freebsd.org>; Mon, 22 Jan 1996 06:02:45 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA01173; Tue, 23 Jan 1996 01:00:40 +1100
Date: Tue, 23 Jan 1996 01:00:40 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601221400.BAA01173@godzilla.zeta.org.au>
To: freebsd-bugs@freebsd.org, wirth@zerberus.hai.siemens.co.at
Subject: Re: Bug with NCR810 driver: Corrections, Additions and a Solution, see previous message
Sender: owner-bugs@freebsd.org
Precedence: bulk

>With some hints from Stefan Esser I was able to track down the real problem and 
>it lies NOT with the NCR driver!

>SCSI traces from (SCSIDEBUG defined) the kernel showed the problem within the
>SCSI subsystem. The 'dump' utility at one point early in the execution forks and
>then the disk to dump is opened some times (sd_open in sd.c) in quick succession.
>At this point both bugs showed. I could not trace down the 'assertion failed' message,
>because the event did not happen with the trace flags for SCSI or for NCR enabled.
>The 'Unit not ready' was traceable. 

>Everytime when the sd_open routine was called in quick succession I heard a 
>head recalibration inside one of the drives. After some thinking I suspected the
>START_UNIT command at the beginning of the sd_open routine. So I commented it out
>and *both* errors went away !! Without this command both disk work very well and 
>there are no more unusual head recalibration cycles.

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