qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for che


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully
Date: Fri, 17 Jun 2016 14:56:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

On 17/06/16 13:57, Artyom Tarasenko wrote:

> On Fri, Jun 17, 2016 at 2:44 PM, Mark Cave-Ayland
> <address@hidden> wrote:
>> On 17/06/16 12:36, Artyom Tarasenko wrote:
>>
>>> Hi Mark,
>>>
>>> On Fri, Jun 17, 2016 at 1:27 PM, Mark Cave-Ayland
>>> <address@hidden> wrote:
>>>> On 17/06/16 07:07, David Gibson wrote:
>>>>
>>>>> On Wed, Jun 15, 2016 at 01:10:18PM +1000, David Gibson wrote:
>>>>>> On Tue, Jun 14, 2016 at 03:57:56PM +0200, Thomas Huth wrote:
>>>>>>> Since the mac99 and g3beige PowerPC machines recently broke without
>>>>>>> being noticed, it would be good to have a tester for "make check"
>>>>>>> that detects such issues immediately. A simple way to test the firmware
>>>>>>> of these machines is to use the "-prom-env" parameter of QEMU. This
>>>>>>> parameter can be used to put some Forth code into the 'boot-command'
>>>>>>> firmware variable which then can signal success to the tester by
>>>>>>> writing a magic value to a known memory location. And since some of the
>>>>>>> Sparc machines are also using OpenBIOS, they are now tested with this
>>>>>>> prom-env-tester, too.
>>>>>>>
>>>>>>> Reviewed-by: Markus Armbruster <address@hidden>
>>>>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>>>>> ---
>>>>>>>  v2: Removed unnecessary include statements (as suggested by Markus)
>>>>>>
>>>>>> Beautiful, I've applied this to ppc-for-2.7, assuming I don't get an
>>>>>> objection to taking this through my tree.
>>>>>
>>>>> Ugh.. turns out this fails on sparc64 target on a 32-bit x86 host.
>>>>> Specifically it trips the tcg_abort() at the end of tcg_reg_alloc()
>>>>> (tcg/tcg.c).
>>>>>
>>>>> I'm reasonably confident this is a pre-existing bug, just triggered by
>>>>> this test, but in the interests of getting this up and running on the
>>>>> platforms where it is working, I've disabled the testcase on sparc64
>>>>> for now.
>>>>>
>>>>> Mark, if you could debug the sparc64-on-i386 failure at some point,
>>>>> that would be helpful.
>>>>
>>>> I'm a little tied up until next week, however I was able to reproduce on
>>>> a local i386 VM and get a stack trace:
>>>>
>>>>
>>>> $ gdb --args ./qemu-system-sparc64 -nographic
>>>> GNU gdb (Debian 7.10-1.1) 7.10
>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later
>>>> <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>>> and "show warranty" for details.
>>>> This GDB was configured as "i686-linux-gnu".
>>>> Type "show configuration" for configuration details.
>>>> For bug reporting instructions, please see:
>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>> Find the GDB manual and other documentation resources online at:
>>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>> For help, type "help".
>>>> Type "apropos word" to search for commands related to "word"...
>>>> Reading symbols from ./qemu-system-sparc64...done.
>>>> (gdb) r
>>>> Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc64
>>>> -nographic
>>>> [Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
>>>> [New Thread 0xb7989b40 (LWP 27497)]
>>>> [New Thread 0xb4af1b40 (LWP 27498)]
>>>> OpenBIOS for Sparc64
>>>> Configuration device id QEMU version 1 machine id 0
>>>> kernel cmdline
>>>> CPUs: 1 x SUNW,UltraSPARC-IIi
>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>> /home/build/src/qemu/tcg/tcg.c:1743: tcg fatal error
>>>>
>>>> Program received signal SIGABRT, Aborted.
>>>> [Switching to Thread 0xb4af1b40 (LWP 27498)]
>>>> 0xb7fdadad in __kernel_vsyscall ()
>>>> (gdb) bt
>>>> #0  0xb7fdadad in __kernel_vsyscall ()
>>>> #1  0xb7a2ee26 in __GI_raise (sig=6) at
>>>> ../sysdeps/unix/sysv/linux/raise.c:55
>>>> #2  0xb7a303f7 in __GI_abort () at abort.c:89
>>>> #3  0x08061776 in tcg_reg_alloc (s=0x8637780 <tcg_ctx>,
>>>> desired_regs=255, allocated_regs=255, rev=true) at
>>>> /home/build/src/qemu/tcg/tcg.c:1743
>>>> #4  0x0806181a in temp_load (s=0x8637780 <tcg_ctx>, ts=0x8637978
>>>> <tcg_ctx+504>, desired_regs=255, allocated_regs=255) at
>>>> /home/build/src/qemu/tcg/tcg.c:1762
>>>> #5  0x080615e0 in tcg_reg_sync (s=0x8637780 <tcg_ctx>, reg=TCG_REG_EAX,
>>>> allocated_regs=255) at /home/build/src/qemu/tcg/tcg.c:1694
>>>> #6  0x08061653 in tcg_reg_free (s=0x8637780 <tcg_ctx>, reg=TCG_REG_EAX,
>>>> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1709
>>>> #7  0x08061740 in tcg_reg_alloc (s=0x8637780 <tcg_ctx>,
>>>> desired_regs=255, allocated_regs=254, rev=true) at
>>>> /home/build/src/qemu/tcg/tcg.c:1738
>>>> #8  0x0806181a in temp_load (s=0x8637780 <tcg_ctx>, ts=0x8637978
>>>> <tcg_ctx+504>, desired_regs=255, allocated_regs=254) at
>>>> /home/build/src/qemu/tcg/tcg.c:1762
>>>> #9  0x080615e0 in tcg_reg_sync (s=0x8637780 <tcg_ctx>, reg=TCG_REG_ECX,
>>>> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1694
>>>> #10 0x08061653 in tcg_reg_free (s=0x8637780 <tcg_ctx>, reg=TCG_REG_ECX,
>>>> allocated_regs=252) at /home/build/src/qemu/tcg/tcg.c:1709
>>>> #11 0x08061740 in tcg_reg_alloc (s=0x8637780 <tcg_ctx>,
>>>> desired_regs=255, allocated_regs=252, rev=true) at
>>>> /home/build/src/qemu/tcg/tcg.c:1738
>>>> #12 0x0806181a in temp_load (s=0x8637780 <tcg_ctx>, ts=0x8637978
>>>> <tcg_ctx+504>, desired_regs=255, allocated_regs=252) at
>>>> /home/build/src/qemu/tcg/tcg.c:1762
>>>> #13 0x08061858 in temp_load (s=0x8637780 <tcg_ctx>, ts=0x8637f48
>>>> <tcg_ctx+1992>, desired_regs=255, allocated_regs=252) at
>>>> /home/build/src/qemu/tcg/tcg.c:1765
>>>> #14 0x0806220f in tcg_reg_alloc_op (s=0x8637780 <tcg_ctx>, def=0x859c150
>>>> <tcg_op_defs+720>, opc=INDEX_op_sub2_i32, args=0x863be54
>>>> <tcg_ctx+18132>, dead_args=60, sync_args=0 '\000') at
>>>> /home/build/src/qemu/tcg/tcg.c:2050
>>>> #15 0x08063156 in tcg_gen_code (s=0x8637780 <tcg_ctx>, tb=0xb4b14d90) at
>>>> /home/build/src/qemu/tcg/tcg.c:2454
>>>> #16 0x08058cb4 in tb_gen_code (cpu=0x8a9e370, pc=4291901680,
>>>> cs_base=4291901684, flags=7, cflags=0) at
>>>> /home/build/src/qemu/translate-all.c:1212
>>>> #17 0x0805a8c5 in tb_find_slow (cpu=0x8a9e370, pc=4291901680,
>>>> cs_base=4291901684, flags=7) at /home/build/src/qemu/cpu-exec.c:310
>>>> #18 0x0805aa1e in tb_find_fast (cpu=0x8a9e370, last_tb=0xb4af1044,
>>>> tb_exit=1) at /home/build/src/qemu/cpu-exec.c:339
>>>> #19 0x0805b189 in cpu_sparc_exec (cpu=0x8a9e370) at
>>>> /home/build/src/qemu/cpu-exec.c:625
>>>> #20 0x0808666d in tcg_cpu_exec (cpu=0x8a9e370) at
>>>> /home/build/src/qemu/cpus.c:1541
>>>> #21 0x0808675b in tcg_exec_all () at /home/build/src/qemu/cpus.c:1574
>>>> #22 0x08085c29 in qemu_tcg_cpu_thread_fn (arg=0x8a9e370) at
>>>> /home/build/src/qemu/cpus.c:1171
>>>> #23 0xb7bc12de in start_thread (arg=0xb4af1b40) at pthread_create.c:334
>>>> #24 0xb7aeb23e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122
>>>> (gdb)
>>>>
>>>>
>>>> I've added Richard as CC since it looks like this is something in the
>>>> TCG core.
>>>
>>> While you are at it, can you please check, whether  -singlestep option
>>> chanes anything at all?
>>> It may help to see if the bug has to do with the TCG optimizer.
>>
>> Adding -singlestep seems to cause OpenBIOS to hang after displaying the
>> initial banner here. Is this similar to -icount which is currently not
>> working under SPARC64?
> 
> Yes, it is similar, but unlike -icount it is working. It slows down
> things quite a bit, but on a x86_64 host I get:
> 
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:20
>   Type 'help' for detailed information
> Trying disk:a...
> No valid state has been set by load or init-program
> 0 >   ok
> 
> It takes ~20 seconds to get there though.

Ah indeed. It took a while to get there, but I did get a successful boot
to the Forth prompt on i386 booting with "./qemu-system-sparc64
-nographic -singlestep". So does that mean this is an optimizer bug?


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]