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: Artyom Tarasenko
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully
Date: Sun, 19 Jun 2016 17:26:16 +0200

On Fri, Jun 17, 2016 at 3:56 PM, Mark Cave-Ayland
<address@hidden> 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?
>

Either that, or target-sparc uses a TCG temp instead of a local temp
at some place.
The optimizer may assume the temp is not needed, and optimize it away.
Adding to CC Laurent, since he diagnosed a similar bug a couple of years ago.

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu



reply via email to

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