Sony VGP-XL1B (200 disk CD/DVD jukebox)
(added Cc: linux-scsi and quoting in full...)
Josha Foust wrote to linux1394-user:
Quoted 2 lines
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.
Quoted 26 lines
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.
Quoted 9 lines
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_commandreturn 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.
Quoted 32 lines
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 00ieee1394: 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 006:0:2:0: scsi: Device offlined - not ready after error recovery
mtx[15550]: segfault at 0000000000000004 rip000000000040361drsp00007fff501a27a0error 4
Quoted 8 lines
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 FailedThe 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.)
Quoted 66 lines
By the way, I am running the latest 2.6.17 linux kernel that Debian ships on amd64.
Josha Foust
Quoted 60 lines · Josha Foust
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 8gscanbus 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: NoCSR ROM Info
------------
GUID:0x003060A100012285
Node Capabilities:0x000083C0
Vendor ID:0x00003060
Unit Spec ID:0x0000609E
Unit SW Version:0x00010483
Model ID:0x00000000
Nr. Textual Leafes: 2Vendor: STARMATIX, INC.
Textual Leafes:
Sony
VGP-XL1BAV/C Subunits
-------------
N/Amtx gives this from a inquiry reqest of
/dev/sg3:
Product Type: Medium Changer
Vendor ID: 'Sony '
Product ID: 'VAIOChanger1 '
Revision: '0100'
Attached Changer: NoThat 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.
Quoted 21 lines
Quoted 21 lines
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
Quoted 2 lines
Quoted 2 lines
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.
Signature · 9 lines
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
Quoted 9 lines · Stefan Richter
Quoted 2 lines
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.
Quoted 5 lines
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_idwhich 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
Josha Foust wrote:
<snip>
Quoted 9 lines
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