On Mon, 16 Nov 1998, Olaf Meyer wrote:
> Now __wait_on_buffer only gets called in wait_on_buffer and lock_buffer (I'm
> using a 2.0.33 kernel) These in turn mainly get called from filesystem and
> char/block device related code. I don't do any file related stuff. In fact I
> only execute my own code and some socket buffer related code (like alloc and
> free). I included a small portion of the code which shows where the freeze
> occurs. I actually run through this section without any problems over
> 25,000 times before the freeze occurs ...
However, the problem is not necessarily related to the code that calls wait_on_buffer.
Remember, the schedule() function thinks that it's being called from an interrupt
if the ``intr_count'' variable is greater than zero. But just because the variable
is greater than zero doesn't mean that you are in fact in an interrupt; it
could just be that the variable was somehow set to an incorrect value.
For example, there may be an artificial increment of intr_count somewhere without
a matching decrement, such as a call to start_bh_atomic() without a corresponding
call to end_bh_atomic(). Leaving an unbalanced increment on intr_count would
be very bad indeed.
This variable is incremented when you are in an interrupt and decremented when
you leave. It's also artificially incremented in some places; the scheduler
itself changes it from 0 to 1 to do bottom-half processing, because bottom half
processing always runs with intr_count equal to 1; if an interrupt happens
during bottom half processing, it will not recursively trigger bottom half
processing because intr_count will be greater than 1.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
