Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!hplabs!hao!seismo!rlgvax!cvl!umcp-cs!chris From: chris@umcp-cs.UUCP Newsgroups: net.unix-wizards Subject: Re: UDA50/RA81 problems.... Message-ID: <8114@umcp-cs.UUCP> Date: Tue, 21-Aug-84 01:46:58 EDT Article-I.D.: umcp-cs.8114 Posted: Tue Aug 21 01:46:58 1984 Date-Received: Sat, 18-Aug-84 00:34:07 EDT References: <12383@sri-arpa.UUCP> Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 45 First: Please post diff's to the 4.2 UDA driver. Second: The reason for the Get Unit Status command in the first place (the one which floods the UBA and UDA with interrupts) is because *something* has to be done at that point, and I suppose the author of the original code felt that M_OP_GTUNT was the least drastic. Here's the scenario: N requests for Unibus BDPs all granted. (N depends on CPU type.) UDA50 requests BDP. Request is denied because the UBA is out of BDPs. The driver can't wait for one because this is happening at interrupt level. What to do? Solution 1: return from the interrupt code, without doing anything at all. This would work except for one snag: what if there are no transfers pending on that controller? No more interrupts will occur, and we'll never get another shot at grabbing a BDP and starting the transfer. (Another thing would need to be done is allocate the MSCP packet *after* getting the BDP, not before. Unless you know a way to give back an MSCP packet . . . ?) Solution 2: do a Get Unit Status. That doesn't need a BDP and can use the handy MSCP packet that's already been allocated. Unfortunately, it floods the UBA with interrupts until a BDP is finally released. Solution 3 (my favourite but requires hacking the UBA code): Return from the interrupt code after exacting a promise from the UBA code to call the interrupt routine again once a BDP is free. Requires some sort of queueing, alas. Another possibility is to just set a flag someplace and have a callout daemon (the udwatch watchdog routine that isn't there for some reason, perhaps) call the interrupt routine. Easier but not as aesthetic. Solution 4: apply Solution 1 after moving all other devices that use BDPs to another Unibus. That would guarantee that the snag never occurs. However, while technically feasible, it may not be a viable option. (I can just see trying to justify another UBA to the state ``because we can't write the software right''. . . .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland