Re: Sony VGP-XL1B (200 disk CD/DVD jukebox)

Re: Sony VGP-XL1B (200 disk CD/DVD jukebox)

[Stefan Richter]

(added Cc: linux-scsi and quoting in full...)

Josha Foust wrote to linux1394-user:
> I've made some progress with mtx.  Is this the right place to talk about
> issues with mtx?

I hope some readers of linux-scsi have advice. I have only a few
comments, see below.

> I noticed the name STARMATIX in the gscanbus output and found this page:
> http://www.linux1394.org/view_device.php?id=512
> I first tried version 1.3.8 without the patch and it didn't help
> anything (I was using 1.2.17rel).  With the patch I got some stuff to
> work.
> 
> The status, load and unload commands now work, mostly.  The status
> command only shows 38 storage elements with the first one being the data
> transfer element and the last one being the import/export slot.
> 
> It will load and unload and I can mount the drive.  Unfortunately I
> can't always safely unload the drive (i.e. you can hear the media
> scraping against something to stop it spinning, and the media was
> damaged).  Hopefully I haven't damanged the drive...  The first time I
> accidently did it when it was mounted, but the 2nd time it seems I just
> did it too soon after the optical drive (sr0) was last accessed and it
> was still spinning.
> 
> The stop command that was added with the patch returns 'mtx:start
> failed' if it doesn't want to stop at that time.  You have to keep
> retrying until it works.  I guess if I don't get the error then it
> should be safe to unload.  Maybe there is a good reason it can't stop it
> from spinning at the time?  It can take a while before it will finally
> stop.  Maybe I'll just patch mtx to retry stop until it works before
> allowing an unload, or write a wrapper program.
> 
> I found this in dmesg from what I think was the first bad unload:
> ieee1394: sbp2: aborting sbp2 command
> sr 5:0:1:0:
>         command: Prevent/Allow Medium Removal: 1e 00 00 00 00 00
> ieee1394: unsolicited response packet received - no tlabel match
> sr 5:0:1:0: ioctl_internal_command return code = 8000002
>    : Current: sense key: Hardware Error
>     Additional sense: Timeout on logical unit
> However I haven't seen it since.

"unsolicited response packet received - no tlabel match" could have
different reasons. A tlabel a.k.a. transaction label is used in the
FireWire protocol to match response packets with previously sent request
packets. A tlabel mismatch means that either the FireWire drivers
wrongly dropped a request too early, or the device's firmware somehow
generated a wrong tlabel, or there went something wrong with the
FireWire bus. You should check dmesg for messages like "ieee1394: sbp2:
Reconnected to SBP-2 device". These should _not_ happen during normal IO.

> If the drive is mounted and I tell it to unload, it does it, but it
> gives this error:
> Unloading drive 0 into Storage Element 3...mtx: Request Sense: 70 00 00
> 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 00
> MOVE MEDIUM from Element Address 2 to 6 Failed
> Is that an error that could be detected before the unload action and
> prevent the unload from occuring?
> 
> The transfer and exchange commands don't seem to work with this unit.  I
> guess it just doesn't support them.  The 'next' command works, but it
> worries me that it might try and unload without stopping the media from
> spinning.  The drive doesn't seem to need the special eject like the
> C200.  I also don't seem to have the problem with the media change
> signals, maybe it was fixed in later kernel versions?
> 
> I managed to crash the unit trying to use the position command.  I had
> to reboot the unit to get it working again.  Here is the dmesg output:
> ieee1394: sbp2: aborting sbp2 command
>  6:0:2:0:
>         command: Inquiry: 12 00 00 00 38 00
> ieee1394: sbp2: aborting sbp2 command
>  6:0:2:0:
>         command: Test Unit Ready: 00 00 00 00 00 00
> ieee1394: sbp2: reset requested
> ieee1394: sbp2: Generating sbp2 fetch agent reset
> ieee1394: sbp2: aborting sbp2 command
>  6:0:2:0:
>         command: Test Unit Ready: 00 00 00 00 00 00
>  6:0:2:0: scsi: Device offlined - not ready after error recovery
> mtx[15550]: segfault at 0000000000000004 rip 000000000040361d rsp
> 00007fff501a27a0 error 4
> 
> I can't seem to reproduce the crash, it doesn't do anything and I just
> get this all of the time:
> mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00
> READ ELEMENT STATUS Command Failed
> 
> The biggest problem is that it says it only has 38 slots.  Any ideas on
> that one?

