[OpenBIOS] Solaris anyone? Solaris 9 04/04

[Mark Cave-Ayland]

On 10/09/11 23:23, Nathan Kunkee wrote:

> Tweaking that a little, I now find myself at pc=0xf01850c8, because that
> is the current instruction when the page tables write out.
>
> (qemu) info cpus
> * CPU #0: pc=0xf01850c8 npc=0xf01850cc thread_id=3483
> (qemu) info registers
> pc: f01850c8 npc: f01850cc
> General Registers:
> %g0-7: 00000000 f024dc00 00000003 f5a6b104 00000004 fbf45b80 f0041000
> f5dd0500
>
> Current Register Window:
> %o0-7: 00000000 f026a2d8 f5901000 f5901200 f026a2dc f018505c f026a270
> f005c5a4
> %l0-7: 04001fc5 f00436ac 000003a6 00000020 00000000 00000009 00000000
> 00000001
> %i0-7: f026a6c0 f026a40c f5901000 000003a6 00000002 f026a384 f026a2e8
> f005cefc
>
> Floating Point Registers:
> %f00: 000000000.000000 000000000.000000 -NaN -NaN
> %f04: -NaN -NaN -NaN -NaN
> ....
> %f28: -NaN -NaN -NaN -NaN
> psr: 04401fe5 (icc: -Z-- SPE: SPE) wim: 00000002
> fsr: 00080000 y: 00000000
> (qemu) x /30i 0xf01850a0
> 0xf01850a0: and %o0, 3, %o3
> 0xf01850a4: cmp %o3, 2
> 0xf01850a8: bne 0xf01850c0
> 0xf01850ac: srl %o2, 0xc, %o3
> 0xf01850b0: and %o3, 0x3f, %o3
> 0xf01850b4: sll %o3, 8, %o3
> 0xf01850b8: b 0xf01850c8
> 0xf01850bc: add %o0, %o3, %o0
> 0xf01850c0: mov %o2, %o3
> 0xf01850c4: lda [ %o3 ] #ASI_M_FLUSH_PROBE, %o0
> 0xf01850c8: srl %o0, 0x18, %o3
> 0xf01850cc: andcc %o3, 7, %o3
> 0xf01850d0: be 0xf01850dc
> 0xf01850d4: nop
> 0xf01850d8: sta %g0, [ %o2 ] #ASI_M_FLUSH_PROBE
> 0xf01850dc: mov 0x300, %o2
> 0xf01850e0: cmp %o1, 0
> 0xf01850e4: be 0xf01850f0
> 0xf01850e8: lda [ %o2 ] #ASI_M_MMUREGS, %o2
> 0xf01850ec: st %o2, [ %o1 ]
> 0xf01850f0: retl
> 0xf01850f4: nop
> 0xf01850f8: sethi %hi(0x10003000), %o2
> 0xf01850fc: or %o2, 0x18, %o2 ! 0x10003018
> 0xf0185100: retl
> 0xf0185104: lda [ %o2 ] #ASI_M_BYPASS, %o0
> 0xf0185108: unimp 0
> 0xf018510c: unimp 0
> 0xf0185110: unimp 0
> 0xf0185114: unimp 0
>
> Now I know reading fragments of assembly are lots of fun, so I've
> attached the dump_mmu results, which will hopefully also be useful.
>
> Does that help point to a next step?

Hi Nathan,

 From previous experience with Solaris 8, I think that you may be on a 
red herring with your 0xf0.. address being the cause. I expect you'll 
find that this is some kind of error/panic handler within the main 
Solaris kernel.

The way to find out is make sure that you have a cross-SPARC gdb to hand 
and then invoke QEMU with the -s (gdbstub) option and connect into the 
SPARC virtual using gdb's target command as per the documentation. You 
can then use add-symbol-file to load the Solaris ELF kernel executable 
into gdb and continue execution. Then at the point where it hangs, you 
can issue a CTRL-C in the gdb window followed by "bt" to get a backtrace 
to confirm my panic handler suspicion.

Looking at the address spaces, my guess is that the memory region around 
0xf59... is reserved for loading dynamic modules into the kernel. 
Possibly I would try and use objdump of the binaries on the CDROM to 
locate some kind of module magic containing the module name. You should 
then be able to use GDB (or perhaps even the QEMU monitor as you have 
done) to work backwards in memory to locate the magic, and hence 
determine which module is causing the error.


HTH,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs