Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!pyramid!prls!mips!roger From: roger@mips.UUCP (Roger March) Newsgroups: comp.unix.wizards Subject: Device driver timeout question ... Message-ID: <570@obiwan.UUCP> Date: Wed, 5-Aug-87 12:08:13 EDT Article-I.D.: obiwan.570 Posted: Wed Aug 5 12:08:13 1987 Date-Received: Tue, 18-Aug-87 03:01:40 EDT Lines: 33 Keywords: device driver, timeouts, sick devices A friend (yeah, sure), no really, a friend of mine is trying to patch up this device driver and foolishly came to me for help, so now I'm asking you. It is a block device and locks up when the cable isn't connected or people chew on the power cords, well at least when the cable isn't connected. I suspect that the lack of a cable means the DMA never starts and most certainly the device driver will never get an interrupt from the controller. It seemed to me that a possible solution was: 1) Enter the "strategy" routine and set up the DMA. Also set a "timeout" for N minutes. Wait for 2) or 3). 2) On a timeout, print a horrible error message and try to clean things up. 3) On a DMA complete interrupt, indicate that when the timeout occurs you were just kidding and everything is really okay. The above does some nasty stuff now when the cable is connected. Since the "timeout" is for N minutes, and requests to the device can be much quicker than this, it looks like I can expect to have several outstanding "timeout"s working; one of which may be valid. So (finally) my question is: is there a way to kill outstanding an "timeout" when realize it is no longer neccessary? If not, is there a limit to how many "timeout"s can be issued before some buffer in the kernal fills? Or, is my algorithm totally brain damaged and I should go back to writting AI programs for microprocessor controlled toasters? Thanks. -- -Rogue Monster UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!roger OR roger@mips.com USPS: MIPS Computer Systems, 930 Arques, Sunnyvale, CA 94086, (408) 991-0220