They could be, if any part of the kernel stays in a loop for too long
without calling schedule() and without causing page faults (the kernel is
not preemptive). Rogier Wolff told me that this can happen if you do
read(2)/write(2) with big block sizes, but I'm not doing that.
> But the time between two calls to schedule() that
> schedule your process in is unbounded (depends on the no of processes
> in the system)
This is not my problem (the process that receives the data is running with
realtime priority, so it probably would be fast enough). The problem is
that the data never reaches user space (and not even the TTY buffer). It
gets lost inside the interrupt handler due to flip buffer overruns. This
happens because the flip buffer obviously doesn't get flipped fast enough.
I don't know what exactly causes the delays for the flip buffers. They
should be flipped from the timer queue which is run every time schedule()
is called. So either there are times when nobody calls schedule() (this is
what I suspect; I'll add some debug code to check this) or the timer queue
gets disabled for too long (this is what Bill Hawes suggested earlier this
year -- I'll try his patch, but I'm not too optimistic).
Some updated information about the exact circumstances when the overflows
happen: The probability that I get an overflow seems to rise if the
machine is paging heavily. But the overflow can also happen when the
machine is nearly idle and there is only a short disk access. Also, as I
wrote earlier, the problem is not reproducible, because I can run X, gs and
xv all simultaneously without having any problems (with 8MB, the machine is
nearly thrashing but there are no overflows).
Martin
-- /* Martin Buck E-Mail: martin-2.buck@student.uni-ulm.de */ /* Student of electrical engineering WWW: http://www.uni-ulm.de/~s_mbuck1/ */ /* University of Ulm, Germany Snail-Mail: Paukengasse 2, 89077 Ulm, Germany */ #include <disclaimer.h> /* PGP Key available MIME-Mail welcome */