At 01:59 PM 12/23/97 -0800, you wrote:
>> I am now.  Bill, do you know what might be causing this?
>> It might be a side-effect of Takashi's changes (might, perhaps,
>> have something to do with spl's?).
>
>Not really. What are Takashi's changes?
>
>> To recap, in case anyone missed this, Takashi's kernel that was
>> modified by him to work on a PB180, works fine, until one tries
>> to do some serial-port intensive I/O (in my case, dialing up a serial
>> connection over a modem line and, for example, catting a file,
>> thus causing much input on the serial line).  When I do this, I
>> get some message having to do with serial timeout's (serial timeout
>> overflow, or something like that), and then get dumped into the
>> kernel debugger, from which I must reboot.
>> Does this sound familiar to anyone?
>
>What is the exact error message? Well, I don't need tons of
>register dumps, but I do need the message. Also, what does a
>stack trace show (type "t" in the debugger). I need the names of the
>routines, not necessarily their arguments.

Actually, I found that the panic is happening within timeout()
itself, in kern_clock.c.  The message is "timeout table full".

Now, what do you think could be causing that?  The only thing I
can think of off the top of my head, is that we are handling
many consecutive interrupts at a higher priority than the system
clock, so that many timeouts are never taken off the queue, and
it fills up.

Unfortunately, whatever is happening is screwing up the debugger
as well, because, when I hit ANY character, I get the panic message
again (i.e. hitting 't' doesn't produce a stack trace).

I haven't yet tried simply spitting a bunch of output directly
to the console (and not using the serial port) to see if this causes
the same problem.... I don't think it does, as I've been using
Takashi's kernel for awhile, and have only seen this happen when I
use the serial port with kermit and cat a large file on a
site I've called up.  This hasn't happened when using the serial
port for PPP, so it probably has something to do with lots of data
coming across the serial line AND appearing on the console,
concurrently.  But I'll try just catting large files to the console
to see if that causes it, as well.

- Tim

------------------------------------------------------------
Tim Bessie
tbessie@eci.net
bessie@apeshit.com