ohurley@cs.tcd.ie (Oisin Hurley) (06/07/91)
[Posting this for a friend of mine who doesn't have news access facilities] This guy works on a 386 machine running ISC 2.0.2 . An interesting thing occurred the other day when he manually killed a process - the message WARNING: Timeout table overflow was sent to the console, continuously, resulting in the machine getting locked up. The process that was killed is designed to be a longlife effort, running in the background and supervising 7 or 8 attached child processes. It also has a message queue associated with it as do most of the children and messages fly about like nobody's business. Some of the babies also connect to a database. Has anybody come across this before? Does anybody know what's happening (in detail)? Any (sane,relevent) contributions would be welcomed. O[-< ---- ombhurley@cs.tcd.ie Oisin Hurley, Dept. of Computer Science, TCD, Dublin 2, Ireland. ----
mike@bria.UUCP (mike.stefanik) (06/09/91)
In an article, ohurley@cs.tcd.ie (Oisin Hurley) writes: >This guy works on a 386 machine running ISC 2.0.2 . An interesting thing >occurred the other day when he manually killed a process - the message > > WARNING: Timeout table overflow > >was sent to the console, continuously, resulting in the machine getting locked >up. [...] Generally speaking, this is a kernel configuration problem. Your callout table in the kernel isn't large enough (trying increasing the size of the NCALL configuration parameter). This may indicate a problem with a device driver on your system. Typically, the callout table is used by drivers to specify entry points in it's code to execute by the kernel's clock handler at a specific time. Drivers call the function timeout() and provide a pointer to a function, an argument to that function, and the number of clock ticks in the future that the kernel should invoke it. The most common uses are for waiting on a busy device and sleeping for n clock ticks, although delay() really should be used in the latter case. Where you can get into trouble is when you use timeout() in the init portion of the driver but the clock handler is disabled by a high priority device. Hope this isn't *too* muddled. :-) -- Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- If MS-DOS didn't exist, who would UNIX programmers have to make fun of?