I just checked in a patch that fixes the problems I was having with my
CD-ROM drive.  A description of the problem (and why the drive is
violating the SCSI spec) is attached below, for anyone who cares.

If you were seeing problems that seemed to be solved by turning off
synchronous negotation, please try the latest version of the driver
(1.41) and let me know whether or not your problems persist.

--

The failure scenario went roughly like this:

Host (CPU + 6360) selects Idiot (NEC MultiSpin 4x) with ATN set.  This
causes Idiot to go to MESSAGE OUT phase.  Host sends a MESSAGE
IDENTIFY followed by the beginning of a MESSAGE SYNCHRONOUS DATA
TRANSFER REQUEST.  Idiot interrupts the SDTR and sends a MESSAGE
REJECT.  Host hasn't deasserted ATN yet, so Idiot goes back into
MESSAGE OUT phase.  Host doesn't have any messages left to send, so it
sends a MESSAGE NO OPERATION.  Idiot goes to BUS FREE phase.

So far, everything is sort of within spec, although going to BUS FREE
phase at that point was a really poor choice on Idiot's part.
However:

The above action by Idiot is an unexpected disconnect.  In complying
with the recommendation at the end of section 5.1.1 of the SCSI-2
spec, Host now selects Idiot again and attempts to issue a REQUEST
SENSE, to clear any contingent allegiance condition that Idiot might
have created, and to try to find out what happened.  Immediately after
sending a MESSAGE IDENTIFY, Idiot goes to STATUS phase and returns
BUSY.

This last bit is a clear violation of the spec.  If I established an
I_T_L nexus and an unexpected disconnect occured, one of two things
should have happened:

1) The I/O process was completely terminated.  In this case, the
REQUEST SENSE will just give me nothing useful.

2) A contingent allegiance condition was created.  In this case, I
should be able to establish another I_T_L nexus and issue a REQUEST
SENSE to get the sense data.

Note that it would be very wrong for me to establish an I_T nexus and
issue a REQUEST SENSE.  Even if that would work, I refuse to try it on
general principle.

This is the second SCSI-2 violation I've found in NEC firmware.  The
other relates to logical units, and is a separate discussion in
itself.

Whee.