From owner-freebsd-current Mon Sep 18 09:20:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA21408 for current-outgoing; Mon, 18 Sep 1995 09:20:01 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA21385 for ; Mon, 18 Sep 1995 09:19:21 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA22099; Mon, 18 Sep 95 18:21:18 +0100 Date: Mon, 18 Sep 95 18:21:18 +0100 Message-Id: <9509181721.AA22099@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: dufault@hda.com Cc: se@zpr.uni-koeln.de, current@freebsd.org In-Reply-To: <199509181107.HAA14449@hda.com> (message from Peter Dufault on Mon, 18 Sep 1995 07:07:21 -0400 (EDT)) Subject: Re: SCSI bug (possibly in the ncr driver) X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk >>>>> 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 =============================================================================