Re: [Qemu-devel] Leon3 is broken since 6281f7d11

[Artyom Tarasenko <atar4qemu@gmail.com>]

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

On Wed, Jan 25, 2012 at 12:06 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> Leon3 machine is broken in the current git master.
>
>  Bisect shows the following:
>
> 6281f7d11fa6bfb6da3926359fbe70684e582cb1 is the first bad commit
> commit 6281f7d11fa6bfb6da3926359fbe70684e582cb1
> Author: Avi Kivity <avi@redhat.com>
> Date:   Mon Nov 14 13:10:13 2011 +0200
>
>    grlib_apbuart: convert to memory API
>
>    Signed-off-by: Avi Kivity <avi@redhat.com>
>
>
>
> I've asked the author's permission to publish the test program. Until
> he responds here is some preliminary analysis. Before the memory API
> running the test program (with unassigned access debugging turned on)
> looked like this:
> $ sparc-softmmu/qemu-system-sparc -M leon3_generic -kernel ravenscar-test
>
> Unassigned mem read access of 4 bytes to 0000000000000108 from 400080d0
> Unassigned mem write access of 1 byte to 0000000040032af5 asi 0x01 from 40003c4c
> Unassigned mem read access of 2 bytes to 0000000000000212 from 40006ca8
> ...
>
> Currently it looks like this:
> $ sparc-softmmu/qemu-system-sparc -M leon3_generic -kernel ravenscar-test
>
> Unassigned mem write access of 1 byte to 0000000040032af5 asi 0x01 from
> <hang>
>
> It looks that qemu produces less 'unassigned mem read accesses' than before.
>
> Unfortunately, there seems to be another bug in the logging, because I
> don't see what could have triggered the unassigned access at 400080d0,
> but there is a good candidate at 400080d8 though:
>
> IN: system__bb__peripherals__initialize_uart
> 0x400080d0:  sethi  %hi(0x80000000), %g1
> 0x400080d4:  or  %g1, 0x108, %g1        ! 0x80000108
> 0x400080d8:  ld  [ %g1 ], %g1
> 0x400080dc:  btst  1, %g1
> 0x400080e0:  bne  0x400081a4
> 0x400080e4:  btst  2, %g1

Thanks to Fabien Chouteau, now we have a test case which even can be
used for automated tests.
It's slighlty different from the above, so the addresses are different.
The binary is crible/main in the attached archive (the source is in Ada).

Before the memory api conversion commit the program produces output
and shuts qemu down,  after the commit
6281f7d11fa6bfb6da3926359fbe70684e582cb1, it hangs.

sparc-softmmu/qemu-system-sparc -nographic -M leon3_generic -kernel crible/main

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

[-- Attachment #2: crible.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 55837 bytes --]