Bug 18594 - Hard System lockup...
Summary: Hard System lockup...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-07 08:58 UTC by Ryan Dietrich
Modified: 2007-04-18 16:29 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-15 02:16:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ryan Dietrich 2000-10-07 08:58:52 UTC
Standard install RH 7.0 ...

Any time I have multiple accesses to my vfat partitions, my system locks
up, and then loses the hard drive (even in bios), until I completely power
cycle.  This sucks.. Funny thing is, it seems to happen even if I'm trying
NOT to do multiple things to a vfat partition..

It's not just me either (seriously), but I would blame my bleeding edge
ata66 hd, via 133a chipset motherboard.  My kernel won't compile, (keeps
complaining about smp_cpu being redefined).  

Ok, to make things even worse, I work at the Soma office, so I probably
should know better, but this one is getting a bit 'out there' ...  

I did set my hard drive parameters to '-c3d1' .. With this off, the system
was almost unbearably slow.. 

Thanks for your help ...

-Ryan Dietrich

Comment 1 Ryan Dietrich 2000-10-08 04:37:33 UTC
Went as far as remounting with "read only" ... Everytime disk io is done on an
ext2 partition and my vfat partition, my system locks up and will not recognize
the hard disk until a full power cycle is performed.

I'd recompile my kernel, but it continues to error out.  I'm thinking of getting
gutsy and installing the 2.4 kernel (maybe I'll have better luck with it).  I
have went ahead and removed my vfat mount points completely now, (tired of
rebooting).  I haven't had any problems so far.. (I'll update if this behaivor
continues even without vfat partitions mounted)...

Comment 2 Ryan Dietrich 2000-10-09 02:12:19 UTC
I have now went as far as removing my vfat mount points entirely, and thought my
problems were over for now.  Not so.  While playing an mp3 off of an ext2
filesystem, and using vmware (virtual disk within an ext2 partition), my system
after a half hour of use decided to lock up hard, exactly as before, and
required a full power cycle to return my hard disk to normal status.

Maybe it's because I'm using dma mode, but without it, my system is unbearably
slow.  Current hdparm configuration is -c3d1 ...

Comment 3 Alan Cox 2000-10-09 23:43:38 UTC
If you play with hdparm you must tune both the drive and controller and in some
cases simply using hdparm may not be correct. Also we don't really take much
notice of bugs reported on kernels with vmware added, vmware is a large piece of
code that can do what it likes to kernel internals. Does it occur from a boot in
which vmware is never loaded ?

Comment 4 Ryan Dietrich 2000-10-10 00:01:39 UTC
Yes, if I mount either of my fat32 partitions and perform read operations or
anything slightly more complex (such as installing an rpm from fat32) .. It will
lock up very little use.  I only threw the vmware example to show that it wasn't
something to do with my vfat partitions.

It does seem stable as long as I 

1. Don't mount any vfat partitions... 
2. Don't mount any vmware partitions from userland. (via vmware-mount.pl)
3. Don't start VMware.
4. Don't play an mp3 residing on an ext2 partition while doing anything IO
intensive on other ext2 partitions.

... I know of hdparm, but I know of no way to 'tune my controller'.. I'll be
compiling 2.4 test9 to see if that makes much of a difference. 

Thank you for your time sir.

Comment 5 Bill Nottingham 2000-10-16 16:53:08 UTC
assigning to kernel

Comment 6 Perry Harrington 2000-12-07 09:19:17 UTC
I have found that using hdparm to enable dma is extremely dangerous as it
doesn't program the controller.  The proper way to do this is to use idex=dma on
the kernel command line.  You specify the ide controller number in the above
line.  On my home machine I have this set in my lilo.conf:

append="ide0=dma ide1=dma"

What this does is tell the kernel to enable DMA if the bios hasn't explicitly
disabled it.  You will see 'UDMA' after the hdx device listings in the dmesg or
boot logs.

If the kernel says something like 'disabling dma for some reason or another'
then you have a chip that isn't fully compatible.  IBM laptops with Acer BX
chipsets are such devices (unfortunately I have one and only get 3MB/s out of

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