| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
The message below was sent to me from a friend at EDS. He describes a problem they are having at a customer site. Can anyone glean from the message what the problem is or point me in the right direction? >---------- >From: Bob Elliott[SMTP:[email protected]] >Sent: Tuesday, April 08, 1997 9:52 AM >To: Devin Lucas > > > Devin > > Say, let me ask you a question. One of our TSS people is trying > to install DUX V4.0A onto an Alphastation 250. When he boots the > 4.0A CDROM things seem to go along fine then he gets: > > DECchip 21071 > 82378IB (SIO) PCI/ISA Bridge > Firmware revision: 6.2 > PALcode: OSF version 1.46 > pci0 slot 6 > Loading SIOP: script 801f00, reg 83040000, data 80de98 > scsi0 at psiop0 slot 0 > rz0 at scsi0 target 0 lun0 (LID=O) (DEC RZ28D (c)DEC 0008 > r24 at scsi0 target4 lun0 (LID=1) (DEC RRD45 (c)DEC 1645 > t25 at scsi0 target5 lun0 (LID=2) (DEC TLZ07 (C)DEC 553B > isa0 at pci0 > panic (cpu0): rmalloc > DUMP: No primary swap, no explicit dumpdev. > Nowhere to put header, giving up. > CP - SAVE_TERM routine to be called > CP - SAVE_TERM exited with hlt_reg=1,r0 = 00000000.00000000 > > halted CPU 0 > halt code = 5 > HALT instruction executed > PC - fffffc0000405040 > >>> > > Now information that you may need: > > Digital 250 4/266 > Final page from 'boot dka400' from Digital UNIX V4.0A - CD > Firmware installed from: Firmware Update V3.7 - CD > > If you have any idea as to what is going on it would be greatly > appreciated. At this point we have a customer that is down. We > cannot get DUX V4.0A to install. > > THANKS > Bob E. >
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9433.1 | Actually an easy one... | RHETT::LACORTI | Tue Apr 08 1997 16:00 | 6 | |
This will fix it
>>>isacfg init
>>>init
Sandy
| |||||
| 9433.2 | 4.0a install panic during boot | NNTPD::"[email protected]" | Soo Veiter | Tue May 06 1997 06:07 | 1 |
[Posted by WWW Notes gateway] | |||||
| 9433.3 | 4.0a install panic during boot | NNTPD::"[email protected]" | Soo Veiter | Tue May 06 1997 06:13 | 7 |
Hi everyone, Refer to Rehett Lacorti reply to enter isaconfig then init does not work. I am not to sure if Devin Lucas has got the customers to work. Can anyone help! [Posted by WWW Notes gateway] | |||||
| 9433.4 | clarification needed? | NNTPD::"[email protected]" | Farrell Woods | Wed May 07 1997 15:14 | 32 |
Actually, .1 was quite specific and I'm uncertain from the replies if those exact instructions were followed: >>>isacfg init >>>init "isacfg init" does something completely different than an unadorned "init". The issue may be this: certain firmware updates to these systems leave the NVRAM in an inconsistent or incompatible (with the newly installed firmware) state. The "isacfg init" command clears the NVRAM. Any subsequent changes to the NVRAM will be compatible with the newly installed console. One word of caution though: BEFORE re-initializing the NVRAM, scribble down any config info for any ISA options installed in the system (sound card, modem, etc.) You will need to put that info back, manually, after using the "isacfg init" and "init" commands. If you don't then the OS won't see those pieces of hardware. This doesn't apply to built-in devices such as the keyboard, mouse, etc. Those get put back automatically. PCI device info is unaffected. The panic in .0 *could* potentially arise from an incompatibility between the format of the info in NVRAM and the console, if the console code was updated prior to the OS installation. The OS will retrieve info about ISA devices from the console. If the console supplies gibberish for that info, it could potentially cause trouble for the OS. -- Farrell [Posted by WWW Notes gateway] | |||||