Hm. I suppose this number is obtained from the NUMBER OF STORAGE
ELEMENTS in the Element Address Assignment mode page. Perhaps the
firmware generates a malformed mode page. The sbp2 driver passes all
these mode parameters from the device through to the SCSI drivers and
applications as-is. (The contents of this mode page is defined by the
SMC-3 or SMC-2 or SMC spec at http://www.t10.org/drafts.htm.)

> By the way, I am running the latest 2.6.17 linux kernel that Debian
> ships on amd64.
> 
> Josha Foust
> 
> On Sat, 2006-11-04 at 18:07 -0600, Josha Foust wrote:
>> So I bought one of these devices on the hope that I could get it to work
>> under linux, don't let me down guys! :)
>>
>> It seems to connect and detect fine, here is the related output:
>> ieee1394: sbp2: Logged into SBP-2 device
>> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
>>   Vendor: MATSHITA  Model: DVD-RAM SW-9584   Rev: B104
>>   Type:   CD-ROM                             ANSI SCSI revision: 00
>> scsi4 : SBP-2 IEEE-1394
>> sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
>> sr 2:0:1:0: Attached scsi CD-ROM sr0
>> sr 2:0:1:0: Attached scsi generic sg2 type 5
>> ieee1394: sbp2: Logged into SBP-2 device
>> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
>>   Vendor: Sony      Model: VAIOChanger1      Rev: 0100
>>   Type:   Medium Changer                     ANSI SCSI revision: 03
>>  4:0:2:0: Attached scsi generic sg3 type 8
>>
>> gscanbus shows:
>> SelfID Info
>> -----------
>> Physical ID: 0
>> Link active: Yes
>> Gap Count: 63
>> PHY Speed: S400
>> PHY Delay: <=144ns
>> IRM Capable: Yes
>> Power Class: None
>> Port 0: Not connected
>> Port 1: Not connected
>> Port 2: Connected to parent node
>> Init. reset: No
>>
>> CSR ROM Info
>> ------------
>> GUID: 0x003060A100012285
>> Node Capabilities: 0x000083C0
>> Vendor ID: 0x00003060
>> Unit Spec ID: 0x0000609E
>> Unit SW Version: 0x00010483
>> Model ID: 0x00000000
>> Nr. Textual Leafes: 2
>>
>> Vendor:  STARMATIX, INC.
>> Textual Leafes: 
>> Sony
>> VGP-XL1B
>>
>> AV/C Subunits
>> -------------
>> N/A
>>
>> mtx gives this from a inquiry reqest of /dev/sg3:
>> Product Type: Medium Changer
>> Vendor ID: 'Sony    '
>> Product ID: 'VAIOChanger1    '
>> Revision: '0100'
>> Attached Changer: No
>>
>> That last line is a problem, correct?

It shouldn't be, unless mtx doesn't fully support "independent" media
changers. Since media changer and CD/DVD-R/W are presented as separate
logical units on the SBP-2 target, it obviously implements the
independent media changer model, not the attached media changer model.
These terms are again defined by the SMC(-2,3) spec.

>> I haven't managed to get mtx to
>> make the changer do anything (with or without the noattach option).  It
>> just reports 'no Data Transfer Element reported' for most other
>> commands.  It is a bit noisy when the carousel moves, so I should be
>> able to tell if anything happens.
>>
>> mtx commands against sg2 just give this error message:
>> mtx: Request Sense: Long Report=yes
>> mtx: Request Sense: Valid Residual=no
>> mtx: Request Sense: Error Code=0 (Unknown?!)
>> mtx: Request Sense: Sense Key=No Sense
>> mtx: Request Sense: FileMark=no
>> mtx: Request Sense: EOM=no
>> mtx: Request Sense: ILI=no
>> mtx: Request Sense: Additional Sense Code = 00
>> mtx: Request Sense: Additional Sense Qualifier = 00
>> mtx: Request Sense: BPV=no
>> mtx: Request Sense: Error in CDB=no
>> mtx: Request Sense: SKSV=no
>> READ ELEMENT STATUS Command Failed
>>
>> I assume that is just a complete failure because it is not a media
>> changer device.

Yes, mtx needs to talk to /dev/sg3 to change media. I guess mtx or
whatever application client needs to talk to /dev/sg2 or /dev/sr0 to
stop the CD/DVD-R/W from spinning, unlock its tray, etc. (by means of
START STOP UNIT, PREVENT ALLOW MEDIUM REMOVAL commands). Your newer
posting looks like mtx is indeed using /dev/sg3 and /dev/sr0 as necessary.

It is not entirely unexpected that the changer does not support all of
the SCSI commands that mtx is obviously able to generate. Many commands
are only optional according to SMC(-2,3). Mandatory commands for the
media changer unit are:
INQUIRY
MOVE MEDIUM
READ ELEMENT STATUS
REQUEST SENSE
SEND DIAGNOSTIC
TEST UNIT READY

The commands that are to be implemented by the CD/DVD-R/W unit are
defined by the MMC(-?) spec.

I don't know if it is a problem for mtx that media changer and "primary
device" i.e. CD/DVD-R/W are associated with different device files (this
happens with all independent media changers), and are even attached to
two different "Linux SCSI hosts" (this is due to implementation details
of sbp2's interface to Linux' SCSI core even though both devices are
actually two units on the same SBP-2 target).

