On 29/12/13 14:12, Artyom Tarasenko wrote:
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
Ah this is because of a bug in Solaris whereby it requests too many parameters to be returned with respect to the CIF method that is being called. The fix is for OpenBIOS to not allow the client to POP() more items from the stack than were there before the CIF call, for which I have a local patch whilst I wait for the QEMU guys to update their git repository from our SVN.
Please try the attached and let me know if you manage to get any further.
ATB,
Mark.
Ah this is because of a bug in Solaris whereby it requests too many parameters to be returned with respect to the CIF method that is being called. The fix is for OpenBIOS to not allow the client to POP() more items from the stack than were there before the CIF call, for which I have a local patch whilst I wait for the QEMU guys to update their git repository from our SVN.
Please try the attached and let me know if you manage to get any further.
I tried the attached patch and the boot doesn't get any further for me (Solaris 9 64-bit). I've attached the output with DEBUG_CIF defined - it's quite verbose. I'm also not booting kadb at present, so it doesn't match Artyom's output exactly.
-Nick
-------- This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.
On 30/12/13 21:11, Nick Couchman wrote:
Ah this is because of a bug in Solaris whereby it requests too many parameters to be returned with respect to the CIF method that is being called. The fix is for OpenBIOS to not allow the client to POP() more items from the stack than were there before the CIF call, for which I have a local patch whilst I wait for the QEMU guys to update their git repository from our SVN.
Please try the attached and let me know if you manage to get any further.
I tried the attached patch and the boot doesn't get any further for me (Solaris 9 64-bit). I've attached the output with DEBUG_CIF defined - it's quite verbose. I'm also not booting kadb at present, so it doesn't match Artyom's output exactly.
Thanks for this Nick.
I think I'm getting to roughly the same place here, so the problem is likely related to the various memory properties. One thing it does show is that my argument patch has an off-by-one error somewhere as most of those argument warnings should not be appearing...
ATB,
Mark.
-
Mark Cave-Ayland -
Nick Couchman