From owner-freebsd-scsi Fri Dec 29 22:41:12 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA03054 for freebsd-scsi-outgoing; Fri, 29 Dec 1995 22:41:12 -0800 (PST) Received: from solaris.cisco.com (solaris.cisco.com [198.92.113.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA03048 for ; Fri, 29 Dec 1995 22:41:09 -0800 (PST) Received: (from stu@localhost) by solaris.cisco.com (8.6.12/8.6.9) id WAA03820; Fri, 29 Dec 1995 22:40:05 -0800 Date: Fri, 29 Dec 1995 22:40:05 -0800 From: Stu Phillips Message-Id: <199512300640.WAA03820@solaris.cisco.com> To: joerg_wunsch@uriah.heep.sax.de CC: freebsd-bugs@freefall.freebsd.org, freebsd-scsi@freebsd.org In-reply-to: <199512291531.QAA28321@uriah.heep.sax.de> (message from J Wunsch on Fri, 29 Dec 1995 16:31:36 +0100 (MET)) Subject: Re: xcdplayer and SCSI Problem with Sony CDU-76S Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk From: J Wunsch Date: Fri, 29 Dec 1995 16:31:36 +0100 (MET) Cc: freebsd-bugs@freefall.freebsd.org, freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I still think Sony is in violation of the standard here. Below are the references i found in the SCSI-2 standard for it: First, the generic documentation says: "7.3.3. Mode Parameters ... Medium types are unique for each device type. Refer to the mode parameters section of the specific device type for definition of these values. Some device types reserve this field." Ok, not ``some devices'', but ``some device types''. That makes it pretty clear that either a device type reserves this field, or it doesn't. Anyway, it's IMHO _not_ up to a particular vendor (i.e., the sentence ain't ``Some implemenation may reserve this field.'') So, let's see what the CD-ROM device-type specification says: ... "13.3.3. Mode Parameters The medium-type code field is contained in the mode parameter header (see Table 7-61 and 7-62). Table 13-30 defines the medium type values for CD-ROM devices. Table 13-30: CD-ROM Medium Type Codes =================================================== Code Value Medium Type ------------ ------------------------------------- 00h Default (only one type supported) 01h 120 mm CD-ROM data only 02h 120 mm CD-DA audio only 03h 120 mm CD-ROM data and audio combined 04h Reserved 05h 80 mm CD-ROM data only 06h 80 mm CD-DA audio only 07h 80 mm CD-ROM data and audio combined 08h - 7Fh Reserved 80h - FFh Vendor unique ===================================================" I.e., it doesn't say that this is an optional parameter or something else. It seems logical that any device should accept the value for a MODE SELECT that it's just been responding by a MODE SENSE. The behaviour of the Sony is at least, ähem, strange. Anyway, i think your proposed change to use a medium type of 0 seems to be usable as a workaround for me, it doesn't contradict the sense of the current code (since the current algorithm was to use all parameters as reported by the drive, and only modify some distinct parameters at will). Fully agree with you that it is STRANGE! However, think on this... the parameters in the audio page are specific to AUDIO capabilities - ie the SOTC is purely applicable to audio and irrelevant to data. I wonder wether setting the medium type to 0x02 would be accepted - I'll try it tomorrow. Not trying to defend SONY, however you must admit that its very wierd that the Windows application I tried (CorelScsi CDPlayer) works without any problems! Are you able to try this code change out on other CD drives ? If so and it works, are you able to commit the change ? Thanks! Stu