Red Hat Bugzilla – Bug 84591
3w-xxxx aic7xxx st - SCSI tape dysfunctional when RAID disk mounted from 3Ware 7500-4
Last modified: 2007-04-18 12:51:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Description of problem:
System is a PII-400 Asus P2B-S 440BX board with onboard aic7890 SCSI controller.
Single device on the bus is an HP C1537A DAT tape drive.
Primarily have successfully been using Arkeia (http://www.arkeia.com) for backup
on this combination for 2+ years.
Have installed 3Ware 7500-4 IDE RAID controller. Tape works fine with 3w-xxxx
However - upon mounting one of the RAID volumes (eg /dev/sda), Arkeia claims it
is unable to open /dev/st0. Target Settings in /proc/scsi/aic7xxx indicate
Commands are Queueing & not being executed.
Some 'mt' commands return "I/O" error, such as fsf, eom, etc. Others such as
rewoffl, erase, work. Meanwhile 'tar cf /dev/st0 <some-dir>' works correctly.
Unloading & reloading the aic7xxx module makes no difference. Have tried
disabling tagged command queuing to the drive.
The order in which 3w-xxxx and aic7xxx are loaded makes no difference.
Have tried different DAT tapes and tape types.
Haven't tested unmounting the IDE RAID volume as this is now my boot/root disk.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. load modules aic7xxx & 3w-xxxx & st
2. mount /dev/sda as presented by 3ware IDE RAID
3. attempt backup with arkeia, alternatively attempt some normal 'mt' operations
Actual Results: Arkeia claims it is unable to open /dev/st0; 'mt' fails with
Expected Results: Arkeia opens & writes normally to tape; 'mt' opens tape
device & performs normal operations successfully
3ware Storage Controller device driver for Linux v1.02.00.025.
PCI: Found IRQ 12 for device 00:09.0
PCI: Sharing IRQ 12 with 00:04.2
PCI: Sharing IRQ 12 with 00:06.0
3w-xxxx: PCI Parity Error: clearing.
scsi0 : Found a 3ware Storage Controller at 0xa800, IRQ: 12, P-chip: 1.3
scsi0 : 3ware Storage Controller
Vendor: 3ware Model: 3w-xxxx Rev: 1.0
Type: Direct-Access ANSI SCSI revision: 00
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 156299440 512-byte hdwr sectors (80025 MB)
sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
PCI: Enabling device 00:06.0 (0016 -> 0017)
PCI: Found IRQ 12 for device 00:06.0
PCI: Sharing IRQ 12 with 00:04.2
PCI: Sharing IRQ 12 with 00:09.0
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec aic7890/91 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
blk: queue dba95614, I/O limit 4095Mb (mask 0xffffffff)
Vendor: HP Model: C1537A Rev: L708
Type: Sequential-Access ANSI SCSI revision: 02
blk: queue c0a91814, I/O limit 4095Mb (mask 0xffffffff)
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi1, channel 0, id 5, lun 0
(scsi1:A:5): 10.000MB/s transfers (10.000MHz, offset 32)
st0: Block limits 1 - 16777215 bytes.
[root@cabrio boot]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
NB. Same behaviour noted on RH7.1 kernel 2.4.18-24.7.x - the machine was at
this revision when the 3ware card arrived.
I don't know why, but there are lot of problems with backups in linux.
take a look : http://www.linuxtapecert.org
makisara has put the solution for the EOF bug at:
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/