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).