From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDuGk-00020Y-IC for qemu-devel@nongnu.org; Fri, 17 Jun 2016 09:57:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDuGh-0003VB-Oe for qemu-devel@nongnu.org; Fri, 17 Jun 2016 09:57:09 -0400 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> From: Mark Cave-Ayland Message-ID: <57640174.70901@ilande.co.uk> Date: Fri, 17 Jun 2016 14:56:04 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Artyom Tarasenko Cc: David Gibson , Thomas Huth , Markus Armbruster , qemu-devel , Alexander Graf , Blue Swirl , qemu-ppc@nongnu.org, Richard Henderson On 17/06/16 13:57, Artyom Tarasenko wrote: > On Fri, Jun 17, 2016 at 2:44 PM, Mark Cave-Ayland > wrote: >> On 17/06/16 12:36, Artyom Tarasenko wrote: >> >>> Hi Mark, >>> >>> On Fri, Jun 17, 2016 at 1:27 PM, Mark Cave-Ayland >>> 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 >>>>>>> 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? ATB, Mark.