Re: Exabyte VXA-2-Packet-Loader: new problem

OK. Some progress here.

First, my crontab script had an error in that the amtape command should have been /usr/sbin/amtape NOT /usr/bin/amtape.

With this fixed, the backup ran normally last night and this morning, a fresh tape is in the next slot for the next backup. GREAT !!

Second, I was stupidly issuing "mtx -f /dev/nst1 inquiry" instead of "mtx -f /dev/sg5 inquiry" and this got me all wrapped around the axle.

I seem to have better luck with the old ncr52c8xx driver. This may be an Alpha thing, not sure. I think I am having timing problems that could get corrected with a tailored /etc/amanda/new/changer.conf parameters file. I plan to study Chapter 9 and 10 of the AMANDA docs and see if I can figure this out. I need to do this because I still get strange error messages with the amtape command and it should not be necessary to issue two identical amtape commands in a row to get it to work.

I will post back here if I figure something out. At least I have a workable backup system running now with the new packet loader and AMANDA.

On Tue, 2005-02-15 at 13:00 -0500, James D. Freels wrote:

Recall I had a problem getting this device to work properly when it failed to write to the tape. This problem was correct by a new and separate scsi card dedicated to the packet loader.

When I use the older ncr53c7xx driver in Linux, it works OK, but does not automatically reload tapes. Here is my crontab entry:

/usr/sbin/amdump new;/usr/bin/amtape new slot next;/usr/bin/amtape new slot next

When I do this at the console, it works fine. However, as a cron job, the amtape commands never work. It is necessary to issue two amtape commands because the first one unloads the tape, but does not load the next one as it is supposed to do. After the first command, I get the following error message:

amtape: could not load slot 4: Unloading Data Transfer Element into Storage Element 4...mtx: Request Sense: Long Report=yes

After I issue the "amtape new slot next" command again, it loads the tape (with the older ncr53c8xx driver).

Then I booted linux with the newer sym53c8xx-2 driver. The amdump command works correctly. The first amtape command also works and unloads the tape as before. However,when I issue the second amtape command, I get the following message to the console:

failed to set sg timeout - Invalid argument

In fact, any mtx command respnds the same way at this point. Checking the /var/log/messages log, I find the following:

Feb 15 12:41:59 fea5 kernel: sym1:3:0: ABORT operation started.
Feb 15 12:41:59 fea5 kernel: sym1:3:control msgout: 80 6.
Feb 15 12:41:59 fea5 kernel: sym1:3:0: ABORT operation complete.
Feb 15 12:42:09 fea5 kernel: sym1:3:0: ABORT operation started.
Feb 15 12:42:14 fea5 kernel: sym1:3:0: ABORT operation timed-out.
Feb 15 12:42:14 fea5 kernel: sym1:3:0: DEVICE RESET operation started.
Feb 15 12:42:19 fea5 kernel: sym1:3:0: DEVICE RESET operation timed-out.
Feb 15 12:42:19 fea5 kernel: sym1:3:0: BUS RESET operation started.
Feb 15 12:42:19 fea5 kernel: sym1: SCSI BUS reset detected.
Feb 15 12:42:19 fea5 kernel: sym1: SCSI BUS has been reset.
Feb 15 12:42:19 fea5 kernel: sym1:3:0: BUS RESET operation complete.
Feb 15 12:42:24 fea5 kernel: scsi: device set offline - not ready or command retry failed after bus reset: host 1 channel 0 id 3 lun 0

I am wondering if perhaps I need to downgrade the packet-loader option from "native" to a compatibility mode to let amanda be compatible with this changer ?