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 [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
