Bug 61950 - mt-st problems when upgrading to 7.2
mt-st problems when upgrading to 7.2
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-26 00:52 EST by Tom Tilmant
Modified: 2007-04-18 12:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-16 20:11:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hwconf files (2.59 KB, text/plain)
2002-03-31 22:43 EST, Tom Tilmant
no flags Details
dmesg file (7.96 KB, text/plain)
2002-03-31 22:44 EST, Tom Tilmant
no flags Details
This is a copy of the cdrecord-scanbus report (2.14 KB, text/plain)
2002-04-05 02:46 EST, Tom Tilmant
no flags Details

  None (edit)
Description Tom Tilmant 2002-03-26 00:52:57 EST
When I upgraded from 7.0 to 7.2, My DLT tape drive stopped working.  Looking 
over past bug reports, it was suggested to install mt-st-0.6-1 which comes 
standard on 7.2.  I have install mt-st-0.7-3 thinking maybe that would help, 
did not fix the issue.  Hwconf file show the device as "st", not "st0"

Hardware Installed:
(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 0/14/0
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
       <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
  Vendor: QUANTUM   Model: ATLAS10K2-TY367L  Rev: DDD6
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: QUANTUM   Model: DLT8000           Rev: 022C
  Type:   Sequential-Access                  ANSI SCSI revision: 02
  Vendor: QUANTUM   Model: ATLAS10K2-TY367L  Rev: DDD6
  Type:   Direct-Access                      ANSI SCSI revision: 03

I downgraded my system back to 7.0 and the drive works.  The hwconf file shows 
the device as "st0".  Upgraded and also tried a clean install to 7.2 and both 
showed "st" as the device in hwconf.

SCSI tape drive selection in the hwconf:
-
class: TAPE
bus: SCSI
detached: 0
device: st
driver: ignore
desc: "Quantum DLT8000"
host: 0
id: 5
channel: 0
lun: 0
-
Comment 1 Ngo Than 2002-03-31 04:42:53 EST
Could you please give me a testcase for this problem. I cannot reproduce it here. 
 
i tested with mt -f /dev/st0 status ... it works
Comment 2 Tom Tilmant 2002-03-31 22:40:17 EST
Testcase:  You do a clean install of RD7.0 with RAID 0 on a Intel 1100 
system.  I will attach my hardware configuration.  tar -cvf /dev/st0 / and the 
system backups to the DLT drive (no problems).   Do a clean install of RD7.2 
and then run "tar -cvf /dev/st0 /" and you get this error.  

[root@ns root]# tar -cvf /dev/st0 / 
tar: Removing leading `/' from member names

lost+found/
boot/
boot/lost+found/
boot/grub/
boot/grub/grub.conf
boot/grub/splash.xpm.gz
tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

I will also include my hwconf file which shows st0 verus st.

When I run the mt -f /dev/st0 status, I get the following:

[root@ns root]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 7627624 bytes. Density code 0x43 (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Hope thos gives you enough info.

Tom
Comment 3 Tom Tilmant 2002-03-31 22:43:39 EST
Created attachment 51584 [details]
hwconf files
Comment 4 Tom Tilmant 2002-03-31 22:44:56 EST
Created attachment 51585 [details]
dmesg file
Comment 5 Ngo Than 2002-04-02 05:28:37 EST
please try to update tar-1.13.25 in rawhide, if it's fixed.
Comment 6 Tom Tilmant 2002-04-03 03:23:37 EST
I upgraded, but still can not run tar.   Same complaints.  

I installed arkeia backup software to see if that would help.  Seems that it 
does not find a tape drive at all.  It appears that the kernel does not see 
the tape drive on st0, only on st as the hwconf claims.
Comment 7 Tom Tilmant 2002-04-05 02:46:54 EST
Created attachment 52308 [details]
This is a copy of the cdrecord-scanbus report
Comment 8 Tom Tilmant 2002-04-05 02:49:51 EST
I have just attached a cdrecord -scanbus report.  The Tape drive is on ID5 and 
as you can see, it is label different each time I run the command.  I have 
also update the BIOS on the Adaptec card to 3.10. and tried rebuilding the 
driver, Still not working.
Comment 9 Bernhard Rosenkraenzer 2002-04-05 04:06:07 EST
Looks like a driver problem.
Comment 10 Tom Tilmant 2002-04-08 18:09:31 EDT
I have done some more tests to confirm the problem to be with the 2.4 kernel.  
All tests done on same server (Intel 1100) with the same SCSI card (Adaptec 
29160 v3.10).. 

Test 1:
I stalled RD 7.0 clean and tried tape drive (work)

Test 2:  
Installed RD 7.1 clean and tried tape (does not work)

Test 3: 
I stalled RD 7.0 clean and upgrade to 7.1 and tried tape (does not work)

Test 4:
I stalled RD 7.0 clean and upgrade to 7.2 and tried tape (does not work)

Test 5:
I stalled RD 7.0 clean and upgraded mt and tar to version on 7.2 CD (work)

Test 6: 
I stalled RD 7.0 clean and upgraded mt and tar to version on 7.2 CD, and then 
upgrade to 7.2 (does not work)

Test 7:
Installed RD 7.2 Enterprise clean and tried tape (does not work)

I can not believe that I am the only person with this problem.  Please help, 
since I really need to perform a backup.

Tom
Comment 11 Arjan van de Ven 2002-04-09 04:58:23 EDT
Ok this may sound strange but can you try the SMP kernel ?
Some intel bioses have bugs that hit UP kernels only (SMP kernels use a
different bios table for certain things)
Comment 12 Tom Tilmant 2002-04-10 02:13:05 EDT
Tried your suggestion, no go.  I have the same results, hwconf is still 
showing the device at st and not st0 and when I run tar, I get the following:

[root@ns root]# tar -cvf /dev/st0 /etc
tar: Removing leading `/' from member names
etc/
etc/sysconfig/
etc/sysconfig/network-scripts/
etc/sysconfig/network-scripts/ifup-aliases
tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now
Comment 13 Arjan van de Ven 2002-04-11 03:19:04 EDT
Doug: any ideas ?
Comment 14 Doug Ledford 2002-04-11 11:12:07 EDT
Try the aic7xxx_mod driver, it should work.  I've heard, but I don't have the
hardware to reproduce, that certain tape drives and the aic7xxx (old) driver
have an error reporting problem that causes a false error to get returned to the
upper layers and stops the tape drive from working.
Comment 15 Tom Tilmant 2002-04-11 16:22:24 EDT
OK, I will try.  Now is the aic7xxx_mod driver the one shipped in the rpm?  If 
not, were can I get it? Is the "aic7xxx (old) driver" also included in the 
rpm?  If yes, how can I remove the "aic7xxx (old) driver" driver with out 
recompiling the kernel, or do I have to recompile and what options should I be 
looking at?  Just for information, which driver was in 7.0?
Comment 16 Arjan van de Ven 2002-04-11 16:29:16 EDT
Both drivers are included as module:
aic7xxx.o      the "old" driver (same basic driver as in 7.0)
aic7xxx_mod.o  the "new" driver written by Adaptec

to switch:
1) edit /etc/modules.conf to change the driver name
2) recreate the initrd:
mkinitrd -f /boot/initrd-2.4.7-10.img 2.4.7-10

