Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!mit-eddie!mit-vax!eagle!mhuxt!mhuxi!mhuxa!houxm!hocda!spanky!burl!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!uiuccsb!emrath From: emrath@uiuccsb.UUCP Newsgroups: net.unix-wizards Subject: Re: Nested spl's really needed? - (nf) Message-ID: <2351@uiucdcs.UUCP> Date: Fri, 1-Jul-83 23:35:30 EDT Article-I.D.: uiucdcs.2351 Posted: Fri Jul 1 23:35:30 1983 Date-Received: Thu, 7-Jul-83 12:09:56 EDT Lines: 29 #R:ccvaxa:15200007:uiuccsb:14900001:000:1201 uiuccsb!emrath Jul 1 18:16:00 1983 The question about nested interrupt levels prods me to ask a related question that I have wondered about before. Can somebody explain the following code in "locore.s" at "alltraps:"? alltraps: .... mtpr $HIGH,$IPL # <<< WHY IS THIS HERE??? rei This mtpr instruction raises the priority level to the max, so that the rei won't fail by trying to go to a higher priority level. When I first read that the rei instruction checked for this, I thought it was really smart, for it helps the system programmer find buggy code which improperly handles the priority level. Any interrupt/exception routine that LOWERS the priority below the interrupted level had better know damn well what it is doing. I've seen systems that would crash or hang once every 3.2 blue moons, only to find that some interrupt routine was lowering the priority, allowing re-entry or corruption of data structures (possibly of some unrelated device handler). The mtpr instruction should not be there. Any routine that lowers the priority should explicitly raise it again, and the reason for doing so should be WELL commented. Perry Emrath, Univ. of IL ...{decvax|inuxc}!pur-ee!uiucdcs!emrath emrath.uiuc@rand-relay