support@dg-rtp.dg.com (Data General Support) (09/01/90)
In article <1567@uvm-gen.UUCP>, ackerman@sadye.uvm.edu (Steve Ackerman) writes: >We're attempting to write a stand-alone program that runs without >the DG/UX kernel...our program bombed hard a few times. By hard, > I mean the machine needed to be power-cycled, and upon reboot, >some of the configuration parameters were trashed... One time, the >machine crashed and never came back up... We sent it back to be repaired. >...We got it back this Monday. Last night, while working on the same >code, the machine broke again... We weren't doing anything device specific > -- just trying to set up our own (basic) exception handler... >We've called DG, but they said send it back. I would hate to >think that our software could damage the DG so much as to require >everything to be replaced. I think that our problem could be as >simple as screwed up configuration settings (somewhere). Mr. Ackerman seems to be writing into an area which is reserved for non-volatile RAM (0xfff80000 - 0xfff81fff). Some of this space is write protected by the hardware, but most of it is not since it contains user-settable information. This user-settable information includes the parameters which can be modified by executing the SCM level format command. The information in this area is used both by the PROM (SCM) and by DG/UX to determine operating characteristics. If this information is altered in an invalid way, the results can vary from incorrect system operation to an inability to power up the machine. Since it is impossible for us to write-protect this area without restricting users from specifying various operating characteristics, those writing device drivers need to make sure they are not writing to this area. If this situation does occur, try these steps to recover: (1) Power down the machine and power it back up again. (2) If the machine does not power up correctly (no text appears on the console) turn the power off and back on. Wait 3 minutes, then turn the power off and back on again. In most cases of non-volatile RAM corruption, this should rectify the situation. If at this point you do not get any text on the console, press the key sequence < control-V > followed by a "1". This will reset the terminal emulator parameters and should enable you to see text output. If you do not, this means that the contents of the non-volatile RAM are not user-recoverable, and the CPU board should be sent back to DG for repair. If you do see text on your console, continue with step 3 below. (3) You should see an SCM prompt at this point. If your console is an asynchronous terminal, you should now be able to boot your system. If your console is a graphics monitor you will need to set the DG/UX parameters for X Window dimensions before you can boot. You should contact your DG support representative for instructions. If these steps do not resolve your problem, you should contact your Data General Support Representative for further assistance. Data General customers who are experiencing problems with their systems or have questions about DG products are strongly urged to contact their Data General support representative for assistance. --Data General Support