[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: why do PPP connections die with heavy disk usage?

Miquel van Smoorenburg wrote:
On Thu, 2005-07-21 at 14:04 -0400, Daniel B. wrote:
Miquel van Smoorenburg wrote:

In article [🔎] 42DD0F2B.8080008@fgm.com"><[🔎] 42DD0F2B.8080008@fgm.com>,
Daniel B. <REMOVEdanielTHIS@fgm.com> wrote:

Does anyone know why Linux can't seem to maintain a diald-dialed serial
PPP connection while performing lots of disk I/O, especially on a PIO-mode
IDE disk?
Because the IDE driver turns off interrupt processing completely
when issuing commands to / reading data from the drive. With DMA,
you don't really notice, in PIO mode, you do ..
If it turns off interrupt processing completely, how would, say,
keyboard and timer interrupts get processed?  Wouldn't I be seeing
keystrokes getting dropped occasionally?
It blocks them, ofcourse. The hardware still sets the interrupt bit.

Do you mean that interrupt handling is _suspended_ when writing
to/reading from the drive (that is, other interrupts aren't ignored
entirely; just deferred)?
Same difference :)

Does the kernel not handle serial port interrupts with higher priority
than disk interrupts to make sure that serial data doesn't overrun
Because the IDE driver simply turns all interrupts *off* ...
I would think that even if the kernel IDE code had to disable
interrupts while performing a PIO-mode transfer, as soon as it
re-enabled interrupts (at the end of the IDE operation), pending
interrupts would be handled.

Does one IDE operation (in PIO mode) take so long that the
serial port buffer overflows before the disk operation is done?
Are you using a 2.4 or 2.6 kernel?

In the 2.6 kernel, each interrupt is locked and disabled/enabled individually to avoid problems like this.
Or are pending interrupts not all processed before a subsequent
IDE operation is started?

To change this, see "man hdparm", -u option.
Well, given that the manual page says:

   -u ... Use this feature with caution: some drive/controller
      combinations do not tolerate the increased I/O latencies
      possible when this feature is enabled, resulting in massive
      filesystem corruption.

I'm not about to try that, since the reason I'm using PIO mode
in the first place is because I get massive file system corruption
when I use DMA mode with IDE controllers on my motherboard (Asus
A7M266-D; AMD 762(?) chipset).
Have you reported this to the kernel IDE maintainers ?
Yes, this needs to be reported and fixed or worked around.

Where is your kernel from, and how is it configured?  Does it try to use dma with your drive automatically, or did you have to force it with hdparm?  Post the output from lspci also.
Would setting one of hdparm's sector-count options to a small value
decrease the length of time interrupts are disabled and reduce the
chances of problems with serial communication?
I don't know, I try to avoid broken hardware :)

Many times, it is broken drivers.


Reply to: