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?
So, can you think of something that may have gone wrong in the above
case?
Is there anything wrong with turning on DMA? (I think not: DMA should
already be on.)
Is there anything wrong with turning on interrupts while doing PIO
data-transfers? (I think not: we should be doing DMA!)
Is there anything wrong with setting the fs readahead to 16? (That
should work, no matter what the drive, right?)
Is there anything wrong with turning on 32bit access mode? (Any
modern drive should do this, right?)
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?
Hmm. The -X option is documented as dangerous. What's dangerous about
it?
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?
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
