Bug 75996
Summary: | (IDE TAPE)ide tape drive use locks up system on Redhat 8.0 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Mike Norwood <mikejunk> | ||||
Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 8.0 | CC: | alan, mgb, p.van.egdom | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-09-30 15:40:04 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Mike Norwood
2002-10-15 17:06:45 UTC
this is supposed to be fixed in the yesterday released erratum kernel I downloaded and installed new kernel and system still completely locks up after accessing ide tape drive. No, we did not have a fix for any hangs in RH8.0. Perhaps 8.0 initscrips forgot to switch DMA off. The tape drive does function if I turn off DMA with hdparm -d0 /dev/hdd. I can then backup and restore without lockup. Created attachment 83004 [details]
Relevant piece lost between 7.3 and 8.0
Customer writes in e-mail "It also works if I copy /etc/sysconfig/harddisks to /etc/sysconfig/harddiskhdd and edit harddiskhdd to show DMA=0." I am not sure it was designed this way, it should check if the media is a disk... Let us hear Bill Nottingham's expert opinion. The code that disabled DMA on non-disk devices was removed; this was due to input from the kernel team that using hdparm was the wrong way to do it and it should be handled in the kernel. A similar story : My computer with an IDE-tape streamer also triggered this bug. Backing up some files in "/usr/bin" gave : [root@vectra bin]# tar cvf /dev/ht0 . ./ ./consolehelper ./catchsegv ide-tape: ht0: I/O error, pc = a, key = 7, asc = 27, ascq = 0 tar: /dev/ht0: Wrote only 0 of 10240 bytes tar: Error is not recoverable: exiting now Here's some info : [root@vectra /]# ide_info /dev/hdd MODEL="HP COLORADO 14GB" FW_REV="4.010000" SERIAL_NO="MX00984149" What did the trick for me was typing in "hdparm -d 0 /dev/hdd". This is not an initscripts issue; at least, I was told this should be properly done in the kernel. This problem is still present in Red Hat Linux release 8.0.92 (Phoebe). I did a fresh install. All ISO's have been 100% MD5'ed by Anaconda. I have been able to trigger this problem by doing : a) "modprobe ide_tape" b) "ide_info /dev/hdc" c) "ide_info /dev/hdd" and repeating step b) and c), and doing a "tar xvf /dev/ht0" quickly results in : <snip> Unable to handle kernel NULL pointer dereference at virtual address 000000b8 printing eip: c5248cad *pde = 00000000 Oops: 0000 ide-cd cdrom ide-tape autofs 3c59x iptable_filter ip_tables loop keybdev mousedev hid input usb-uhci usbcore ext3 jbd lvm-mod CPU: 0 EIP: 0060:[<c5248cad>] Not tainted EFLAGS: 00010202 EIP is at idetape_exit [ide-tape] 0x2d (2.4.20-2.2) eax: 00000000 ebx: 00000000 ecx: 00000014 edx: 00000025 esi: 00000014 edi: 00000000 ebp: bfffeb28 esp: c5435f84 ds: 0068 es: 0068 ss: 0068 <snip> I'll be happy to provide more specific info if needed. The oops is not "the" problem, it's entirely different from inability to handle DMA. Also, it's supposedly fixed in 2.4.21-pre3. This problem is still present in Red Hat Linux release 8.0.93 (Phoebe). Here's some output from the command "dmesg" with Phoebe 8.0.93 after doing the following commands : - "modprobe ide-tape" - "tar tvf /dev/ht0". <snip> ide-tape: hdd <-> ht0: HP COLORADO 14GB rev 4.01 ide-tape: hdd: overriding capabilities->speed (assuming 650KB/sec) ide-tape: hdd: overriding capabilities->max_speed (assuming 650KB/sec) ide-tape: hdd <-> ht0: 650KBps, 13*32kB buffer, 6336kB pipeline, 100ms tDSC, DMA ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = 4 ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = 4 ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = 4 <snip> Disabling DMA (with "hdparm -d 0 /dev/hdd") after this has occured does not help. After rebooting and disabling DMA on /dev/hdd _before_ executing these 2 commands _does_ let these commands work properly. Installed a fresh Phoebe 8.0.94 on my HP Vectra computer with Colorado IDE tape streamer. Using "ide_info" on the device of the IDE tape streamer results in : [root@vectra root]# ide_info /dev/hdd MODEL="PHC LORODA O41BG" FW_REV=".4100000" SERIAL_NO="XM00891494" Notice that the output of this command on Phoebe 8.0.94 is very different than the output of this command on Red Hat 8.0. Unfortunately restoring files with "tar xvf /dev/ht0" still doesn't work. Here's some output of "dmesg" : ide-tape: hdd <-> ht0: HP COLORADO 14GB rev 4.01 ide-tape: hdd: overriding capabilities->speed (assuming 650KB/sec) ide-tape: hdd: overriding capabilities->max_speed (assuming 650KB/sec) ide-tape: hdd <-> ht0: 650KBps, 13*32kB buffer, 6336kB pipeline, 100ms tDSC, DMA ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c Installed a fresh release of Red Hat Linux 9 (Shrike) on my HP Vectra computer with Colorado IDE tape-streamer. Unfortunately, the IDE tape-streamer still doesn't work out of the box on Red Hat Linux 9: the same problems described in Comment #13 occur. Also, upgrading to "kernel-2.4.20-1.1976" (which is based on 2.4.21-pre7-ac1) did not help. Here's some output of "dmesg" after "modprobe ide-tape" and "tar tvf /dev/ht0": ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c However, turning off DMA with "hdparm -d0 /dev/hdd" after a reboot fixes described problems with accessing the tape-streamer; the commands "modprobe ide-tape" and "tar tvf /dev/ht0" work as advertised. Installed a fresh release of Red Hat Linux release 9.0.93 (Severn) on my HP Vectra computer with Colorado IDE tape-streamer. Alas, the IDE tape-streamer still doesn't work out of the box. This time with a couple of differences. After booting Red Hat Linux release 9.0.93 (Severn), the following is seen in the kernel ring buffer (and with the command "dmesg") : <snip> hdd: attached ide-tape driver. ide-tape: hdd <-> ht0: HP COLORADO 14GB rev 4.01 ide-tape: hdd: overriding capabilities->speed (assuming 650KB/sec) ide-tape: hdd: overriding capabilities->max_speed (assuming 650KB/sec) ide-tape: hdd <-> ht0: 650KBps, 13*32kB buffer, 6336kB pipeline, 100ms tDSC, DMA <snip> After inserting a tape and doing "tar xvf /dev/ht0" results in : <snip> ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c ide-tape: ht0: I/O error, pc = 8, key = 9, asc = 3, ascq = c <snip> Okay, let me try "hdparm -d0 /dev/hdd" before doing this, I thought. So I rebooted, but ... the problem re-appeared. It turned out that I had to disable 'smartd - SMART Disk Monitoring Daemon' to prevent initialisation of the IDE tape-drive. So I did "chkconfig --level 35 smartd off" and rebooted the machine. After rebooting (the IDE tape-drive was not probed this time), I tried "hdparm -d0 /dev/hdd" again. Here's a piece of "dmesg" : <snip> ide-floppy driver 0.99.newide hdd: attached ide-tape driver. ide-tape: hdd <-> ht0: HP COLORADO 14GB rev 4.01 ide-tape: hdd: overriding capabilities->speed (assuming 650KB/sec) ide-tape: hdd: overriding capabilities->max_speed (assuming 650KB/sec) ide-tape: hdd <-> ht0: 650KBps, 13*32kB buffer, 6336kB pipeline, 100ms tDSC, DMA hdd: DMA disabled <snip> Strangely, the command "ide_info /dev/hdd" results in : MODEL="" FW_REV="" SERIAL_NO="" Then I tried using the tape streamer again with "tar xvf /dev/ht0". This time it worked 100%. 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 persists. 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/ |