From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEecR-0000Z1-Hz for qemu-devel@nongnu.org; Sun, 19 Jun 2016 11:26:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEecP-00008l-Na for qemu-devel@nongnu.org; Sun, 19 Jun 2016 11:26:39 -0400 MIME-Version: 1.0 In-Reply-To: <57640174.70901@ilande.co.uk> References: <1465912676-6089-1-git-send-email-thuth@redhat.com> <20160615031018.GD4882@voom.fritz.box> <20160617060718.GC19581@voom.fritz.box> <5763DE99.8070105@ilande.co.uk> <5763F0B0.7050208@ilande.co.uk> <57640174.70901@ilande.co.uk> From: Artyom Tarasenko Date: Sun, 19 Jun 2016 17:26:16 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: David Gibson , Thomas Huth , Markus Armbruster , qemu-devel , Alexander Graf , Blue Swirl , qemu-ppc@nongnu.org, Richard Henderson , Laurent Desnogues On Fri, Jun 17, 2016 at 3:56 PM, Mark Cave-Ayland 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 >>>>>>>> Signed-off-by: Thomas Huth >>>>>>>> --- >>>>>>>> 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 >>>>> >>>>> 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: >>>>> . >>>>> Find the GDB manual and other documentation resources online at: >>>>> . >>>>> 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 , >>>>> desired_regs=255, allocated_regs=255, rev=true) at >>>>> /home/build/src/qemu/tcg/tcg.c:1743 >>>>> #4 0x0806181a in temp_load (s=0x8637780 , ts=0x8637978 >>>>> , desired_regs=255, allocated_regs=255) at >>>>> /home/build/src/qemu/tcg/tcg.c:1762 >>>>> #5 0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_EAX, >>>>> allocated_regs=255) at /home/build/src/qemu/tcg/tcg.c:1694 >>>>> #6 0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_EAX, >>>>> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1709 >>>>> #7 0x08061740 in tcg_reg_alloc (s=0x8637780 , >>>>> desired_regs=255, allocated_regs=254, rev=true) at >>>>> /home/build/src/qemu/tcg/tcg.c:1738 >>>>> #8 0x0806181a in temp_load (s=0x8637780 , ts=0x8637978 >>>>> , desired_regs=255, allocated_regs=254) at >>>>> /home/build/src/qemu/tcg/tcg.c:1762 >>>>> #9 0x080615e0 in tcg_reg_sync (s=0x8637780 , reg=TCG_REG_ECX, >>>>> allocated_regs=254) at /home/build/src/qemu/tcg/tcg.c:1694 >>>>> #10 0x08061653 in tcg_reg_free (s=0x8637780 , reg=TCG_REG_ECX, >>>>> allocated_regs=252) at /home/build/src/qemu/tcg/tcg.c:1709 >>>>> #11 0x08061740 in tcg_reg_alloc (s=0x8637780 , >>>>> desired_regs=255, allocated_regs=252, rev=true) at >>>>> /home/build/src/qemu/tcg/tcg.c:1738 >>>>> #12 0x0806181a in temp_load (s=0x8637780 , ts=0x8637978 >>>>> , desired_regs=255, allocated_regs=252) at >>>>> /home/build/src/qemu/tcg/tcg.c:1762 >>>>> #13 0x08061858 in temp_load (s=0x8637780 , ts=0x8637f48 >>>>> , desired_regs=255, allocated_regs=252) at >>>>> /home/build/src/qemu/tcg/tcg.c:1765 >>>>> #14 0x0806220f in tcg_reg_alloc_op (s=0x8637780 , def=0x859c150 >>>>> , opc=INDEX_op_sub2_i32, args=0x863be54 >>>>> , dead_args=60, sync_args=0 '\000') at >>>>> /home/build/src/qemu/tcg/tcg.c:2050 >>>>> #15 0x08063156 in tcg_gen_code (s=0x8637780 , 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