Re: i386/2049: bug in ffs code or SCSI driver

[Scott Ballantyne <sdb_(_at_)_ssr_(_dot_)_com>]

The following reply was made to PR i386/2049; it has been noted by GNATS.

From: Scott Ballantyne <sdb_(_at_)_ssr_(_dot_)_com>
To: gnats_(_at_)_openbsd_(_dot_)_org
Cc:  Subject: Re: i386/2049: bug in ffs code or SCSI driver
Date: 6 Sep 2001 03:01:11 -0000

 Hi Todd,
 
 Thanks for the suggestion. I'm very sorry to say it doesn't change
 anything but the amount of time that passes before the dup_alloc
 error. It still occurs before the first tar archive has been unpacked.
 
 sdb
 
 
 > The following reply was made to PR i386/2049; it has been noted by GNATS.
 > 
 > From: "Todd C. Miller" <Todd_(_dot_)_Miller_(_at_)_courtesan_(_dot_)_com>
 > To: sdb_(_at_)_ssr_(_dot_)_com
 > Cc: gnats_(_at_)_openbsd_(_dot_)_org
 > Subject: Re: i386/2049: bug in ffs code or SCSI driver 
 > Date: Wed, 05 Sep 2001 14:59:27 -0600
 > 
 >  There appears to be an "issue" with the ahc driver and (some?)
 >  Quantum disks.  It only seems to cause trouble when filesystems are
 >  mounted with the async or softdep options though.  If you hit ^Z
 >  or start a shell *after* the filesystems have been newfs'd and
 >  mounted (but before sets are extracted) and then turn off async you
 >  should be able to complete the install.  E.g.:
 >      # mount -u -o noasync /mnt
 >      # mount -u -o noasync /mnt/var
 >      # mount -u -o noasync /mnt/usr
 >  
 >  In normal usage I have worked around this by changing aic7xxx.c to
 >  default to 4 tags instead of 16 but that's not a great solution.
 >  Interestingly enough this only seems to affect my 2940U -- I can't
 >  reproduce the problem with a straight 2940.
 >  
 >   - todd
 >  
 > 
 >