Re: Odd network behaviour
On Wed, Oct 02, 2002 at 09:05:43PM +1000, Simon Bland wrote:
> On Wed, Oct 02, 2002 at 08:30:00PM +1000, Donovan Baarda wrote:
> > Don't forget the old reliable (adjust params to your particular situation);
> >
> > hdparm -m16 -c1 -d1 -u1 /dev/hda
> > irqtune 3 14
> >
>
> After setting this up and doing a little testing it seems this has fixed
> the problem, or at least fixed the symptoms. ;)
>
> Are these configs stable over boot, or do I need to run config it after
> any reboot?
If you install the hwtools package, it has an /etc/init.d/hwtools script
that needs tweaking that will apply these settings on boot.
> BTW, those who mentioned it might be due to hardware not up to spec, is
> that likely to be the real cause of the problem? I find it difficult to
> believe that a system using an AMD XP 2200+ would have that sort of an
> issue.. But I guess new hardware could still be a problem.
I believe the Debian kernels still default to DMA off for IDE drives. Not
just DMA off, but effectively "hdparm -m1 -c0 -d0 -u0"... ie, the slowest
most conservative settings possible. This is so you don't get data loss
problems that are possible with some (old) dodgey chipsets.
The "-u0" in PIO mode effectively blocks all interrupts while an IDE request
is being processed. I'm not sure exactly, but if it blocks interrupts for a
whole ide request/responce transaction including the 10ms seek time, that's
a damn long time not to service a serial interrupt. At 115.2Kbps it only
takes about 1.5ms for a 16550's 16 byte fifo to overflow.
With the default non-irqtune'd interrupt priorities, two ide interfaces
getting hammered could effectively block serial interrupt servicing routines
for a significant time. The two drives could ping-pong interrupt service
routines between each other, effectively denying the "low priority" serial
interrupt.
In fact, that is so bad I can't believe the PIO mode -u0 would be like that,
otherwise heaps more people would be having heaps more problems... it also
wouldn't surprise me in this day of ATA-133 if some new drives had very bad
PIO mode implementations. In any case -d1 avoids all these potential
problems and makes your HDD heaps faster :-)
I suspect you might have some marginal hardware issues too that contribute
to the problem. IRQ conflicts and/or a misconfigured serial port can do it
(ie, does it think they are 16450's or 89xx? UARTS with no FIFO... hence
configuring them with the FIFO disabled?).
Do you have any strange hardware in the machine? If this hardware had a
dodgey driver with very long irq-blocking interrupt service routines you
could also hit this problem. In this case the irqtune would probably help,
but you might still hit it occasionaly.
I wonder if a machine that fast might be triggering some strange race
conditions...
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: