On 2 Feb at 23:59 "Dustin J. Mitchell" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>
> On Feb 1, 2008 6:38 AM, Tony van der Hoff <[EMAIL PROTECTED]> wrote: > > Meanwhile, and maybe easier to diagnose, I find: >>GMT_ONLINE > > [EMAIL PROTECTED]:~$ sudo ammt -t /dev/nht0 status tapedev /dev/nht0 is > > offline or has no loaded tape. /dev/nht0 status failed: Success >> > > Whereas: >> > > [EMAIL PROTECTED]:~$ sudo mt -t /dev/nht0 status drive type = Generic SCSI-2 > > tape drive status = 512 sense key error = 0 residue count = 0 file > > number = 0 block number = 0 Tape block size 512 bytes. Density code 0x0 > > (default). Soft error count since last status=0 General status bits on > > (4000000): >> WR_PROT >> > > I have attached the strace dumps for all 3 commands. Thanks again for > > your help. > > From the strace, it looks like both applications (ammt and mt) are making > the same syscalls, but getting different results: > > mt: open("/dev/nht0", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3 fstat64(3, > {st_mode=S_IFCHR|0660, st_rdev=makedev(37, 128), ...}) = 0 ioctl(3, > MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0xbfa50750) = 0 > ioctl(3, MGSL_IOCSTXIDLE or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0xbfa50738) = > 0 > > ammt: open("/dev/nht0", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, MGSL_IOCSTXIDLE > or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0xbf884cd8) = 0 > > It comes from this code in taper-src/output-tape.c: > 537 #ifdef GMT_ONLINE > 538 if (!GMT_ONLINE(mt.mt_gstat)) { > 539 close(ret); > 540 fprintf(stderr, "tapedev %s is offline or has no loaded > tape.\n", > 541 filename); > 542 return -1; > 543 } 544 #endif /* GMT_ONLINE */ > > So I think the only conclusion is that something in your config is buggy, > and MTIOCGET is not returning an "ONLINE" state. Unfortunately, strace > doesn't give us any insight into the contents of the 'mt' struct. > > The new device-src/tape-posix.c does a similar thing: > > 145 TapeCheckResult tape_is_ready(int fd) { > 146 struct mtget get; > 147 if (0 == ioctl(fd, MTIOCGET, &get)) { > 148 #if defined(GMT_ONLINE) || defined(GMT_DR_OPEN) > 149 if (1 > 150 #ifdef GMT_ONLINE > 151 && GMT_ONLINE(get.mt_gstat) > 152 #endif > 153 #ifdef GMT_DR_OPEN > 154 && !GMT_DR_OPEN(get.mt_gstat) > 155 #endif > 156 ) { > 157 return TAPE_CHECK_SUCCESS; > 158 } else { > 159 return TAPE_CHECK_FAILURE; > 160 } > 161 #else /* Neither macro is defined. */ > 162 return TAPE_CHECK_UNKNOWN; > 163 #endif > 164 } else { > 165 return TAPE_CHECK_FAILURE; > 166 } > 167 } > > Neither looks obviously incorrect, but I'm not well-versed in the posix > tape interface. I think the best trick at this point may be to upgrade > your kernel and/or tape drivers, but if you're interested in getting > low-level, you could compile Amanda with debugging symbols (./configure > ... CFLAGS=-g ...) and then run ammt under gdb, break on tape_tape_open, > and investigate the contents of the 'mt' struct. As is always a > frustration with hardware-related questions, this is not something anyone > can investigate on your behalf :( > > Another solution may be to just delete lines 537-544, recompile, and see > what happens. OK, after some digging about, I find the following. Whether it's an Amanda bug, or a kernel bug, I'll leave to more capable people to decide :) >From the kernel sources, the Generic Magtape On-Line bit (GMT_ONLINE) is defined by include/linux/mtio.h. However, this bit is presumably meaningful for the SCSI tape interface (drivers/scsi/st.c), but has no meaning for the IDE tape interface (drivers/ide/ide-tape.c), where a tape can't be taken off-line. Consequently ide-tape.c does not return this flag (st.c does). Looking at the sources for GNU mt and mt-st, neither makes any assumptions about GMT_ONLINE, although mt-st (which is the SCSI-enhanced version of mt) reports it if set. Amanda, on the other hand, faults it if not set. In view of the kernel's actions, this is probably a bit over-enthusiastic. It could be argued that the kernel, having defined the flag in mtio.h, should just return it set for an IDE tape, which I guess is what the now deprecated ide-scsi interface did. My upgrade to a later kernel, and abandoning ide-scsi in favour of ide-tape has shown up this incompatibility. My solution was to adopt Dustin's suggestion, and comment out the lines 537-544 in output-tape.c. It worked for me; but obviously a more permanent fix is required. Cheers, Tony -- Tony van der Hoff | mailto:[EMAIL PROTECTED] Buckinghamshire, England