| > We simulated "force crash dump" by ^p but the console jumps into
> the debugger mode.
Why do you say this is a simulated crash? Did you do something other than
a normally supported ^P which could be followed by a >>>CONT. Or do
you mean that you were going to get to >>> and then issue a CRASH
command.
Do you know what was different the time you ^P'ed and got the 8A0 interrupt
problem as compared to times when you successfully ^P.
When you ^P, you should have entered console at elevated IPL, and you
should not have received any interrupts. An 8A0 looks like it might be
an interrupt from some IO device, but I am not sure it matters. The
console should not have dropped its interrupt level below 31 and allowed
in any interrupts.
|
|
RE: 1075.1
>Why do you say this is a simulated crash? Did you do something other than
>a normally supported ^P which could be followed by a >>>CONT. Or do
>you mean that you were going to get to >>> and then issue a CRASH
>command.
Please forget the words "simulated crash". I just meant doing a normally
supported ^P. I expected a ">>>" prompt came back, then I can type CRASH
to get a dump file.
In this case, after we typed in ^P, the console has never come back a ">>>"
prompt but got the following printout immediately:
.
halted CPU 0
CPU 1 is not halted
CPU 2 is not halted
CPU 3 is not halted
halt code =1
operator initiated halt
PC = fffffc0000380f50
Punexpected exception/interrupt through vetor 8A0
Unexpected IO device interrupt : 8A)
prcoess timer, pcb = 0010f240
.
. ; dump pc, ps,r2, r5,r3,r6,r4,r7
. ; registers.
.
Brk 0 at 000656F4
000656F4 ! BPT
Eh ?
Eh ?
Then we reset the machine.
Regards, C.S.
|
|
o When the system hung, was it crashing or was it up and normally operating?
o Did it hang while trying to crash dump?
o What was the boot device?
o What is the dump device?
Next time you have access to that system in console mode, issue a
">>> show conf -v" command and capture that if you can. This will
display the interrupt vectors the console uses. These vectors may be
totally unrelated to the event because the 8A0 vector was probably
assigned by Unix and not by console and so we cannot relate it back to
a device. But just for yuks, issue the ">>> show conf -v". It will
look something like:
P00>>>show conf -v
Name Type Rev Mnemonic Vector
TLSB
0++ KN7CE-AB 8014 0000 kn7ce-ab0 002
4+ MS7CC 5000 0000 ms7cc0 100
6+ KFTHA 2000 0000 kftha0 800
8+ KFTIA 2020 0A02 kftia0 db0
C0 Internal PCI connected to kftia0 pci0
0+ ISP1020 10201077 0001 isp0 0df
1+ ISP1020 10201077 0001 isp1 0e3
2+ DECchip 21040-AA 21011 0023 tulip0 0e7
4+ ISP1020 10201077 0001 isp2 0ef
5+ ISP1020 10201077 0001 isp3 0f3
6+ DECchip 21040-AA 21011 0023 tulip1 0f7
C1 PCI connected to kftia0 pci1
0+ SIO 4828086 0005 sio0 111
6+ VGA D1011 0022 vga0 12a
7+ DEC PCI FDDI F1011 0001 pfi0 12e
Controllers on SIO sio0
0+ DECchip 21040-AA 21011 0024 tulip2 116
1+ FLOPPY 2 0000 floppy0 007
2+ KBD 3 0000 kbd0 006
3+ MOUSE 4 0000 mouse0 003
EISA connected to pci1 through sio0 eisa0
C8 XMI connected to kftha0 xmi0
1+ DEMNA C03 0803 demna0 880
2+ CIXCD C2F 0811 cixcd0 8c0
3+ DEMFA 823 0521 demfa0 900
8+ DWLMA 102A 020A dwlma0 940
E+ KZMSA C36 5256 kzmsa0 980
C10 FBUS connected to kftha0 fbus0
5+ DWLAA 2003 0000 dwlaa0 a00
7+ DEFAA 2006 0000 defaa0 a40
|