Date: Mon, 18 Sep 95 18:21:18 +0100 From: Jean-Marc Zucconi <jmz@cabri.obs-besancon.fr> To: dufault@hda.com Cc: se@zpr.uni-koeln.de, current@freebsd.org Subject: Re: SCSI bug (possibly in the ncr driver) Message-ID: <9509181721.AA22099@cabri.obs-besancon.fr> In-Reply-To: <199509181107.HAA14449@hda.com> (message from Peter Dufault on Mon, 18 Sep 1995 07:07:21 -0400 (EDT))
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> Peter Dufault writes:
>>
>> The CDROMs don't support the command they receive,
>> Don't know, whether the Adaptec implements special
>> magic to better deal with that situation, but it
>> is no driver problem.
> No, there is no magic in the Adaptec driver.
>> (Which Adaptec did you use successfully before ?)
This was a 1542B
>>
>> The driver sent the command, received the status and
>> let the GENERIC SCSI code write that message ...
> The message is from the kernel driver and not the user mode scsi
> library (I'm just clarifying; you may mean the generic part of the
> kernel driver but it isn't clear as we have two CDROM programs one
> using kernel ioctls and the other using the user library).
> If it worked fine with an Adaptec and now fails with the NCR then
> the command may be getting stepped on. As Stefan says, this is
> unlikely: there would probably be problems with commands
> to other devices.
I have used the same program (cdplay) since FreeBSD 1.1 with the
adaptec without any problems, it only fails since I installed the ncr
controller!
>> Perhaps it is possible to find out, WHICH field has
>> been the cause of the command failure. But I guess
>> this will require some CDROM technical manuals, that
>> I don't have access to.
> You can tell which byte in the command is in error in a command
> independent way. The user mode library does this. It isn't likely
> to add that much information. You can turn on debugging in
> the kernel by compiling with SCSI_DEBUG defined and then use scsi(8)
> to set a debugging level on the CDROM. This will dump the commands
> via syslog and we can see if they are intact.
> Verify that the program does work with the Adaptec. If it does
> you have found a bug.
I no more have the adaptec. However, I have found the problem :-)
$ cdplay cd1
CD>tocentry
track minute second frame
1 0 2 0
2 22 39 3
255 43 44 3
CD>msfplay 0 2 0 43 44 3
cdplay: Invalid argument #ILLEGAL REQUEST asc:24,0 Invalid field in CDB
CD>msfplay 0 2 0 43 44 2
CD>stop
I always used the last minute-second-frame with the msf play
command. Apparently, one must not play the last frame of the disk. But
this does not explain why the adaptec driver does not report the error:
the bug is now in the aha1542 driver :-)
Jean-Marc
> --
> Peter Dufault Real Time Machine Control and Simulation
> HD Associates, Inc. Voice: 508 433 6936
> dufault@hda.com Fax: 508 433 5267
_____________________________________________________________________________
Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex
PGP Key: finger jmz@cabri.obs-besancon.fr
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509181721.AA22099>