Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Sat, 7 Apr 2001, Thomas Hepper wrote: Well, I've tried the 'sst' driver and it works only slightly better than the 'sgen' driver. With the 'sst' driver I can send as many 'mtx inquiry' commands as I like and they all work. What about "mtx -f /dev/rsst5 status"? No dice: # mtx -f /dev/rsst5 status mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed Hmm, what happens if you use chg-scsi from the 2.5.0 development version of amanda. I'm currently working a little bit on it, and if you like we can try to get it running, either with the sgen driver or the sst driver. After some more fiddling, and discovering (somewhat red-faced, but it was at 3 am in the morning!) that the ADIC unit does *not* automatically 'load' the magazine when it receives SCSI commands addressed to the robotics, I've got the 'stctl' driver built, installed and working perfectly. 8-) I still needed to sort out the stctl code to correct the header file problems, but so far there don't seem to be any other operational problems. The fact that the driver only operates using slot numbers might be a problem at a later date if Amanda gains support for spreading large dumps over multiple tapes, but for now it's ok. Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Thu, 5 Apr 2001, John R. Jackson wrote: Well, I've tried the 'sst' driver and it works only slightly better than the 'sgen' driver. With the 'sst' driver I can send as many 'mtx inquiry' commands as I like and they all work. What about "mtx -f /dev/rsst5 status"? No dice: # mtx -f /dev/rsst5 status mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed Anyway, has anyone done much testing with the 'sst' driver in SunOS 5.8? It seems the bulk of people tend to use Linux or Windows so I guess Solaris testing is not the primary focus of the Amanda development group. Ummm, you've got that twisted a bit. I use only Solaris and AIX and I'm an Amanda developer, but don't use any of the Amanda changers (it's a long story :-), and also do not use mtx. So it's the mtx testing that might be a bit behind, not Solaris. And for that, maybe you should ask the mtx people since it's their program that's not working here, not Amanda. Sounds like a good idea. I'll pass my problems reports on to them and see what happens. Be that as it may, I have a robot and sst on Solaris 2.6 and should at least be able to get some more debugging output into the code for you to try. What version of mtx are you using? I had a HP autochanger working (as far as the robotics go) with the 'sst' code from the 2.4.1p1 distribution before, but the autochanger itself was broken. 8-) This ADIC-1200D autochanger is obviously responding differently. FYI, 1.10 works with inquiry for me but fails (I/O error) for status. Version 1.11pre2 doesn't work at all (I/O error). I'm pretty sure I can get at least those things to work for me, and possibly in the process, get the going for you. If you get some results, I'm more than happy to try things out here with my setup. I'm going to try out the stctl code tonight and have a go at using that. It's been too long between backups. 8-) Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Wednesday 04 April 2001 3:21 pm, Rhett Saunders wrote: [storage-element-number][drive#] mtx [ -f loader-dev ] [eepos eepos-number] transfer storage-element-number storage-element-number mtx [ -f device ] eject # mtx -f /dev/rsst1 first mtx: No such device or address mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed I wonder if this is related to a problem I had when setting up AMANDA using chg-scsi on a solaris box I had lying around. When doing ioctls on the scsi-generic device, the ioctl would fail unless there was a valid buffer supplied to return data in, even if the particular SCSI command was positional (i.e. move tape) and therefore wasn't going to return any data. This resulted in it simply not working for no readily apparent reason, until I bodged a small buffer into SCSI_Move() in scsi-changer-driver.c so that it always supplied one to SCSI_ExecuteCommand() -- Tim Smith ([EMAIL PROTECTED]) Rebel SpecForces foil unauthorised cloning attempt on General Madine. "I'm beside myself." says General.
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
Well, I've tried the 'sst' driver and it works only slightly better than the 'sgen' driver. With the 'sst' driver I can send as many 'mtx inquiry' commands as I like and they all work. What about "mtx -f /dev/rsst5 status"? # mtx -f /dev/rsst5 first mtx: No such device or address ... I don't know what this means, but obviously something is producing incorrect results. Any ideas on what I can look at? We need to see exactly what mtx tried to do. Unfortunately, mtx it not too good at that (see below). Anyway, has anyone done much testing with the 'sst' driver in SunOS 5.8? It seems the bulk of people tend to use Linux or Windows so I guess Solaris testing is not the primary focus of the Amanda development group. Ummm, you've got that twisted a bit. I use only Solaris and AIX and I'm an Amanda developer, but don't use any of the Amanda changers (it's a long story :-), and also do not use mtx. So it's the mtx testing that might be a bit behind, not Solaris. And for that, maybe you should ask the mtx people since it's their program that's not working here, not Amanda. Be that as it may, I have a robot and sst on Solaris 2.6 and should at least be able to get some more debugging output into the code for you to try. What version of mtx are you using? FYI, 1.10 works with inquiry for me but fails (I/O error) for status. Version 1.11pre2 doesn't work at all (I/O error). I'm pretty sure I can get at least those things to work for me, and possibly in the process, get the going for you. Craig. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Tue, 27 Mar 2001, Craig Dewick wrote: Will try the 'sst' driver out and report on it's performance after I have some sleep! 8-) Well, I've tried the 'sst' driver and it works only slightly better than the 'sgen' driver. With the 'sst' driver I can send as many 'mtx inquiry' commands as I like and they all work. Also, the 'mtx inventory' command produces a response from the robotics (the gripper arm moves out and in, but nothing else happens). However, all other commands produce SCSI errors. For example, 'mtx -f /dev/rsst5 first' produces this output: # mtx -f /dev/rsst5 first mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed and this error message is logged from the kernel: Apr 4 23:05:21 lios scsi: [ID 107833 kern.warning] WARNING: /iommu@f,e000/sbus@f,e0001000/espdma@f,40/esp@f,80/sst@5,0(sst3): Apr 4 23:05:21 liosError for Command: undecoded cmd 0xb8Error Level: Fatal Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Requested Block: 0 Error Block: 0 Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Vendor: ADIC Serial Number: Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Sense Key: Illegal Request Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0 I don't know what this means, but obviously something is producing incorrect results. Any ideas on what I can look at? With other people reporting success using an ADIC-1200 autochanger with the 'sg' driver in Linux, I'm surprised the 'sgen' and 'sst' drivers under SunOS 5.8 are giving so many hassles... Anyway, has anyone done much testing with the 'sst' driver in SunOS 5.8? It seems the bulk of people tend to use Linux or Windows so I guess Solaris testing is not the primary focus of the Amanda development group. Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Wed, 4 Apr 2001, Christopher Linn wrote: are you using gcc or SUNWspro cc? gcc. It's the only compiler I have, since I'm not about to fork out money for a commercial compiler which is less capable than the robust FSF compiler. 8-) if you are running a 64 bit kernel, then you must build your changer software in 64 bit mode; this means you cannot use gcc, since gcc doesn't do 64 bit (on solaris) yet. Nope - this machine is a Sparc 20, so it only supports 32 bit mode. also, have you seen the stctl package? http://www.cs.pdx.edu/~eric/stctl/ written for solaris, i have been using this as my changer software for several years, with both an exabyte 10-h changer and now a compaq storageworks SSL2000 series AIT2 changer; i had to tweek the timeout value for the Initialize Element Status command for the exabyte 10-h, but other than that it has been working flawlessly on solaris 2.6 and solaris 8. Can't say I have, but I will check it out. Looks like the ideal solution if the mtx/sst and mtx/sgen combinations are going to continue to give problems. Thanks very much for the pointer... Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
I have the same problem, but I doubt anyone will answer in the amanda forum, since I have asked about this issue before. Since it an mtx issue, I guess there's a different forum to discuss this. But I will post my message again... I have a SUN Enterprise 3500 with SunOS 5.7, a differential SCSI and a DLT L-280 SUN StorEdge array. I have attached the sst through add_drv successfully, and can issue a mtx command to eject, and the autoloader ejects one DLT tape and then loads another. That's the most I can do. Here is my output for the rest of the commands issued by mtx... # mtx -f /dev/rsst1 inquiry Product Type: Tape Drive Vendor ID: 'QUANTUM ' Product ID: 'DLT7000 ' Revision: '2560' Attached Changer: No # mtx -f /dev/rsst1 eject # mtx -f /dev/rsst1 inventory mtx: I/O error mtx:inventory failed # mtx --version mtx version 1.2.9 Usage: mtx --version mtx [ -f loader-dev ] noattach more commands\n mtx [ -f loader-dev ] inquiry | inventory | status mtx [ -f loader-dev ] first [drive#] mtx [ -f loader-dev ] last [drive#] mtx [ -f loader-dev ] next [drive#] mtx [ -f loader-dev ] previous [drive#] mtx [ -f loader-dev ] [invert] load storage-element-number [drive#] mtx [ -f loader-dev ] [invert] unload [storage-element-number][drive#] mtx [ -f loader-dev ] [eepos eepos-number] transfer storage-element-number storage-element-number mtx [ -f device ] eject # mtx -f /dev/rsst1 first mtx: No such device or address mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed If I can get this simple problem fixed, I'm in buisness... -- Rhett Saunders National Office Operations email: [EMAIL PROTECTED] phone: (202) 693-3275
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Mon, 26 Mar 2001, Urban Petry wrote: Which device driver are you using under Linux? The equivalent of Sun's 'sgen' driver? I am going to try the 'sst' driver supplied with Amanda today and see if I get a different result. According to the manual, the factory defaults are ID 0 for the drive and ID 3 for the robotics. I would say so, since it's the "scsi generic" driver that I use (/dev/sg1) Sounds like it's very similar to Sun's 'sgen' driver in principle. I've checked Sunsolve and there is a patch for the 'sgen' package, but it doens't apply to my platform. I have installed the Solaris 8 Maintenance Update 3 patch package today, but to no avail since the 'sgen' driver is still giving problems. Will try the 'sst' driver out and report on it's performance after I have some sleep! 8-) Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
Hi Craig, I'm using the ADIC-1200 as well (although with linux instead of sunos, mtx is the same as yours - 1.2.10). # mtx -f /dev/scsi/changer/c0t5d0 inquiry Product Type: Medium Changer Vendor ID: 'ADIC' Product ID: 'DAT AutoChanger ' Revision: '0461' Attached Changer: No So far, this is good, but I'm not quite sure why it reported the last piece of information as 'No'. I get the same information when running mtx inquiry (only you got a newer revision ;-), so that shouldn't be a problem. AFAIK the 'Attached Changer' is only yes if your tape changer and tape drive listen to the same scsi ID and thus understand both streamer and changer scsi commands (maybe different LUNs). But that's not the case with the ADIC. # mtx -f /dev/scsi/changer/c0t5d0 status mtx: no Data Transfer Element reported Hmm, have you checked the SCSI ID settings on the back of the unit ? The only situation that could lead to such an error is in my opinion (and to my knowledge) that both the changer and the tape device have the same ID set, so the changer can't find its streamer. Is the tape device listed seperately when you list all your scsi devices on that bus ? Regarding your question about replacing the shipped drive with a newer model: The same thing came to my mind as well. I already opened the case to find out, that it should be possible to replace the existing drive with another one. It shoud work as long as it's the same brand, because I have the feeling that the changer device snoops on the tape device messages on the scsi bus and I don't know how well they're standardized (e.g. the arm doesn't try to grab a tape out of the tape drive before unloading the whole cartridge unless you issued an eject command to the _tape drive_ before ...). If you have any success with this, please let me know (although I have a HP drive instead of a sony). Urban
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Sun, 25 Mar 2001, Urban Petry wrote: Hi Craig, I'm using the ADIC-1200 as well (although with linux instead of sunos, mtx is the same as yours - 1.2.10). Which device driver are you using under Linux? The equivalent of Sun's 'sgen' driver? I am going to try the 'sst' driver supplied with Amanda today and see if I get a different result. According to the manual, the factory defaults are ID 0 for the drive and ID 3 for the robotics. Are you using your ADIC-1200 in random-access or sequential mode? Mine is set to random-access mode with the jumper installed on the small PCB inside the front of the autochanger door. # mtx -f /dev/scsi/changer/c0t5d0 inquiry Product Type: Medium Changer Vendor ID: 'ADIC' Product ID: 'DAT AutoChanger ' Revision: '0461' Attached Changer: No So far, this is good, but I'm not quite sure why it reported the last piece of information as 'No'. I get the same information when running mtx inquiry (only you got a newer revision ;-), so that shouldn't be a problem. AFAIK the 'Attached Changer' is only yes if your tape changer and tape drive listen to the same scsi ID and thus understand both streamer and changer scsi commands (maybe different LUNs). But that's not the case with the ADIC. They're set to different ID's. The Sony drive is ID 4, and the robotics are ID 5. # mtx -f /dev/scsi/changer/c0t5d0 status mtx: no Data Transfer Element reported Hmm, have you checked the SCSI ID settings on the back of the unit ? The only situation that could lead to such an error is in my opinion (and to my knowledge) that both the changer and the tape device have the same ID set, so the changer can't find its streamer. Is the tape device listed seperately when you list all your scsi devices on that bus ? I might alter the ID settings so the robotics are on a lower ID that the drive, but it should be irrelevant providing the ID's are actually different. Regarding your question about replacing the shipped drive with a newer model: The same thing came to my mind as well. I already opened the case to find out, that it should be possible to replace the existing drive with another one. It shoud work as long as it's the same brand, because I have the feeling that the changer device snoops on the tape device messages on the scsi bus and I don't know how well they're standardized (e.g. the arm doesn't try to grab a tape out of the tape drive before unloading the whole cartridge unless you issued an eject command to the _tape drive_ before ...). If you have any success with this, please let me know (although I have a HP drive instead of a sony). If I actually do this, I will let you know how it goes. I think you might be right about the changer electronics watching SCSI activity for the drive. There's quite a lot of smarts on the robotics control board, judging by the ammount of hardware on the changer PCB. Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
Which device driver are you using under Linux? The equivalent of Sun's 'sgen' driver? I am going to try the 'sst' driver supplied with Amanda today and see if I get a different result. According to the manual, the factory defaults are ID 0 for the drive and ID 3 for the robotics. I would say so, since it's the "scsi generic" driver that I use (/dev/sg1) Are you using your ADIC-1200 in random-access or sequential mode? Mine is set to random-access mode with the jumper installed on the small PCB inside the front of the autochanger door. Yepp. I might alter the ID settings so the robotics are on a lower ID that the drive, but it should be irrelevant providing the ID's are actually different. I hope it is ;-) On my systwm the drive is ID 3 and the changer is ID 5 Godd luck ! Urban
more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
Hiya, Ok, I've reconfigured my system now so that all SCSI devices except the autochanger are attached to the wide SCSI controller my SunSwift card. The autochanger is the sole occupant of the standard narrow scsi bus. My setup is - Sparc 20, Solaris 8, mtx-1.2.10, SunOS 'sgen' driver for changer I've typed a series of commands using 'mtx' to talk to the autochanger, and the results are not good: # ls -sal /dev/scsi/changer total 6 2 drwxr-xr-x 2 root root 512 Mar 24 10:13 . 2 drwxr-xr-x 3 root root 512 Mar 24 10:13 .. 2 lrwxrwxrwx 1 root root 95 Mar 24 10:13 c0t5d0 - ../../../devices/iommu@f,e000/sbus@f,e0001000/espdma@f,40/esp@f,80/sgen@5,0:changer This was to confirm that the sgen driver had detected the autochanger and attached properly. # mtx -f /dev/scsi/changer/c0t5d0 inquiry Product Type: Medium Changer Vendor ID: 'ADIC' Product ID: 'DAT AutoChanger ' Revision: '0461' Attached Changer: No This caused the 'sgen' driver to initialise itself and print the usual messages in the console window, and the autochanger responded correctly. So far, this is good, but I'm not quite sure why it reported the last piece of information as 'No'. # mtx -f /dev/scsi/changer/c0t5d0 status mtx: no Data Transfer Element reported Starting to be a problem. I don't know what the error message means, but my presumption is that mtx didn't get a response where one was expected. # mtx -f /dev/scsi/changer/c0t5d0 inventory mtx: Invalid argument mtx:inventory failed I tried this since it shows up as a valid option with 'mtx --version' in the usage report. # mtx -f /dev/scsi/changer/c0t5d0 inquiry mtx: I/O error mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: INQUIRY Command Failed This is the first clear failure. After this I cycled the power to the autochanger, and tried these commands: # mtx -f /dev/scsi/changer/c0t5d0 first mtx: no Data Transfer Element reported Strange, since the autochanger had just been power-cycled. # mtx -f /dev/scsi/changer/c0t5d0 inquiry mtx: I/O error mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: INQUIRY Command Failed Once again, a clear failure of SCSI communication. Now since I'd just cycled the power to the autochanger, this, to me, points to a problem with software on this machine since the ADIC unit should have come back with a valid response. From here, I can take a few different course of action. The one I'm thinking of trying the most is to discontinue use of the 'sgen' driver and install the 'sst' driver from the amanda-2.4.2p1 source tree to see if that reacts correctly when 'mtx' send commands to the autochanger. Another possibility is that 'mtx' itself is broken as far as working with the 'sgen' driver is concerned. I had it talking fairly successfully to one of the HP 6-tape autochangers before when I was using 2.4.1p1 with the 'sst' driver. Are there any known problems with v1.2.10 of 'mtx' that might affect it's performance with the SunOS 'sgen' driver? Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point a web browser at 'http://lios.apana.org.au/~cdewick/sun_shack.html' to access my archive of Sun information and links to other places. For info about Sun Ripened Kernels, go to "http://www.sunrk.com.au"
