| This bug/feature was recently uncovered during V4.8 SRM console qual.
It's been there since Day One and is fixed in the soon-to-be-released
V4.8 console. What causes this is the user swapping a PCI boot adapter,
pointed to by bootdef_dev, with a non-boot adapter/device. An example
would be a KZPSA being swapped with a VGA card..
To get out of this state, one needs to either restore the adapter
configuration or erase the SRM console's NVRAM (which will cause all
saved environment variables to be lost..)
To erase the SRM's NVRAM, type the following at console:
P00>>> d eerom:1800 -b -n 7ff 0
Then cycle reset and reset any preferred environment variables.
For the record, the V4.8 console adds a couple features around
saving/restoring NVRAM contents to/from a floppy diskette. Namely,
save_nvram and restore_nvram scripts which tell the user what to do.
Clear_arc_nvram and clear_srm_nvram scripts have also been added so
one does not need to remember the above deposit sequence. And again,
V4.8 also fixes the problem described in the base note.
The V4.8 console is expected to FRS on 2/7 to support some 4100/4000
CPU upgrades and will ship on the V3.9 FW CD which is scheduled to ship
on 3/3.
If questions, let me know.
BC
|
| Note that boots and autoboots that use bootdef_dev will also hang if
the NVRAM gets into this state. If auto_boot is set to halt and
bootdef_dev points to a boot device, should the user swap the boot
adapter with a non-boot addapter (e.g. a VGA), the subsequent auto-
boot will hang. To recover from this situation, depress the front-panel
halt button to regain control of the console. Then use one of the
methods described in .1 to restore the system to an operable state.
|