ron@brl-sem.ARPA (Ron Natalie <ron>) (04/21/86)
> What is a "red and green" stack violation? I've heard references to this > over the years, but no one has given me a satisfying explanation. > Does it exist only on obscure members of the PDP-11 family, or is it > a common, universal condition to which DEC has assigned a cute name? > Actually it is red and yellow stack violation. It isn't obscure PDP-11's just the big ones (45's and 70's). You'd get a warning trap when the kernel stack went below one address and a red stack when it went beyond a further limit. We installed code in our UNIX to process these traps. The problem is however, that you never see YELLOW STACK violations. The only time the stack even gets close to being out of range is when it gets loaded with garbage and that gets you a RED STACK fault immediately. This however was very useful in dealing with test versions of the operating system and flakey hardware, just one more consistancy check that shows up as something solid rather than looping or wierd trapping (you can't really do much in UNIX once the stack goes, we just halt with a distinctive pattern in the console lights, you know back when machines had lights). -Ron
jdb@mordor.UUCP (04/23/86)
In article <164@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >> What is a "red and green" stack violation? I've heard references to this >> over the years, but no one has given me a satisfying explanation. >> Does it exist only on obscure members of the PDP-11 family, or is it >> a common, universal condition to which DEC has assigned a cute name? >> >Actually it is red and yellow stack violation. It isn't obscure PDP-11's >just the big ones (45's and 70's). Smaller (or maybe only older?) PDP-11's have a fixed stack overflow boundary at location 0400. I seem to recall that RSX-11M put its stack down at the bottom of memory. I'm not sure why they thought a stack which extended down to the middle of the interrupt vector space (0 - 0777) was ideal. The yellow and red limits are 16 words apart. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb