DLT Tape Read errors on aac0

Mon Dec 19 01:38:59 PST 2005

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 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
>
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"