Thanks to some good testing and debugging by Gerard Roudier we seem to
have a handle on this problem. It wasn't an interrupt overflow at all,
but a recursion in get_more_buffer_heads().
One page of stack should be plenty: you can try to press shift- (or was
it ctrl-?) ScrollLock when in text-mode, and you'll see some kernel
debugging info, including how much free stack we have. At least when I
do this, I've never seen the free count go below 2600 bytes (out of
4096), so we aren't even halfway.
> So how am I to know whether my interrupt handler (along with the SCSI
> completion processing) is using a "reasonable" amount of space?
It really shouldn't be much of a problem, as long as people don't
allocate arrays or structures on the stack (or do recursive stuff). The
problem with the 1.3.6x kernels was that the way we use buffer heads
changed radically: we used to allocate a new buffer (and thus a new
buffer head) only when we had enough memory for it.
However, with the new page cache, we allocate much less buffers, but
instead we allocate a lot of buffer heads to give to device drivers so
that they can fill in (or write out) pages of data. That broke the old
"get_free_buffer_heads()", which assumes that we generally have memory
free to allocate buffer heads.
"get_more_buffer_heads()" will try to allocate a new page for buffer
heads if there are none free, and the problem is that this new
allocation might want to swap out some old memory to disk - and thus it
wants more buffer-heads for that IO. Oops, instant recursion.
Anyway, the problem is known now, and there is just a small matter of
fixing it. It shouldn't be too bad, but I'm still thinking about the
best way to handle it.
Linus