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 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
