[Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Jakub Jermar]

Hi,

when I build qemu-system-sparc64 from trunk and attempt to
boot the HelenOS iso image, I immediately get segmentation fault.
Below is the output from a gdb session, show the place of
crash:

OpenBIOS for Sparc64

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b616b0 (LWP 16553)]
change_pstate (new_pstate=21) at /home/jermar/install/qemu/target-sparc/op_helper.c:2676
2676        pstate_regs = env->pstate & 0xc01;
(gdb) bt
#0  change_pstate (new_pstate=21) at /home/jermar/install/qemu/target-sparc/op_helper.c:2676
#1  0x0814d3b4 in do_interrupt (env=0x83d9bc8) at /home/jermar/install/qemu/target-sparc/helper.c:758
#2  0x080d6510 in cpu_sparc_exec (env1=0x0) at /home/jermar/install/qemu/cpu-exec.c:320
#3  0x08055cca in main_loop () at /home/jermar/install/qemu/vl.c:7545
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
2676        pstate_regs = env->pstate & 0xc01;
(gdb) print env
$1 = (struct CPUSPARCState *) 0xbfdb97c8
(gdb) print env->pstate
Cannot access memory at address 0xbfdc717c

Since I get this error so early, I think this is a generic issue.
Anyone else has seen something similar?

I built qemu using gcc-3.3. The arguments I used to run qemu:
-cdrom image.iso -m 512 -boot d -nographic

Please, respond to me directly as I am not subscribed to the list.

Cheers,
Jakub

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

On 8/28/08, Jakub Jermar <jakub@jermar.eu> wrote:
> Hi,
>
>  when I build qemu-system-sparc64 from trunk and attempt to
>  boot the HelenOS iso image, I immediately get segmentation fault.
>  Below is the output from a gdb session, show the place of
>  crash:
>
>  OpenBIOS for Sparc64
>
>  Program received signal SIGSEGV, Segmentation fault.
>  [Switching to Thread 0xb7b616b0 (LWP 16553)]
>  change_pstate (new_pstate=21) at /home/jermar/install/qemu/target-sparc/op_helper.c:2676
>  2676        pstate_regs = env->pstate & 0xc01;
>  (gdb) bt
>  #0  change_pstate (new_pstate=21) at /home/jermar/install/qemu/target-sparc/op_helper.c:2676
>  #1  0x0814d3b4 in do_interrupt (env=0x83d9bc8) at /home/jermar/install/qemu/target-sparc/helper.c:758
>  #2  0x080d6510 in cpu_sparc_exec (env1=0x0) at /home/jermar/install/qemu/cpu-exec.c:320
>  #3  0x08055cca in main_loop () at /home/jermar/install/qemu/vl.c:7545
>  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>  2676        pstate_regs = env->pstate & 0xc01;
>  (gdb) print env
>  $1 = (struct CPUSPARCState *) 0xbfdb97c8
>  (gdb) print env->pstate
>  Cannot access memory at address 0xbfdc717c
>
>  Since I get this error so early, I think this is a generic issue.
>  Anyone else has seen something similar?
>
>  I built qemu using gcc-3.3. The arguments I used to run qemu:
>  -cdrom image.iso -m 512 -boot d -nographic
>
>  Please, respond to me directly as I am not subscribed to the list.

What host? On my amd64 and using the latest OpenBIOS I get this:

boot:
Allocated 8 Megs of memory at 0x40000000 for kernel
Kernel doesn't support loading to high memory, relocating...done.
Loaded kernel version 0.0.0
service close: argument count error (0 0)
HelenOS SPARC64 Bootloader
Release 0.2.0.5, revision exported
Built on 2007-06-18 23:55:43
Copyright (c) 2006 HelenOS project

System info
 memory: 512M starting at 0x0000000000000000

Memory statistics
 kernel entry point at 0x0000000000400000
 0x0000000000008e78: boot info structure
 0x00000000000092cc: kernel image (size 459416 bytes)
 0x0000000000079564: ns image (size 221421 bytes)
 0x00000000000af651: init image (size 221340 bytes)
 0x00000000000e56ed: fb image (size 239587 bytes)
 0x000000000011fed0: kbd image (size 254904 bytes)
 0x000000000015e288: console image (size 404892 bytes)
 0x00000000001c1024: tetris image (size 239492 bytes)
 0x00000000001fb7a8: tester image (size 238840 bytes)
 0x0000000000235ca0: klog image (size 204910 bytes)

Copying components
 kernel...done.
 ns...done.
 init...done.
 fb...done.
 kbd...done.
 console...done.
 tetris...done.
 tester...done.
 klog...done.

Canonizing OpenFirmware device tree...done.

