I've narrowed down the bit of code that triggers the MMU Fast Cache Miss when booting silo on cdroms.
The problem is in boot/second.b; setup_stack calls my_main(), which
calls bootmain(), which calls diskinit(), which calls
open("/[EMAIL PROTECTED],700000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a"). The
prom version is
PROM_P1275, so prom_cmd("open", 1, device) is called; this never
returns. Inside prom_cmd, there is the following bit of code:
__asm__ __volatile__ ("\t"
"mov %1, %%g1\n\t"
"mov %2, %%g2\n\t"
"save %0, -0xc0, %%sp\n\t"
"rdpr %%pstate, %%l1\n\t"
"andn %%l1, 8, %%l1\n\t"
"wrpr %%l1, 0, %%pstate\n\t"
"call %%g1\n\t"
" mov %%g2, %%o0\n\t"
"wrpr %%l1, 8, %%pstate\n\t"
"restore\n"
: : "r" (prom_cif_stack), "r" (prom_cif_handler),
"r" (p1275_args) :
"o0", "o1", "o2", "o3", "o4", "o5", "o7", "g1", "g2", "g3",
"g4",
"g5", "g6", "g7");
This ends up being compiled into:
sethi %hi(prom_cif_stack), %g1
.LL21:
ld [%l3+%lo(prom_cif_handler)], %l2
ld [%g1+%lo(prom_cif_stack)], %l1
sethi %hi(p1275_args), %l0
or %l0, %lo(p1275_args), %l0
mov %l2, %g1
mov %l0, %g2
save %l1, -0xc0, %sp
rdpr %pstate, %l1
andn %l1, 8, %l1
wrpr %l1, 0, %pstate
call %g1
mov %g2, %o0
wrpr %l1, 8, %pstate
restore
Step by step:
sethi %hi(prom_cif_stack), %g1
.LL21:
ld [%l3+%lo(prom_cif_handler)], %l2
ld [%g1+%lo(prom_cif_stack)], %l1
sethi %hi(p1275_args), %l0
or %l0, %lo(p1275_args), %l0
Load prom_cif_handler into %l2, prom_cif_stack into %l1, and p1275_args
into %l0. prom_cif_handler and prom_cif_stack come from the
environment; when second.b is loaded, they arg fetched from the %o4 and
%o6 registers.
mov %l2, %g1
mov %l0, %g2
Move prom_cif_handler into %g1, and p1275_args into %g2.
save %l1, -0xc0, %sp
This one is weird, if I'm understanding it correctly; move
prom_cif_stack on the stack pointer, after allocating 192 bytes for it.
Save also zeros out local registers, and shifts input and output regs
(window stuff).
rdpr %pstate, %l1
andn %l1, 8, %l1
Grab the processor state, saving the Address Mask bit, store it in %l1.
This controls whether the high order 32 bits in instructions and data
addresses are masked to 0 (for running in 32bit stuff).
wrpr %l1, 0, %pstate
I'm not sure whether this is zeroing out %pstate (enabling 64bit mode),
or whether it's just disabling other %pstate bits (disabling interrupts
and enabling traps).
call %g1
Call prom_cif_handler().
mov %g2, %o0
I'm not sure if %g2 is still p1275_args, or if prom_cif_handler
clobbered it; whatever the case may be, write that out to an output
register.
wrpr %l1, 8, %pstate
Restore %pstate to its prior value.
restore
Shift the window again.
This bit of code is the culprit; specifically, I believe it's either the
call the prom_cif_handler, or something in prom_cif_handler. Looking at
what happens during a run:
In open() of second (line 89) (prom_cif_handler: 4026903552).
(note: this is 0xf005ac00)
dis
fff64280 illtrap
fff64284 ld [%g5 + %o4], %i0
fff64288 ??? [%i7 - a] %asi, %f62
fff6428c illtrap
fff64290 illtrap
fff64294 illtrap
fff64298 illtrap
fff6429c illtrap
fff642a0 ??? [%i7 - 1] %asi, %f62
fff642a4 ??? [%i7 - 1] %asi, %f62
fff642a8 illtrap
fff642ac illtrap
fff642b0 illtrap
fff642b4 casxa [%l1] ae, %g1, %i7
fff642b8 illtrap
fff642bc ld [%o7 + %l0], %i0
fff642c0 illtrap
fff642c4 illtrap
fff642c8 illtrap
fff642cc ldf [%g1], %f31
fff642d0 illtrap
fff642d4 illtrap
fff642d8 illtrap
fff642dc illtrap
fff642e0 illtrap
fff642e4 illtrap
fff642e8 illtrap
fff642ec illtrap
fff642f0 illtrap
fff642f4 illtrap
fff642f8 illtrap
fff642fc illtrap
fff64300 illtrap
fff64304 illtrap
fff64308 illtrap
fff6430c illtrap
fff64310 illtrap
fff64314 illtrap
fff64318 illtrap
fff6431c illtrap
fff64320 illtrap
fff64324 illtrap
fff64328 illtrap
fff6432c illtrap
fff64330 illtrap
fff64334 casxa [%l1] b4, %g1, %i7
fff64338 illtrap
fff6433c illtrap
fff64340 illtrap
fff64344 illtrap
fff64348 illtrap
fff6434c illtrap
fff64350 illtrap
fff64354 illtrap
fff64358 illtrap
fff6435c illtrap
fff64360 illtrap
fff64364 illtrap
fff64368 illtrap
fff6436c illtrap
fff64370 illtrap
fff64374 illtrap
fff64378 illtrap
fff6437c illtrap
fff64380 illtrap
fff64384 illtrap
fff64388 illtrap
fff6438c illtrap
fff64390 illtrap
fff64394 ld [%o3 + %i4], %i0
fff64398 illtrap
fff6439c illtrap
fff643a0 illtrap
fff643a4 illtrap
fff643a8 illtrap
fff643ac illtrap
fff643b0 illtrap
fff643b4 illtrap
fff643b8 illtrap
fff643bc illtrap
fff643c0 illtrap
fff643c4 illtrap
fff643c8 illtrap
fff643cc casxa [%l1] ba, %g1, %i7
fff643d0 illtrap
fff643d4 ld [%l6 + c00], %i0
fff643d8 illtrap
fff643dc illtrap
fff643e0 illtrap
fff643e4 illtrap
fff643e8 illtrap
fff643ec illtrap
fff643f0 illtrap
fff643f4 illtrap
fff643f8 illtrap
fff643fc illtrap
fff64400 illtrap
fff64404 illtrap
fff64408 illtrap
fff6440c illtrap
fff64410 illtrap
fff64414 illtrap
fff64418 illtrap
fff6441c illtrap
fff64420 illtrap
fff64424 illtrap
fff64428 illtrap
fff6442c illtrap
fff64430 illtrap
fff64434 illtrap
fff64438 illtrap
fff6443c illtrap
fff64440 illtrap
fff64444 illtrap
fff64448 illtrap
fff6444c illtrap
fff64450 illtrap
fff64454 illtrap
fff64458 illtrap
fff6445c illtrap
fff64460 illtrap
fff64464 illtrap
fff64468 illtrap
fff6446c illtrap
fff64470 illtrap
fff64474 illtrap
fff64478 illtrap
fff6447c illtrap
fff64480 illtrap
fff64484 illtrap
fff64488 illtrap
fff6448c illtrap
fff64490 illtrap
fff64494 illtrap
fff64498 illtrap
fff6449c illtrap
fff644a0 illtrap
fff644a4 illtrap
fff644a8 illtrap
fff644ac illtrap
fff644b0 illtrap
fff644b4 illtrap
fff644b8 illtrap
fff644bc illtrap
fff644c0 illtrap
fff644c4 illtrap
fff644c8 call fff644c4
fff644cc ??? [%i7 - 8] %asi, %f62
Stack Underflow
{0} ok WARNING: There is a TBD problem with ps2.
.window
Window number too large. The maximum number is 6
INs LOCALs OUTs
0: 380000 3a71a0 0
1: 3a71a0 1e 0
2: 0 0 0
3: 100000 16e0008 0
4: 0 180008 f005ac00
5: 0 140008 0
6: 0 140008 fff45741
7: 0 109d8 10800
Stack Underflow
.registers
Normal Alternate MMU Vector
0: 0 0 0 0
1: f005ac00 1 fff646c0 0
2: f0000000 f0050850 f0000000 1000
3: fff78000 fff78000 6 6e03c0
4: fffffffffffffff8 0 6 30
5: f003d8f0 fff72ab0WARNING: There is a TBD problem
with ps2.
de000000000f 0
6: fff66540 1606 fff78000 6ebf80
7: fff657a8 4e 4048 0
%PC f0009038 %nPC f000903c
%TBA f0000000 %CCR 0 XCC:nzvc ICC:nzvc
Here you can see that prom_cif_handler (0xf005ac00) is in %o4 in the
current window, as well as %g1. So, the code got at least as far as
'mov %l2, %g1'.
{0} ok ctrace
PC: f0009038
Last leaf: call f000808c from f003d230
0 w %o0-%o7: (f00150cc fffffff600000000 0 4 ffffffffffffffff a
fff455c1 f)jmpl f005ac00 from 382610
1 w %o0-%o7: (3a1ad0 0 a 0 3a5000 2 fff45681 382610 )
call 3821a0 from 3823a8
2 w %o0-%o7: (10 37fc6c f002d8bc 0 3a5000 4 37fba8 3823a8 )
call 38248c from 38772c
3 w %o0-%o7: (397d80 0 3a5630 0 3a5000 1 37fc18 38772c )
call 387904 from 3861a4
4 w %o0-%o7: (3a5630 397690 421 20 3a5000 3 37fcd8 3861a4 )
call 381bc8 from 3802c8
5 w %o0-%o7: (398e30 f005ac00 596530 0 0 3a5000 37ff88 3802c8 )
call 10958 from 10800
6 w %o0-%o7: (0 0 0 0 f005ac00 0 fff45741 10800 )
{0} ok dis 382610
fff64000 illtrap
fff64004 ld [%g2 + %i0], %i0
fff64008 illtrap
fff6400c ld [%l1 + %g4], %i0
fff64010 ??? [%i7 - 1] %asi, %f62
fff64014 ??? [%i7 - 4] %asi, %f62
fff64018 ??? [%i7 - 1] %asi, %f62
fff6401c ??? [%i7 - 4] %asi, %f62
fff64020 ??? [%i7 - 1] %asi, %f62
fff64024 ??? [%i7 - 4] %asi, %f62
fff64028 illtrap
fff6402c ld [%g2 + %i4], %i0
fff64030 illtrap
fff64034 ld [%l1 + %o0], %i0
fff64038WARNING: There is a TBD problem with ps2.
??? [%i7 - 1] %asi, %f62
fff6403c ??? [%i7 - 4] %asi, %f62
fff64040 ??? [%i7 - 1] %asi, %f62
fff64044 ??? [%i7 - 4] %asi, %f62
fff64048 ??? [%i7 - 1] %asi, %f62
fff6404c ??? [%i7 - 4] %asi, %f62
fff64050 illtrap
fff64054 illtrap
fff64058 illtrap
fff6405c illtrap
fff64060 illtrap
fff64064 illtrap
fff64068 illtrap
fff6406c illtrap
fff64070 illtrap
fff64074 illtrap
fff64078 illtrap
fff6407c illtrap
fff64080 illtrap
fff64084 call 16006909c
fff64088 illtrap
{0} ok dis f005ac00
382610 jmp %g1, %g0, %o7
382614 or %g0, %g2, %o0
{0} ok WARNING: There is a TBD problem with ps2.
dis f0009038
f005ac00 save %o6, ffffffffffffff40, %o6
f005ac04 call f002877c
f005ac08 sethi 0, %g0
The backtrace shows 'jmpl f005ac00', which leads me to believe the
'call %g1' succeeded, and the MMU Miss happens somewhere in that
callback function. Unfortunately, I have no idea where that function
actually ends up. 'dis f0009038' shows f005ac00, doing a save to an
output register w/ a rather large, ugly looking value.
At this point, I'd really love to know where prom_cif_handler is
implemented, or how it works. Looks like I'm not the only one:
http://www.sparc-boot.org/pipermail/silo-general/2005-January/000033.html
--
Andres Salomon <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
