On Sun, Dec 29, 2013 at 12:10 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 29/12/13 05:01, Nick Couchman wrote:
I see the "VAC too big!" error on my local copy of 32-bit Solaris 9 too. Some searching showed the message occurs in the OpenSolaris source at
http://fxr.watson.org/fxr/source/sfmmu/vm/hat_sfmmu.c?v=OPENSOLARIS#L1347.
I'm not exactly sure what this is trying to check here, but I do know that OpenBIOS uses 512K PTEs to map itself, while calls to OFMEM use 8K PTEs which may be relevant. Does anyone know the exact significance of this?
Hmmm...I do not recall seeing that VAC too big error on Solaris 9 32-bit (on 32-bit Qemu/OpenBIOS), but if you're seeing it and Solaris 9 boots fine for you, then perhaps that's a Red Herring and not worth running down. Maybe I'll focus on trying to track down the source of some of the other error messages that seem to contribute to not being able to boot 64-bit Solaris - particularly Solaris 10 and higher, since I think that's where the CPU Power Management starts, which would be great to get working for the CPU performance aspect of running Qemu.
-Nick
Gah. Sorry Nick - this message was definitely a case of "fingers before brain. What I meant to say was that I see the "VAC too big!" error on my local copy of *64-bit* Solaris 9 too. I currently don't have access to a Solaris 9 32-bit image for testing, but it sounds as if it is working fine for you which is great.
Actually "VAC too big" is a pretty nice error: it should happen in the early sfmmu initialization phase, but for some reason I never get it. I tried to make the boot process more verbose, but for this I'd need a working kadb. Maybe it's easy to make it working? With CIF_DEBUG booting kadb looks like this:
Jumping to entry point 0000000000100000 for type 0000000000000001... switching to new context: entry point 0x100000 stack 0x00000000ffe86a01 finddevice("/chosen") = 0x00000000ffe1bed0 getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004 getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004 getprop(0x00000000ffe1bed0, "mmu", 0x000000000013e02c, 4) = service getprop: possible argument error (0 1)
^^^ The message about possible argument error keeps appearing on every call after this point. [...]
getprop(0x00000000ffe30940, "clock-frequency", 0x0000000000138608, 4) = service getprop: possible argument error (0 1) 3990516880 0x00138608 05 f5 e1 00 __ __ __ __ __ __ __ __ __ __ __ __ .��. getproplen(0x00000000ffe30940, "status") = 0xffffffffffffffff
^^^ are we missing "status" property?
child(0x00000000ffe30940) = 0x0000000000000000 peer(0x00000000ffe30940) = 0x0000000000000000 peer(0x00000000ffe1b838) = 0x0000000000000000 of_client_interface: interpret 00000000eddac894 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 interpret : kadb_callback %pc dup f000.0000 ffff.ffff between if drop exit then h# eddda630 x! %npc h# eddb0758 x! %g1 h# eddda6d0 x! %g2 h# eddda6d8 x! %g3 h# eddda6e0 x! %g4 h# eddda720 x! %g5 h# eddda728 x! %g6 h# eddda730 x! %g7 h# eddda738 x! 1 %tstate h# eddaf070 x! 1 %tt h# eddd9e48 l! h# edd008ec set-pc go ; ([6] -- [0]) %pc:interpret: exception -13 caught
^^^ I guess things go wrong after this point.
interpret ': kadb_callback %pc dup f000.0000 ffff.ffff between if drop exit then h# eddda630 x! %npc h# eddb0758 x! %g1 h# eddda6d0 x! %g2 h# eddda6d8 x! %g3 h# eddda6e0 x! %g4 h# eddda720 x! %g5 h# eddda728 x! %g6 h# eddda730 x! %g7 h# eddda738 x! 1 %tstate h# eddaf070 x! 1 %tt h# eddd9e48 l! h# edd008ec set-pc go ; ': possible argument error (4--0) got 0 handle_calls return: of_client_interface: interpret 00000000edd28010 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 interpret ['] kadb_callback init-debugger-hook ([6] -- [0]) kadb_callback:interpret: exception -13 caught interpret ' ['] kadb_callback init-debugger-hook ': possible argument error (4--0) got 0
And then kadb prompt appears but it can't start executing the kernel:
kadb[0]: :c of_client_interface: call-method 00000000eddac6e0 00000000ffc847f0 0000000001006000 call-method translate ([3] -- [5]) handle_calls return: 0000000000000000 ffffffffffffffff 0000000000000032 0000000000000000 000000001f806000 of_client_interface: call-method 00000000eddac668 00000000ffc847f0 0000000000000033 0000000000002000 00000000ffc7e000 0000000000000000 000000001f806000 call-method map ([7] -- [1]) handle_calls return: 0000000000000000 of_client_interface: call-method 00000000eddac6c8 00000000ffc847f0 0000000000002000 00000000ffc7e000 call-method unmap ([4] -- [0]) call-method 'unmap': possible argument error (2--0) got 0 handle_calls return: Unhandled Exception 0x000000000000017e PC = 0x0000000001006f90 NPC = 0x0000000001006f94 Stopping execution
Artyom