DLT Tape Read errors on aac0

Scott Long scottl at samsco.org
Sun Dec 18 11:24:55 PST 2005


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 at 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 at 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 at 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



More information about the freebsd-stable mailing list