From owner-freebsd-hackers Wed Nov 22 18:17:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03612 for hackers-outgoing; Wed, 22 Nov 1995 18:17:37 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA03607 for ; Wed, 22 Nov 1995 18:17:34 -0800 Received: from fw.ast.com by ast.com with SMTP id AA17633 (5.67b/IDA-1.5 for ); Wed, 22 Nov 1995 18:18:17 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0tIQrw-00008UC; Wed, 22 Nov 95 19:54 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0tIQkj-000J7dC; Wed, 22 Nov 95 19:47 WET Message-Id: Date: Wed, 22 Nov 95 19:47 WET To: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, rb@gid.co.uk, hackers@freefall.freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Wed Nov 22 1995, 19:47:05 CST Subject: Re: Anyone keen to help me get a Phillips CDD 521 Recorder working? Sender: owner-hackers@FreeBSD.ORG Precedence: bulk [0]However, a device that responds identically to all eight LUNs on a given [0]TARGET ID is most likely simply not checking the LUN field in the [0]command header, and is thus fundamentally busted, to use your words 8) [1]Unfortunately, in the rarified atmosphere of the CD writer market (soon [1]to get less so, I'm sure, but I still have to wait my turn) you need [1]to also take whatever you can get.. :-) Actually, I have an *ancient* Sony CD-W1/CD-E1 CD-ROM burner (encoder and burner are in separate units and it all cost $20K in 1991 plus $5K for software), and it responds on ALL the LUNs under a single target ID to certain commands. I recall that we encountered this behavior on a device/media-type query command. The Sony manual explains why: The system supports multiple CD-ROM writers under the encoder (up to 8) and when writing, the host only writes the sectors to the first LUN and it passes the data in EFM format on an optical bus to the other writers. (All writers burn the same image.) But certain commands targeted to the other LUNs for status and other enquiries return information specific for a given writer. For example, the burning software can detect and report a servo error on LUN 3 (writer 3) but that recording is progressing nicely on LUNs 0, 1, 2 and 4. Commands directly related to controller or writing activities will respond on all LUNs regardless of additional writers being present. Commands specific to individual writers (like head position status) return information on that writer, including ready/not ready status. Subsequently, referencing LUNs 1-7 when there is no hardware may return confusing/conflicting information to commands, based on how Sony categorized the commands (controller command vs lun command). Perhaps this explains the behavior you are seeing in the burner you have and this type of action probably confuses our probing routines. Frank Durda IV |"Knowledge is power, so be or uhclem%nemesis@fw.ast.com (Fastest Route)| sure to give some away today. ...letni!rwsys!nemesis!uhclem | Doing this annoys Microsoft." ...decvax!fw.ast.com!nemesis!uhclem | (C) 1995 FDIV