Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 81536

Summary: LTO tape device can't work properly, with some errors.
Product: Red Hat Enterprise Linux 2.1 Reporter: Shinya Narahara <naraha_s>
Component: kernelAssignee: Larry Woodman <lwoodman>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:25:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Shinya Narahara 2003-01-10 04:38:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [ja] (WinNT; U)

Description of problem:
Even the command "cat /dev/st0" fails with LTO
tape device. "dd if=/dev/st0" also fails, tar too.
Both reading/Writing from/to LTO tape can't finish
properly. Sometime it works fine, but big data(ex.30GB)
offten causes this error. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.set LTO tape device and tape into it. /dev/st0

Actual Results:  Error exit with error message:

(scsi1:A:4:0): Unexpected busfree in Data-in phase
SEQADDR == 0x8b
scsi1:0:4:0: Attempting to queue a TARGET RESET message
scsi1:0:4:0: Command not found
aic7xxx_dev_reset returns 0x2002
scsi: device set offline - command error recover failed: host 1 channel 0 id 4 lun 0

Expected Results:  can read/write normally.

Additional info:

LTO tape device is:
  Vendor: HP        Model: Ultrium 1-SCSI    Rev: E15G
  Type:   Sequential-Access                  ANSI SCSI revision: 03
(scsi1:A:4): 20.000MB/s transfers (10.000MHz, offset 15, 16bit)

We know the problems of aic789x(,
but this issue is reproduced on aic7880(aic7xxx.o) and

ncr53c825-0-<4,0>: phase change 2-6 6@37198488 resid=5.
ncr53c825-0:4: ERROR (0:4) (8-0-0) (8/1b) @ (script 380:860b0000).
ncr53c825-0: script cmd = 78340800
ncr53c825-0: regdump: da 00 80 1b 47 08 04 0f 75 08 84 00 80 00 0e 02.
ncr53c825-0: have to clear fifos.
ncr53c825-0: unexpected disconnect
ncr53c825-0: SCSI parity error detected: SCR1=138 DBC=860b0000 SSTAT1=e
ncr53c825-0-<4,0>: COMMAND FAILED (8a ff) @f7198000.
st0: Error 2707007f (sugg. bt 0x20, driver bt 0x27, host bt 0x7).
st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sns = 70  5
ASC=20 ASCQ= 0
Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0e 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 
st0: Error on write filemark.

This issue is also reproduced on kernel-2.4.18-18.8.0,

Interestingly, this is reproduced only on LTO tape
device, not on DAT/DLT device. we change SCSI Transfer
speed from 5MB/s to 10MB/s or Wide/Narrow, but this
doesn't go away...

We guess this is not problem of scsi device drivers,
but scsi tape driver(st.o).

Comment 1 Shinya Narahara 2003-01-17 01:59:30 UTC
I've confirmed that Red Hat Advanced Server 2.1 has also this issue.
Could anyone please give me any suggestions?

Comment 2 acount closed by user 2003-03-22 05:43:12 UTC
makisara has put the solution for the EOF bug at:

Comment 3 Shinya Narahara 2003-04-10 03:11:31 UTC
Thank you for your information,
unfortunately the patch you pointed has no effects for this issue...
We'll try the another "older" patch:
Does anyone try this on the kernel-2.4.9-34?

Comment 4 Alan Cox 2003-06-08 19:46:25 UTC
Since AS is affected transferring over to AS so the bug lives the full lifetime
of AS

Comment 5 RHEL Product and Program Management 2007-10-19 19:25:35 UTC
This bug is filed against RHEL2.1, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products.  Since
this bug does not meet that criteria, it is now being closed.

For more information of the RHEL errata support policy, please visit:

If you feel this bug is indeed mission critical, please contact your
support representative.  You may be asked to provide detailed
information on how this bug is affecting you.