Date: Mon, 19 Dec 2005 10:38:49 +0100 From: =?ISO-8859-15?Q?Christian_Gr=FCndemann?= <mailing@libet.de> To: Scott Long <scottl@samsco.org> Cc: freebsd-stable@freebsd.org Subject: Re: DLT Tape Read errors on aac0 Message-ID: <43A67FA9.5070308@libet.de> In-Reply-To: <43A5B2BC.6050307@samsco.org> References: <43A57DBF.6050404@libet.de> <43A580A9.5090504@libet.de> <43A5B2BC.6050307@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long schrieb: > First of all, let me apologize for the mess that is the aac passthrough > driver. I wrote it in hopes that it would be useful, but the support > needed for it in the aac firmware simply isn't robust enough for the > kind of SCSI stuff that FreeBSD does. In other words, it's a hack from > top to bottom, and really is little more than a novelty at this point. > > See below... > > Christian Gründemann wrote: > >> Waah, I forgot the most important information. >> >> Its an 5.3-STABLE FreeBSD Operating System. >> :-) >> Christian >> >> >> Christian Gründemann schrieb: >> >>> Hi, >>> >>> I am using an Adaptec SCSI RAID 2120S Card with 5 SCSI >>> Seagate drives as a RAID-5 without any probelms for almost two years >>> now. >>> >>> Last week I attached to the aac0 controller a Tandberg DLT Drive >>> QUANTUM DLT VS160 2500 Removable Sequential Access SCSI-2 device >>> for large backup purposes. >>> >>> We decided to use dump/restore for our backup strategy but >>> unfortunately we can >>> only make backups and no restores. E.g dumping a filesystem works >>> great: >>> >>> root@hercules ~ dump -0aLf /dev/sa0 /var >>> DUMP: Date of this level 0 dump: Tue Dec 20 15:44:05 2005 >>> DUMP: Date of last level 0 dump: the epoch >>> DUMP: Dumping snapshot of /dev/aacd0s1f (/var) to /dev/sa0 >>> DUMP: mapping (Pass I) [regular files] >>> DUMP: mapping (Pass II) [directories] >>> DUMP: estimated 63220 tape blocks. >>> DUMP: dumping (Pass III) [directories] >>> DUMP: dumping (Pass IV) [regular files] >>> DUMP: DUMP: 64341 tape blocks on 1 volume >>> DUMP: finished in 15 seconds, throughput 4289 KBytes/sec >>> DUMP: Closing /dev/sa0 >>> DUMP: DUMP IS DONE >>> root@hercules ~ >>> >>> I guess the backup has been successfully finished. >>> >>> But when I try a access the backup ether via the interactive >>> console or >>> by trying to extract the data directly I get the follwing errors >>> in /var/log/messages >>> >>> root@hercules /var restore -i -f /dev/sa0 >>> tape read error: Input/output error >>> >>> Dec 20 15:49:22 hercules kernel: (sa0:aacp0:0:5:0): READ(06). CDB: 8 >>> 0 0 80 0 0 >>> Dec 20 15:49:22 hercules kernel: (sa0:aacp0:0:5:0): NO SENSE ILI >>> (length mismatch): 22528 csi:e0,40,0,20 asc:0,0 >>> Dec 20 15:49:22 hercules kernel: (sa0:aacp0:0:5:0): No additional >>> sense information >> > > This is very very strange, and I don't even know where to start > guessing. It could be either a fairly minor bug in the driver, or a > major bug/lack of support in the firmware. > >>> >>> Sometimes I often get some Timeouts (only using restore). >>> Dec 19 11:34:27 hercules kernel: aac0: COMMAND 0xc1fdf750 TIMEOUT >>> AFTER 51 SECONDS >> > > This is usually a sign that the firmware either lost a command, or > paniced all together. Both conditions are fatal =-( > > >>> >>> Kernel config: >>> ------------------------- >>> # SCSI peripherals >>> device scbus # SCSI bus (required for SCSI) >>> device ch # SCSI media changers >>> device da # Direct Access (disks) >>> device sa # Sequential Access (tape etc) >>> device cd # CD >>> device pass # Passthrough device (direct SCSI >>> access) >>> device ses # SCSI Environmental Services (and >>> SAF-TE) >>> # RAID controllers >>> device aac # Adaptec FSA RAID >>> device aacp # SCSI passthrough for aac (requires >>> CAM) >>> ------------------------- >>> >>> dmesg (cutted): >>> ------------------ >>> hercules kernel: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2399.33-MHz >>> 686-class CPU) >>> hercules kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> hercules kernel: cpu0 (BSP): APIC ID: 0 >>> hercules kernel: cpu1 (AP): APIC ID: 1 >>> hercules kernel: cpu2 (AP): APIC ID: 6 >>> hercules kernel: cpu3 (AP): APIC ID: 7 >>> >>> aac0: <Adaptec SCSI RAID 2120S> mem 0xd0000000-0xd3ffffff irq 52 at >>> device 2.0 on pci4 >>> aac0: [FAST] >>> aac0: Unknown processor 100MHz, 48MB cache memory, optional battery >>> not installed >>> aac0: Kernel 4.1-0, Build 7244, S/N bd10c2 >>> aac0: Supported >>> Options=11d7e<CLUSTERS,WCACHE,DATA64,HOSTTIME,RAID50,WINDOW4GB,SOFTERR,SGMAP64,ALARM,NONDASD> >>> >>> aacp0: <SCSI Passthrough Bus> on aac0 >>> >>> acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% >>> (probe5:aacp0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >>> (probe5:aacp0:0:5:0): NOT READY csi:e0,40,0,1c asc:4,1 >>> (probe5:aacp0:0:5:0): Logical unit is in process of becoming ready >>> sa0 at aacp0 bus 0 target 5 lun 0 >>> sa0: <QUANTUM DLT VS160 2500> Removable Sequential Access SCSI-2 device >>> sa0: 160.000MB/s transfers (80.000MHz, offset 96, 16bit) >>> ---------------------- >>> >>> Does anybody maybe have an idea why I can use dump but not restore ? >>> This doesn't make sense to me. >>> >>> And I should mention that "tar" works great! I can write and read >>> from the tape, even with filemarks. >>> >>> Thanks for your help! >>> Christian >>> > > I have a DLT drive here that I could probably hook up and start > debugging with, but there are a lot of other things on my plate with > higher priority, unfortunately. Your best bet for now is to put the > tape drive onto a real Symbios or Adaptec SCSI card. > > Scott > Thanks for your fast answer, Scott! What Adaptec Card can you recommend? I am thinking about this card, it seems to be supported quite well. * Adaptec 19160B Is this card a "real" SCSI card ? Actually I thought the 2120S is a "real" SCSI Card. And for the future, what kind of Adaptec RAID-5 card is useable where I can put several devices on it like a Raid-5 *and* a DLT device ? Christian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43A67FA9.5070308>