Bug 45164 - DDS3 tape backup fails on RH 7.1 with U160 adapter
Summary: DDS3 tape backup fails on RH 7.1 with U160 adapter
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Ben Levenson
URL:
Whiteboard:
: 51357 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-20 17:37 UTC by Wendy Hung
Modified: 2007-04-18 16:33 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-09-04 16:51:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Wendy Hung 2001-06-20 17:37:13 UTC
Description of Problem:
Executing  "tar cvf /dev/st0 /backup" results in no response from DDS3 tape.

Steps to Reproduce:
1.  Install RH 7.1 on IBM xSeries 300 to onboard U160 adapter
2.  DDS3 tape connected to second U160 adapter in rear of box
3.  Run tar cvf /dev/st0 /backup

Actual Results:
No response from tape.

Expected Results:
Backup should have been successful.

Additional Information:
When using the 2940UW SCSI adapter for the DDS3 tape drive instead of the U160 SCSI adapter, no problem.
Red Hat 7.0 works fine.
There are no problems when other tape drives are used: DDS4, TR5(SCSI), TR5(IDE) or HH-LTO.

Comment 1 Bernhard Rosenkraenzer 2001-06-25 11:50:37 UTC
Looks like a driver issue.


Comment 2 Wendy Hung 2001-07-13 19:45:28 UTC
Also unable to backup data to DLT tape drives with U160 SCSI adapter on RedHat7.1J. 
Results with running TAR backup command with DLT tapes: 
DLT4000: No response.
DLT8000: An error message of "0 byte was written out of 10240 bytes.  An error was not recovered."


Comment 3 Yil-Kyu Kang 2001-07-18 14:36:41 UTC
I also experienced the same problem when using a DDS3 tape drive with an Adaptec
U160 adapter. However, the DDS3 tape backup functions properly with other
adapters...just confirmed that it works properly with the LSI Logic 53c896.

Comment 4 Michael K. Johnson 2001-08-17 15:14:38 UTC
Doug, please investigate this

Comment 5 Doug Ledford 2001-08-21 17:44:20 UTC
I need complete logs of the SCSI startup messages on the failing box.  I need
the Adaptec driver messages, the tape identity messages, and the messages from
the startup of the st driver.  I also need you to load the aic7xxx driver in
verbose mode so we might be able to get a better clue about what's going on (I
assume there is a bus reset in there somewhere as the drive and controller try
to talk to each other).  If there is a bus activity LED, then knowing what that
LED is doing when the tar command is running would also be very helpful (is it
on solid, does it only blink occasionally, what details can you provide).  Also,
try going into the aic7xxx cards' BIOS and setting the device parameters for the
DDS3 tape drive to a maximum transfer speed of 80MB/s and see if it works any
better (if not, then try 40MB/s and see if that helps).  Let me know how it all
comes out...

Comment 6 Glen Foster 2001-08-23 21:49:23 UTC
We (Red Hat) really need to fix this before next release.

Comment 7 Doug Ledford 2001-08-23 23:03:04 UTC
*** Bug 51357 has been marked as a duplicate of this bug. ***

Comment 8 Wendy Hung 2001-08-28 19:57:54 UTC
Works fine with Fairfax RC1.

After installing RC1 on IBM xSeries 300 (BIOS level 17), U160 card was 
installed and autodetected and configured by Kudzu as an Adaptec/7892A. 
tar command was run successfully.
 
Will the fix for RH 7.1 be to upgrade to the Fairfax kernel?



Comment 9 Wendy Hung 2001-08-28 20:28:40 UTC
The x300 was tested with the DDS3 tape and the DLT 7000 tape -- both worked 
fine with RC1.

Comment 10 Doug Ledford 2001-08-29 14:40:28 UTC
I don't know the answer to that question.  Michael?

Comment 11 Michael K. Johnson 2001-09-04 16:51:32 UTC
The fix for Red Hat Linux 7.1 will be to upgrade to an errata kernel
closely related to the fairfax kernel, once we release the errata
kernel.

Comment 12 Wendy Hung 2001-11-02 21:06:02 UTC
Fixed in RH 7.1 kernel errata (2.4.9-6).


Note You need to log in before you can comment on or make changes to this bug.