BTW, if you have a reasonably recent version of udev, you could
certainly also use persistent device file names according to
/sys/bus/scsi/devices/*/ieee1394_id which has the format
EUI64_of_node:number_of_unit_directory:logical_unit_number, instead of
the names /dev/sg* and /dev/sr* which may change by hotplugging.
-- 
Stefan Richter
-=====-=-==- =-== --=-=
http://arcgraph.de/sr/

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sony VGP-XL1B (200 disk CD/DVD jukebox)

[Josha Foust]

On Sun, 2006-11-05 at 10:57 +0100, Stefan Richter wrote: 
> > The biggest problem is that it says it only has 38 slots.  Any ideas on
> > that one?
> 
> Hm. I suppose this number is obtained from the NUMBER OF STORAGE
> ELEMENTS in the Element Address Assignment mode page. Perhaps the
> firmware generates a malformed mode page. The sbp2 driver passes all
> these mode parameters from the device through to the SCSI drivers and
> applications as-is. (The contents of this mode page is defined by the
> SMC-3 or SMC-2 or SMC spec at http://www.t10.org/drafts.htm.)

Thanks for the reference, that is very useful information.

I haven't seen any more SCSI kernel errors in the log.  I think it is ok
as long as you are careful to send the unit commands that it likes.  I
am mainly writing this as a status report on making the unit work under
Linux.

I have determined what is occurring with the unit in regard to the
number of storage elements.  Primarily, it is buggy and doesn't follow
the spec (as I understand it).  MODE SENSE reports 200 storage elements,
1 import/export element, 1 data transfer element and 1 medium transport
element.  This is correct.  However, getting all of the data on these
elements is a bit more difficult.

Apparently READ ELEMENT STATUS on this device will only return a maximum
of 40 elements at a time, even if it should have plenty of space in the
element status page.  The kicker is that if you ask for less than *or
equal to* the number of elements it wants to return, it will freak out.
If the previous command was an element status request it will just
return the previous response.  If it wasn't, it will crash the device
and require a power cycle.

So you have to send 6 separate READ ELEMENT STATUS requests with
"starting element addresses" incrementing (by 40) and a "number of
elements" field of at least 41 to be safe, to get all of the information
from the media changer.  I ended up doing this and stitching the data
back together as if I had gotten back all of the information in a single
packet.  Then the standard parsing routines in mtx can read it.

The other problem is that it reports an extra storage element whose
element address is the one for the medium transport element (0).  Oddly,
it comes at the very end of the first element status packet of 40
elements.  That makes a total of 204 elements reported when there should
have only been 203 according to MODE SENSE (which complicates any
generic method for requesting all of the elements' statuses).  I simply
made mtx ignore any storage element information whose element address is
the same as the transport element address.  I don't understand what its
purpose might be, any ideas?

I now have a mtx program that operates all of the basic functions of the
media changer: load, unload, transfer, and status.

My main remaining concern is with the safe operation of the unload
command.  As I mentioned in a previous email, the media changer is
perfectly happy to unload a disk from the drive while it is still
spinning, obviously causing damage to the disk and possibly the changer.
With the stop command that Dan Dennedy added in his patch to mtx, I can
get the drive stopped if I retry until the command succeeds.  I am
worried about race conditions, however.  Is there a way to lock a SCSI
device for exclusive access so that I can guarantee a safe unload?  I.E.
that the disk stays stopped while the media changer unloads it.

> BTW, if you have a reasonably recent version of udev, you could
> certainly also use persistent device file names according to
> /sys/bus/scsi/devices/*/ieee1394_id which has the format
> EUI64_of_node:number_of_unit_directory:logical_unit_number, instead of
> the names /dev/sg* and /dev/sr* which may change by hotplugging.

Thanks for the tip.

Josha Foust



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Sony VGP-XL1B (200 disk CD/DVD jukebox)

[Douglas Gilbert]

Josha Foust wrote:
<snip>

> My main remaining concern is with the safe operation of the unload
> command.  As I mentioned in a previous email, the media changer is
> perfectly happy to unload a disk from the drive while it is still
> spinning, obviously causing damage to the disk and possibly the changer.
> With the stop command that Dan Dennedy added in his patch to mtx, I can
> get the drive stopped if I retry until the command succeeds.  I am
> worried about race conditions, however.  Is there a way to lock a SCSI
> device for exclusive access so that I can guarantee a safe unload?  I.E.
> that the disk stays stopped while the media changer unloads it.

The PREVENT ALLOW MEDIUM REMOVAL command is defined for
SMC devices (see SPC-3 as SPC-4 has devolved that command
and it is yet to appear explicitly in SMC-3). That isn't
exactly what you asked for but it will impede a START
STOP UNIT (start_bit=0, loej_bit=1) command.

<snip>

Doug Gilbert