On Sat, 5 May 2001, Rogier Wolff wrote:
> Andre Hedrick wrote:
> > On 5 May 2001, Adam Gregoire wrote:
> >
> > > I have tested this kernel last night about an hour after release and the
> > > board locked hard during hdparm tuning on boot. No SysRq, no oopsie.
> > >
> > > Options I used where:
> > >
> > > /sbin/hdparm -d 1 -u 1 -a 16 -c 1 -k 1 -K 1 -m 16 -X 68 -W 1 /dev/hde
> > >
> >
> > DO NOT DO STUPID THINGS LIKE THIS!!!!!!!!!!!!!!!!
> >
> > Let the driver work or turn the driver off!
>
> OK, Andre,
>
> you're being a bit terse today. What you're saying is that we
> shouldn't need any "hdparm": The driver should figure out the best
> configuration all by itself?
Rogier,
First start with everything about storage is a LIE, a big fat WHOPPER.
> So, can you think of something that may have gone wrong in the above
> case?
Sure, but I need to know more about the system.
The point is that if the driver does not set something up, then you may
wish to do some minor tuning.
> Is there anything wrong with turning on DMA? (I think not: DMA should
> already be on.)
No.
> Is there anything wrong with turning on interrupts while doing PIO
> data-transfers? (I think not: we should be doing DMA!)
Yes in some cases where legacy systems fail to address the issues of
arbitration (specifcially, the pci-bridging is broken by Intel by design)
Not until I restrict the interrupt masks to only be set for key locations
will it be testable and safe, (in my strong opinion).
> Is there anything wrong with setting the fs readahead to 16? (That
> should work, no matter what the drive, right?)
Yes
> Is there anything wrong with turning on 32bit access mode? (Any
> modern drive should do this, right?)
No, this command sets was obsolete or retired.
"32bit access" died with the introduction of MultiMode.
READ/WRITE-LONG == MultiMode set to a value of 2.
> Is there anything wrong with setting the "k" flags? (If it works now,
> it keeps on working, but indeed, if it doesn't work, a reset may
> be unable to fix it...)
>
> Is there anything wrong with a multcount of 16?
No, but you can set a compile option to auto-set to max.
> Hmm. The -X option is documented as dangerous. What's dangerous about
> it?
Before the chipset tuning code, you would force things into a mistimed
mode.
> Hmm. The -W option is documented as dangerous. What's dangerous about
> it? I'd think that a write cache in the drive is just as bad as having
> write caching in the OS. So what's the difference?
Not all drive did it correctly, and only the very lastest code I have (to
publish) tests for support and will auto-on and flush drive to platters.
Cheers Rogier,
Andre Hedrick
Linux ATA Development
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
