Miquel van Smoorenburg wrote:
In article <[EMAIL PROTECTED]>,
Daniel B. <[EMAIL PROTECTED]> 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?
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)?
Does the kernel not handle serial port interrupts with higher priority
than disk interrupts to make sure that serial data doesn't overrun
buffers?
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?
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).
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?
Thanks,
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
