Re: Unusual filesystem/memory corruption
Quoting John Toon on Sun, Aug 12, 2001 at 12:04:20AM +0100:
> On 11 Aug 2001 16:37:58 -0500, Mike Brownlow wrote:
>
> > * hdparm options: -m16 -d1
> > * Machine is behind firewall, and has few services for external
> > access
> >
> > I suspect hardware failure caused it, but there are still a few software
> > unknowns. I'm starting to lean on corruption due to using -m16 for
> > hdparm. Any other suggestions appreciated...
>
> Ouch. Sounds bad.
>
> In general, you should _not_ use hdparm, for the simple reason that if
> you build a custom kernel with all the necessary options, it will
> default to optimum performance anyway (you can set "Use DMA by default"
> under the block device options).
>
> I'm running a 2.4.5 XFS patched custom kernel that I built, and DMA/32
> bit disc access etc. is fully operational by default since I selected
> the appropriate kernel options. With modern kernels, hdparm is totally
> unnecessary and potentially dangerous (except for performing performance
> tests on your drive of course!).
>
> What chipset does your mainboard use?
>
> John.
>
Hi-
I had a similar thing occur on a system running a VIA/southbridge
chipset on 2.2.18. this a K7T style motherboard with a KT133 chipset.
I had been using it with a Western Digital 6g drive and the system was
so corrupt and unusable it could not find mounted file systems, the
/etc/fstab file corrupt, and on... I was also using hdparm.
I re-installed and went to a 2.4.5 kernel with the via/southbridge ide
driver. The system now runs happily with twin maxtor 40g ide drives on
the 2.4.7 kernel with the via ide driver compiled in.
--
Michael Perry | "Do or do not; there is no try" Master Yoda
mperry@lnxpowered.org | http://www.lnxpowered.org
Reply to: