>On Wed, 27 May 1998, Sean Doran wrote:
>> sd0 at scsibus0 targ 0 lun 0: <QUANTUM, XP34550W, LXY4> SCSI2 0/direct fixed
>> sd0: 4341MB, 5899 cyl, 10 head, 150 sec, 512 bytes/sect x 8890760 sectors
>
>Here's a message from FreeBSD's SCSI mailing list that looks relevant:

This only tells half the story.

The Atlas II has a tendency to return QUEUE FULL status when its write 
cache fills.  Julian E. derived SCSI subsystems simply don't have a clean
way to stop the queue of transactions to the device and requeue a transaction
that returns BUSY or QUEUE FULL status for a retry.  Instead, the code,
while in an interrupt context, sends the transaction again immediately.  This
simply won't work well with the Atlas II regardless of the firmware level
(LKY8 is better than LXY4, but it doesn't make the problem go completely
away) and is less than ideal for other drives too.  The correct algorithm
is to stop the flow of transactions to the device when a QUEUE FULL condition
occurs, lower the tag count to the number of currently active transaction,
and release the queue of transactions once a command completes.  For drives
like the Atlas II that return queue full for temporary resource shortages,
you need a quirk entry that prevents the count from going too low.

Now, you can kludge up the controller driver to do the re-queue, but rather
than fix it for only one driver when so many controllers have the potential
to support tagged queuing (bt, ahb, aic, uha, etc.), I added support in
the CAM SCSI layer for properly dealing with these kinds of issues.  So,
even the FreeBSD-current version of the aic7xxx driver, although it has
many bug fixes the NetBSD driver does not, will still suffer from this
problem.  The only fix I know of for these drives that is available today,
is to run CAM under either FreeBSD-current or FreeBSD-stable.

I would certainly support any effort to port this code to NetBSD, but I
simply don't have the time or resources to do this myself.

--
Justin