(assuming the 2.4.7-10 up kernel, replace -10 with -10smp for the smp kernel)
Comment 17 Tom Tilmant 2002-04-11 23:36:33 EDT
IT WORKS!!!  

Once I had installed the new driver as suggested, the problem was gone.  It 
still shows st in the hwconf file, which is different then 7.0, but it 
works. :-)  

Can we have the aic7xxx_mod be the default install for the rpm in the future?

Thanks Again Guys.
Comment 18 Tom Tilmant 2002-04-15 13:10:39 EDT
OK, I jumped the gun.

I ran into a little problem with the instruction you gave me.  It worked as 
described, but the next day, the system would not boot.  I reformatted and 
followed the directions again, still could not get the system to boot.  I 
found instructions (below) on the web and tried it and it worked.  But, now 
the system sees the tape drive and can backup and restore little amounts of 
data (such as the /etc directory), but errors on restoring large amount of 
data (such as full system backups) with the following "Can not find 
INPUT/OUTPUT device". Does the tar command have problems with ext3?  I also 
notice that Adaptec has a 6.2.4 version (dated 12-18-2001) of there driver and 
that the driver version on RH7.2 Kernel 2.4.9-31 is 6.2.1.  Since I am not an 
expert on installing patches, how can I update the aic7xxx_mod without 
recompliing?

----------------------------

work around on the issue that linux boots up and lock up at aic78xx......

After loading aic7xxx_mod driver and the system fails upon reboot because it

was loading both the aic7xxx_mod and the regular aic7xxx driver.

 

So the complete procedure is:

at the boot prompt type "expert noprobe"

Select "No" driver Disk

after pass the language, etc

choose "add device" to list device drivers

select "ScSI"

select "new experimental .... aic7xxx_mod"

then aic7xxx_mod will be loaded, instead of the regular aic7xxx

complete the installation

*To prevent loading two drivers*

After completing the installation, reboot with the installation CD in the CD-
rom.

At the boot prompt, type "linux rescue noprobe"

choose "add device" to list device drivers

select "new experimental.... aic7xxx_mod" and it will load the driver

choose "done" and choose "US" and "english"

Then anaconda will start to load

Answer "ok" and it will bring up the shell

Type the following command and enter at the end of the line

chroot /mnt/sysimage

cd /etc

vi modules.conf

*delete the command that loads the regular driver*

move the cursor to the beginning of the 1st line:

alias SCSI_hostadapter1 AIC 7xxx

and press dd to delete this line

move the cursor to the beginning of the 2nd line:

alias SCSI_hostadapter2 AIC 7xxx

and press dd to delete this line

Then

press :wq

Then on the commend line type

cd /boot

/sbin/mkinitrd -f initrd-2.4.2-2.img 2.4.2-2

notes: if using dual cpu, please add smp after the "2" as follow:

/sbin/mkinitrd -f initrd-2.4.2-2smp.img 2.4.2-2smp

next

type

sync

Then you can hardware reboot and the proper driver will be loaded.

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