jle@cfm.brown.edu (Jon Elion) (12/10/90)
Many thanks to all those responding to my problem "SunOS 4.1 crashes exiting SunView or OpenWindows". I received many helpful suggestions, and one definitive solution. I had discovered on my own that the problem was in the use of the "reset" command, included in shell scripts that invoked the windowing environments. It was suggested that when running X-Windows (or OpenWindows), instead of using "reset", one should check out "kbd_mode -a" to clear up the console. The correct analysis and solution came from a kind soul at Sun.COM. Since I have heard a rumor that Sun employees are discouraged from replying to network queries directly, I will not mention his name -- you know who you are and I thank you for your help. The problem with "reset" crashing the system turns out to be an EEPROM configuration problem. There's a location which identifies what type of frame buffer you have. I haved a cgsix (GX), and it was set to a be a routine color monitor (as if you had said "eeprom console=color"). Then, "reset" tries to talk to the board that is there, but it isn't. The byte to be configured is location 0x1f: 00 - monochrome monitor 10 - ttya 11 - ttyb 12 - color monitor and 3/60 plug-in color frame buffer 20 - P4 Color frame buffer Get to the PROM monitor (for example, "shutdown -hf now"). At the ">" prompt, change the value with the "q" command: >q 01f Your current value will be displayed. Enter "20", then a "." to end the patches. Reboot, and "reset" will be working correctly.
datri@uxc.cso.uiuc.edu (Anthony A. Datri) (12/11/90)
>(or OpenWindows), instead of using "reset", one should check out "kbd_mode >-a" to clear up the console. kbd_mode -a will put the console into a normal state -- sometimes after the (mit at least) X server shuts down, the console is in a strange state where every key seems to be interpretted as a return. I have xinit aliased to unset autologout; /usr/bin/X11/xinit >& /tmp/xinit.out ; kbd_mode -a The redirect helps in debugging screwy .xinitrc files. >The byte to be configured is location 0x1f: > 00 - monochrome monitor > 10 - ttya > 11 - ttyb > 12 - color monitor and 3/60 plug-in color frame buffer > 20 - P4 Color frame buffer Hmmmmm. I've run afoul of this before. When one purchased a color 3/60, you got a cpu board without the bwtwo circuitry on it, but spare boards all have the bwtwo. So, when you swap a color board with a spare, you end up having two bwtwo's, and I've never quite figured out what effect that's *supposed* to have. I have a couple machines like this that experience strange behavior (up to and including spontaneous reboot) when reading *certain* images. This location is "documented" in /usr/include/mon/eeprom.h, where one can find all *kinds* of interesting things. It says (4.1): * 0x01f */ char eed_console; /* device to use for console */ #define EED_CONS_BW 0x00 /* use b&w monitor for console */ #define EED_CONS_TTYA 0x10 /* use tty A port for console */ #define EED_CONS_TTYB 0x11 /* use tty B port for console */ #define EED_CONS_COLOR 0x12 /* use color monitor for console */ #define EED_CONS_P4 0x20 /* use the P4 monitor for console */ Of course, it's not *really* clear from this file what "color" means. I think that the repaired machines I mentioned above perhaps had this set to 0, and things worked okay as long as the on-board bwtwo didn't exist, but when one started existing, all I got was blackness on the real console. Poking around blind in an eeprom is great fun8^). >Get to the PROM monitor (for example, "shutdown -hf now"). At the ">" By the by, you can do this kind of stuff without shutting down -- just hit L1-A, diddle away, and hit 'c' at the > prompt to continue. You'll want to refresh your display, but it works fine. I once laboriously typed in a custom logo this way, only to have the machine move to another desk a week later.