Checking for secondary processors...done.

Booting the kernel...

Using the version in pc-bios it does not get this far, but does not
crash either:
boot:
Allocated 8 Megs of memory at 0x40000000 for kernel
Kernel doesn't support loading to high memory, relocating...done.
Loaded kernel version 0.0.0
service close: argument count error (0 0)
HelenOS SPARC64 Bootloader
Release 0.2.0.5, revision exported
Built on 2007-06-18 23:55:43
Copyright (c) 2006 HelenOS project
Error: no memory detected, halting.

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Jakub Jermar]

Blue Swirl wrote:
<snip>
> What host? On my amd64 and using the latest OpenBIOS I get this:

Oops, the host is ia32 and the OpenBIOS is the one from qemu's current
trunk. I will try it on amd64 shortly.

Btw, couldn't you update the openbios version in qemu? It will allow me
to make sure that HelenOS on qemu/sparc64 makes it to the point where
it probes the framebuffer and eventually write a small driver for it.

Thanks,
Jakub

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

On 8/28/08, Jakub Jermar <jakub@jermar.eu> wrote:
> Blue Swirl wrote:
>  <snip>
>
> > What host? On my amd64 and using the latest OpenBIOS I get this:
> >
>
>  Oops, the host is ia32 and the OpenBIOS is the one from qemu's current
>  trunk. I will try it on amd64 shortly.

It should work on i386 too. It just seems that some bugs on i386 can't
be reproduced on amd64 32-bit chroot.

>  Btw, couldn't you update the openbios version in qemu? It will allow me
>  to make sure that HelenOS on qemu/sparc64 makes it to the point where
>  it probes the framebuffer and eventually write a small driver for it.

Well, if the firmware configuration device is committed, I'll update
OpenBIOS to the new system and then probably update the image.

I wouldn't trust the Qemu version of VGA on Sparc64 yet, there could
be some wrong assumptions. Once a real kernel can boot, initialize the
VGA and preferably start X, then we should know that it's realistic.

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Jakub Jermar]

Blue Swirl wrote:
>>> What host? On my amd64 and using the latest OpenBIOS I get this:

It works on amd64 for me too, so it's an ia32 issue.
If I sent you an ia32 coredump, would that be of any help to you?

> I wouldn't trust the Qemu version of VGA on Sparc64 yet, there could
> be some wrong assumptions. Once a real kernel can boot, initialize the
> VGA and preferably start X, then we should know that it's realistic.

