This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 44277 - (IDE)System lock up and corrupts hard drive while mounting CD
(IDE)System lock up and corrupts hard drive while mounting CD
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-12 08:31 EDT by Bob Colbert
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bob Colbert 2001-06-12 08:31:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

Description of problem:
Please refer to bug 38654 for possible related issue.  
After setting ide=nodma on the linux install.  A subsequent reboot and 
attempted mounting of a CD, the machine locks up.  During the subsequent 
reboot, fsck finds many errors like some number is 64 should be 8, inode 
this, inode that.  It eventually dumps me to a forced maintenance mode.  I 
then run fsck manually on /hda but that usually fails.  I then eventually 
have to run fsck on the hda6 partition.  After several more reboots it 
eventually comes back to life.  I am willing to live with the fact that 
the CDROM may not be the best quality and I could get a new one but it 
seems a little extreme that the simple attempt to mount a CD would corrupt 
the hard drive.

How reproducible:
Always

Steps to Reproduce:
1.See description
2.
3.
	

Expected Results:  the cd should have been mounted

Additional info:
Comment 1 Bernhard Rosenkraenzer 2001-06-24 05:44:06 EDT
Definitely not a mount issue, assigning to kernel
Comment 2 Arjan van de Ven 2001-06-25 02:44:37 EDT
If you need "ide=nodma" during install, you might also need it during normal 
use. I've seen a "bad" cdromdrive totally lock up the IDE bus, and as 
a result the kernel was unable to write back pending data to the harddisk.

What model cdrom-drive is this ?
(type "cat  /proc/ide/*/model" to get a list)
Comment 3 Bob Colbert 2001-07-02 08:26:57 EDT
output from /proc/ide/hdc/model

CD-R/RW RW7063A

I dont remember what brand it was that I bought but I dont think it was 
a 'name' brand.

I can accept that this isnt an 'authorized', supported model, but can you 
recommend the fastest CD burner that RedHat supports, or for instance which one 
that you use and have good results with?

Bob
Comment 4 none given 2001-09-16 10:12:31 EDT
I had a similar(?) problem using RedHat 7.1 and the following drive
configuration:
[
$ cat /proc/ide/*/model
IC35L060AVER07-0
CRD-8482B             (no problem CDROM drive)
IOMEGA ZIP 250 ATAPI  (no problem zip drive)
_NEC CD-RW NR-7800A   (problem CDRW drive; use can corrupt /dev/hda7 hard drive)
pci
pci
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda7              36G  2.3G   32G   7% /
/dev/hda2              15M  3.5M   10M  24% /boot
/dev/hda5              14G  939M   12G   7% /windata
/dev/hda1             4.9G  2.7G  2.1G  55% /winme
/dev/hdc4             239M  175M   63M  74% /mnt/zip0
/dev/hdb              638M  638M     0 100% /mnt/cdrom0
/dev/scd0             641M  642M     0 100% /mnt/cdrom1
]

I had the CRD-8482B CDROM and IOMEGA ZIP 250 ATAPI drive attached for about a
month with no problems. Then, I attached the NEC CDRW drive, restarted Linux and
noted that it had detected and mounted the drive as /dev/hdd. Dell told me this
was a very recent model CDRW drive. I planned to follow the HOWTO on simulating
a SCSI device modifying lilo.conf, etc. in order to permit use of the new drive
as a CDRW later; but for a few days kept using it as an ATAPI CDROM. Apparently,
over that period of about a week, use of the new drive under WindozeMe was
successful; both as a CDROM & CDRW. But, either as a result of those few
WindozeMe tests I ran, or as a result of daily use as an audio CD & a CDROM
under Linux, I began to accumulate some kind of file corruption problems.

The problems first manifested themselves to me when I started up Sawfish after
logging in. Although this problem did not happen the first time; after a while,
Sawfish always crashed. Eventually I had to run KDE or twm in order to use the X
gui. As root, I removed and replaced the Sawfish package several times; but each
time I'd restart (init 5), I'd get the file corruption problem again and usually
it stopped Sawfish. Removing the old package became increasingly difficult too,
as bizzare and "illegal" file permissions and sizes seemed to prevent many file
utilities (rm, ls, rmdir, mv, cp, gmc, [and kde's gui too]) from working.
Eventually, a restart one morning required a single user mode use of fsck to get
the system in some kind of semi-functional order. The command, "rpm -Va" would
show more and more packages being corrupted, which I kept replacing. Finally,
even the /bin/rpm command was corrupted. So, I saved all personal (some of the
files under /home) and ISP-connection configuration information from the "/"
drive to "/windata" and "/mnt/zip0" and reinstalled RedHat 7.1.

I should not that I was pleasantly surprised to note that after a fairly close
inspection of some 1300+ personal files on /home that none of them seems to have
been corrupted.

The re-installation detected my CDRW drive and set up the scsi emulation for me.
I don't know if that fixed the problem or hid it; but for over a week now I have
had no file corruption problems. Since I have the machine "up" over 12 hours a
day, 6 or 7 days a week and I am often moving and creating files while the "rpm
-Va" output was not showing any surprises, I felt all was well.

I am certain that files in /bin or /usr/bin or /sbin were not corrupted, until
after the first few days. When that did start to happen the corrupted commands
were not (as I understand) the sort a hacker usually tinkers with via a root
kit. Files like rpm and zcat were some of the corrupted files, and the type of
corruption usually just made them impossible to execute or sometimes even to
stat. This (to me) suggests I was not a victim of a hacking break in, though I
am connected to the network at least 8 of those 12 hours. Since I was a breakin
victim using RH 6.2 a few months ago I take many precautions to watch things,
running trafshow in a window I keep an eye on, etc. and never leave the keyboard
for even a few minutes without breaking the network connection. The tech support
staff at RedHat also helped rule out this cause as well as memory problems
(using memtest86). Anyway, in the near future (now that things are stable) I
plan to be setting up snort.

Please let me know if I can provide any other information that might be helpful.
Since the problem "went away" for me there is no urgency in obtaining a
solution; but I'd hate to have others go through what I went through.
Comment 5 Bugzilla owner 2004-09-30 11:39:02 EDT
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/

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