Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!uhura.cc.rochester.edu!ur-valhalla!micropen!dave From: dave@micropen (David F. Carlson) Newsgroups: comp.unix.microport Subject: Re: Losing interrupts? Summary: worse than that, its an Intel problem Message-ID: <553@micropen> Date: 30 Sep 88 18:20:48 GMT References: Organization: Micropen Dirent Writing Systems, Pittsford, NY Lines: 22 In article , nelson@sun.soe.clarkson.edu (Russ Nelson) writes: > I notice that the section of the Runtime System manual that deals with > Writing Device Drivers and interrupts says that interrupts can be > lost. Is this true? If so, does Microport consider it a bug (i.e. > will it be fixed?) > --russ (nelson@clutx [.bitnet | .clarkson.edu]) The problem is not Microport's: its the d*mn IBM PC/AT interrupt controller (aka Intel 8259.) The problem is not solvable in software alone, thus Microport is not to blame. It was nice of them to tell you that it is a problem though so you won't pull your hair out trying to figure our why. It is good device driver design to *assume* you will lose a critical interrupt so your design can cover its ass with a polling. If the "next" interrupt time is known, a callout can be done to "simulate" the missing interrupt. The rule for device drivers anywhere is that there is no such thing as reliable interrupts. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll