Subject: Re: 420R fails to boot
To: None <cg2v+@andrew.cmu.edu, port-sparc64@netbsd.org>
From: None <eeh@netbsd.org>
List: port-sparc64
Date: 11/05/2001 23:58:48
| Excerpts from mail: 5-Nov-101 Re: 420R fails to boot by eeh@netbsd.org
| > | %TL:3 %TT:32 %TPC:1008590 %TnPC:10085a0
| > | %TSTATE:4482041402 %CWP:2
| > | %PSTATE:414 AG:0 IE:0 PRIV:1 AM:0 PEF:1 RED:0 MM:0 TLE:0 CLE:0
| > | MG:1 IG:0
| > | %ASI:82 %CCR:44 XCC:nZvc ICC:nZvc
| >
| > Which then generated a bus fault, which shouldn't happen here...
| I'm assuming you want the disasembly from around this trap. If not, then
| I'm not sure what I'm supposed to be doing.
|
| 1008500 or %g0, 30, %g3
| 1008504 +4 sethi 1c00, %g6
| 1008508 +8 ldxa [%g3]58, %g3
| 100850c +c sethi 18a2400, %g4
| 1008510 +10 or %g6, 3ff, %g6
| 1008514 +14 ldx [%g4 + 348], %g4
| 1008518 +18 srax %g3, 2b, %g5
| 100851c +1c and %g3, %g6, %g6
| 1008520 +20 add %g5, 1, %g5
| 1008524 +24 sllx %g6, 3, %g6
| 1008528 +28 ldx [%g4 + %g6], %g4
| 100852c +2c bprnz,pt %g6, 1008560 +60
| 1008530 +30 sethi 1000000, %g7
| 1008534 +34 sethi 800000, %g6
| 1008538 +38 sub %g3, %g7, %g7
| 100853c +3c subcc %g7, %g6, %g0
| 1008540 +40 sethi 1800000, %g7
| 1008544 +44 or %g0, 6, %g6
| 1008548 +48 stb %g6, [%g7 + 20]
| 100854c +4c tcs %g0, fffffffffffff001
| 1008550 +50 sethi 0, %g0
| 1008554 +54 bpcs,pn %xcc, 1008640
| 1008558 +58 or %g0, 7, %g6
| 100855c +5c stb %g6, [%g7 + 20]
| 1008560 +60 srlx %g3, 21, %g6
| 1008564 +64 subcc %g5, 1, %g0
| 1008568 +68 bpgu,pn %xcc, 1008640
| 100856c +6c srlx %g3, 17, %g5
| 1008570 +70 and %g6, 3ff, %g6
| 1008574 +74 sll %g6, 3, %g6
| 1008578 +78 and %g5, 3ff, %g5
| 100857c +7c sll %g5, 3, %g5
| 1008580 +80 add %g6, %g4, %g4
| 1008584 +84 ldxa [%g4]14, %g4
| 1008588 +88 srlx %g3, d, %g6
| 100858c +8c and %g6, 3ff, %g6
| 1008590 +90 add %g5, %g4, %g5
This is not a memory operation, so it could not have generated
the fault. Let's assume it was caused by the load at 1008584.
That's an attempt to load an entry from the first-level page table,
which is in the pmap. The code here uses physical addresses for
the page tables, so it's either accessing a location that doesn't
exist or some device register instead of RAM. This means that
either the pointer to the current pmap is wrong, or some of the
entries in the current pmap are corrupt.
| 1008594 +94 bprz,pn %g4, 1008608
| 1008598 +98 sethi 0, %g0
| 100859c +9c ldxa [%g5]14, %g4
| 10085a0 +a0 sll %g6, 3, %g6
What's the RAM configuration on this machine? And specifically
which kernel is this?
Eduardo