That would imply that the HelenOS kernel is somewhat unreal, which
is not easily possible since it can drive real UltraSPARC machines :-)
(And yes, on a real machine, it doesn't end with the "Booting the
kernel..." message).

A simple unaccelerated framebuffer support is not a big deal, all we
need is an address, width, height and color depth and maybe a heads
up if the device is weird (such as the Creator 3D).

Cheers,
Jakub

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

On 8/28/08, Jakub Jermar <jakub@jermar.eu> wrote:
> Blue Swirl wrote:
>
> >
> > >
> > > > What host? On my amd64 and using the latest OpenBIOS I get this:
> > > >
> > >
> >
>
>  It works on amd64 for me too, so it's an ia32 issue.
>  If I sent you an ia32 coredump, would that be of any help to you?

No thanks, I can no reproduce it. Maybe the reason can be found with bisection.

> > I wouldn't trust the Qemu version of VGA on Sparc64 yet, there could
> > be some wrong assumptions. Once a real kernel can boot, initialize the
> > VGA and preferably start X, then we should know that it's realistic.
> >
>
>  That would imply that the HelenOS kernel is somewhat unreal, which
>  is not easily possible since it can drive real UltraSPARC machines :-)
>  (And yes, on a real machine, it doesn't end with the "Booting the
>  kernel..." message).

I just meant that you should not use Qemu as reference. If your VGA
code runs unmodified in Qemu, it's a sign that we could trust
Qemu/Sparc64 VGA coupling.

>  A simple unaccelerated framebuffer support is not a big deal, all we
>  need is an address, width, height and color depth and maybe a heads
>  up if the device is weird (such as the Creator 3D).

The current Sun4u machine uses only PC devices. It's of course
possible to add other devices, but I'd rather do later, after for
example working PCI or even interrupt controller.

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

On 8/28/08, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 8/28/08, Jakub Jermar <jakub@jermar.eu> wrote:
>
> > Blue Swirl wrote:
>  >
>  > >
>  > > >
>  > > > > What host? On my amd64 and using the latest OpenBIOS I get this:
>  > > > >
>  > > >
>  > >
>  >
>  >  It works on amd64 for me too, so it's an ia32 issue.
>  >  If I sent you an ia32 coredump, would that be of any help to you?
>
>
> No thanks, I can no reproduce it. Maybe the reason can be found with bisection.

f2bc7e7fa175b61a20c6f10c324d7c4d68af676f is first bad commit
commit f2bc7e7fa175b61a20c6f10c324d7c4d68af676f
Author: blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
Date:   Tue May 27 17:35:30 2008 +0000

    Move non-op functions from op_helper.c to helper.c and vice versa.
    Rearrange interrupt handling to match other targets.


    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@4590
c046a42c-6fe2-441c-8c8c-71466251a162

:100644 100644 65af9a6d879e922ad0e90bd110f087ac81032bcf
5e64fa43cae3b7fc12507621351cd4d0b82cb4b0 M      cpu-exec.c
:040000 040000 f519a87338e29fd5d3a642698fd4dd405bf19024
adfd50c255dccdee1098c3131cca5c20453d19f9 M      target-sparc

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On 8/28/08, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 8/28/08, Blue Swirl <blauwirbel@gmail.com> wrote:
>  > On 8/28/08, Jakub Jermar <jakub@jermar.eu> wrote:
>  >
>  > > Blue Swirl wrote:
>  >  >
>  >  > >
>  >  > > >
>  >  > > > > What host? On my amd64 and using the latest OpenBIOS I get this:
>  >  > > > >
>  >  > > >
>  >  > >
>  >  >
>  >  >  It works on amd64 for me too, so it's an ia32 issue.
>  >  >  If I sent you an ia32 coredump, would that be of any help to you?
>  >
>  >
>  > No thanks, I can no reproduce it. Maybe the reason can be found with bisection.
>
>
> f2bc7e7fa175b61a20c6f10c324d7c4d68af676f is first bad commit
>  commit f2bc7e7fa175b61a20c6f10c324d7c4d68af676f
>  Author: blueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>
>  Date:   Tue May 27 17:35:30 2008 +0000
>
>     Move non-op functions from op_helper.c to helper.c and vice versa.
>     Rearrange interrupt handling to match other targets.
>
>
>     git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@4590
>  c046a42c-6fe2-441c-8c8c-71466251a162
>
>  :100644 100644 65af9a6d879e922ad0e90bd110f087ac81032bcf
>  5e64fa43cae3b7fc12507621351cd4d0b82cb4b0 M      cpu-exec.c
>  :040000 040000 f519a87338e29fd5d3a642698fd4dd405bf19024
>  adfd50c255dccdee1098c3131cca5c20453d19f9 M      target-sparc

Surprisingly it was moving of do_interrupt to helper.c that caused the
bug. Moving it back to op_helper.c allows Sparc64 to boot. I'm still
trying to understand the real cause of the bug and to find if there is
some other way of fixing this. This kind of voodoo makes me nervous.

[-- Attachment #2: fix_sparc64_on_i386.diff --]
[-- Type: plain/text, Size: 15817 bytes --]

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Paul Brook]

> Surprisingly it was moving of do_interrupt to helper.c that caused the
> bug. Moving it back to op_helper.c allows Sparc64 to boot. I'm still
> trying to understand the real cause of the bug and to find if there is
> some other way of fixing this. This kind of voodoo makes me nervous.

do_interrupt calls change_pstate, which relies on global register state.  
Global register state is only valid when called directly from translated code 
or other code that includes exec.h.

You should never call code in op_helper.c from outside that file (or 
cpu-exec.h). The easy way to enforce this is to put teh declarations for 
functions defined in op_helper.h in exec.h, not helper.h or cpu.h. Failure to 
follow this rule results in bugs like the one you've encountered.

helper.h is included multiple times, so should really just contain DEF_HELPER 
statements.

Paul

Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed

[Blue Swirl]

On 8/29/08, Paul Brook <paul@codesourcery.com> wrote:
> > Surprisingly it was moving of do_interrupt to helper.c that caused the
>  > bug. Moving it back to op_helper.c allows Sparc64 to boot. I'm still
>  > trying to understand the real cause of the bug and to find if there is
>  > some other way of fixing this. This kind of voodoo makes me nervous.
>
>
> do_interrupt calls change_pstate, which relies on global register state.
>  Global register state is only valid when called directly from translated code
>  or other code that includes exec.h.
>
>  You should never call code in op_helper.c from outside that file (or
>  cpu-exec.h). The easy way to enforce this is to put teh declarations for
>  functions defined in op_helper.h in exec.h, not helper.h or cpu.h. Failure to
>  follow this rule results in bugs like the one you've encountered.
>
>  helper.h is included multiple times, so should really just contain DEF_HELPER
>  statements.

Thanks, great advice. I'll check all exported functions.