CentOs 4.3 with kernel 2.6.9-34.0.2.ELsmp (x86_64): [EMAIL PROTECTED] ~]# uname -a Linux abel 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux Here's what I get when you I cat the device entry in proc: [EMAIL PROTECTED] ~]# cat /proc/scsi/qla1280/0 QLogic PCI to SCSI Adapter for ISP 1280/12160: Firmware version: 8.15.00, Driver version 3.24.4 SCSI Host Adapter Information: QLA1240 Request Queue count= 0x100, Response Queue count= 0x10 Number of pending commands = 0x0 Number of free request entries = 237 Strange thing though, I get garbage every second time I try to view the contents of this file.... Jean-Francois Malouin wrote: * Luc Lalonde <[EMAIL PROTECTED]> [20060814 12:08]:Hello Jean-François,I seem to be having problems with the SCSI controller: st0: Error 80000 (sugg. bt 0x0, driver bt 0x0, host bt 0x8). scsi(0): Resetting Cmnd=0x000001008229b6c0, Handle=0x0000000000000202, action="" scsi(0:0:6:0): Queueing device reset command. Are your LTO drives HVD or LVD... and what controller are you using? I'm using the same model (QLA1240) that was on the SGI... with no luck it seems.My LTO1s are all HVD. Controllers are the same as you have. I suspect you're being bitten by your driver and/or kernel combo... On what box are you doing this?Bye. Luc Lalonde wrote:Hello Jean-François, I think I found the problem. I have another old binary 'mt' in the PATH that is causing the problem. After removing I get the same output as you do: [EMAIL PROTECTED] ~]# mt -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN [EMAIL PROTECTED] bin]# /bin/mt -f /dev/nst1 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN When I do an amcheck I get this error (changerdev "/dev/sg0"): scsi(0): Resetting Cmnd=0x000001000b06b880, Handle=0x0000000000000202, action="" scsi(0:0:6:0): Queueing device reset command. So the changer seems to be struggling... I'm continuing my investigations... Thanks again for your input... Luc Lalonde wrote:Hello Jean-François, I'm getting this weird message with 'mt': [EMAIL PROTECTED] ~]# mt -f /dev/nst0 status Unknown tape drive type (0x72): residual= 0 ds = 200 er = 0 file no= 0 block no= 0 What I don't understand is that it seems to be correctly recognized by the system: [EMAIL PROTECTED] ~]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: STK Model: L40 Rev: 0215 Type: Medium Changer ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 15 Lun: 00 Vendor: SEAGATE Model: ULTRIUM06242-XXX Rev: 1619 Type: Sequential-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 01 Id: 15 Lun: 00 Vendor: SEAGATE Model: ULTRIUM06242-XXX Rev: 1619 Type: Sequential-Access ANSI SCSI revision: 03 Any ideas? By the way, the jukebox is connected to the server via a Qlogic QLA1240. What are you using on your Linux box? Thanks again. PS: 'mtx -f /dev/sg0 status' seems to work fine. I get a full report of the contents of my library. Jean-Francois Malouin wrote:* Luc Lalonde <[EMAIL PROTECTED]> [20060811 11:52]:Hello Folks, I'm getting this error when I try to use the tapes (LTO1) on a StorageTek L40 Jukebox: st1: Block limits 1 - 16777215 bytes. st1: Incorrect block size. st1: Incorrect block size. scsi(0): Resetting Cmnd=0x000001004a871b00, Handle=0x0000000000000202, action="" scsi(0:1:15:0): Queueing device reset command. st1: Error with sense data: Current st1: sense key Not Ready Additional sense: Logical unit not ready, cause not reportable I'm in the process of migrating Amanda from a SGI (Origin 300) server to a Linux server. I'm hoping that I don't have to re-label all my tapes and lose the backups created with the old SGI Amanda server.I'm in the middle of relocating our entire computer room so I'll be brief :) I have a bunch of LTO1s in a L80 hooked to a O3k so that's essentially what you have. I'll be moving this to a Debian system soon and in my testings I could drive the library and tape drives with mtx and mt no problem except for the hardware compression bit on the drive: after much mucking around with stinit I couldn't disable it but seems the for LTO that's not a problem. Still looking for a way to disable it though. To your problem: what does 'mt status' says? Here's what I got on a Debian system running 2.6.x ~# mt -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN ~# ./amtapetype -o -f /dev/nst0 -e 100g Writing 1024 Mbyte compresseable data: 35 sec Writing 1024 Mbyte uncompresseable data: 69 sec WARNING: Tape drive has hardware compression enabled Estimated time to write 2 * 102400 Mbyte: 13800 sec = 3 h 50 min wrote 3178496 32Kb blocks in 97 files in 6880 seconds (short write) wrote 3194880 32Kb blocks in 195 files in 6886 seconds (short write) define tapetype unknown-tapetype { comment "just produced by tapetype prog (hardware compression on)" length 99584 mbytes filemark 0 kbytes speed 14815 kps } HTH jfThanks!-- Luc Lalonde, analyste --------------------------------------------------------------------- Département de génie informatique: Éole polytechnique de Montréal (514) 340-4711 x5049 [EMAIL PROTECTED] --------------------------------------------------------------------- Never try to teach a pig to sing. It wastes your time, and it annoys the pig. --------------------------------------------------------------------- -- Luc Lalonde, analyste --------------------------------------------------------------------- Département de génie informatique: Éole polytechnique de Montréal (514) 340-4711 x5049 [EMAIL PROTECTED] --------------------------------------------------------------------- Never try to teach a pig to sing. It wastes your time, and it annoys the pig. --------------------------------------------------------------------- |
- Re: Amanda migration from SGI-Irix to Linux Luc Lalonde
- Re: Amanda migration from SGI-Irix to Linux Luc Lalonde