Red Hat Bugzilla – Bug 18594
Hard System lockup...
Last modified: 2007-04-18 12:29:04 EDT
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 hardware.. 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
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)...
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 ...
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 ?
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.
assigning to kernel
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 it).