Xref: utzoo unix-pc.general:3597 comp.sys.att:7343 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!mtunb!jcm From: jcm@mtunb.ATT.COM (was-John McMillan) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: What does a "panic: trap 11" mean, and what can I do about it? Summary: May be RS232 error Keywords: RS232 Message-ID: <1625@mtunb.ATT.COM> Date: 19 Aug 89 14:34:36 GMT References: <1989Aug18.011357.28605@ziebmef.uucp> Reply-To: jcm@mtunb.UUCP (John McMillan) Organization: AT&T ISL Middletown NJ USA Lines: 48 In article <1989Aug18.011357.28605@ziebmef.uucp> cks@ziebmef.uucp (Chris Siebenmann) writes: : >[My Motorola 68K handbook says exception 11 is "line 1111 emulation" - > is this what this panic is referring to, or is it an actual TRAP > opcode with a garbage value?] : "Trap 11" is one of a half dozen deaths associated with a corrupted PC [Program Counter]. The principle cause of this in the UNIX(r)pc kernel lay in the RS232 driver code. The two types of RS232 chips -- one on the MB, which handles the Serial & phone ports, and the other on the Combo board -- have many two step instructions: 1) Load an index register for the next access; 2) Read/Write data from the indexed register. These pairs of operations MUST-MUST-MUST-MUST be performed ATOMICALLY! If another RS232 access splits these, the first one is corrupted: eg., 1a) IR=2 interrupt 1b) IR=3 2b) R[IR]=X interrupt exit 2a) Y=R[??] What typically resulted was that chips' interrupt handlers were reading the interrupt-type value [range 0->7] and getting an arbitrary [corrupted] value which exceeded the jump-vector table's size. This jump to an "arbitrary location" [not quite arbitrary 8) ] could give any of many unattractive results -- such as EMT's. There were other corruptions too.... Unfortunately, the code -- particularly that of the phone subsystem -- is so obscured with defines, pointers, and clock-driven [ie., SPL6 initiated RS232 accesses] events that it took quite a while to find ALL [?] the interactions that had to be SPL6'd. I think the HOTLINE's latest kernel/combo driver should solve these. [Note: the quest to find these #%$&* was central to the release of the 3.51a (incomplete), 3.51b (lethal&inc.), 3.51c (almost complete) and 3.51c+ (YEH!) fixes. MANY other fixes went into the kernels, but the main theme for all but 3.51c was trying to track down all these things that should've been written correctly from the start.... sigh. (Obv. _I_ didn't write the original code 8)) ] john mcmillan -- att!mtunb!jcm -- muttering for himself, only