qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Artyom Tarasenko <atar4qemu@gmail.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	Thomas Huth <thuth@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, Blue Swirl <blauwirbel@gmail.com>,
	qemu-ppc@nongnu.org, Richard Henderson <rth@twiddle.net>,
	Laurent Desnogues <laurent.desnogues@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully
Date: Sun, 19 Jun 2016 17:26:16 +0200	[thread overview]
Message-ID: <CACXAS8CLxW6G2+1zxe-ff1ePhWpfB7M7PFLE_TUdBPgijcHyBg@mail.gmail.com> (raw)
In-Reply-To: <57640174.70901@ilande.co.uk>

On Fri, Jun 17, 2016 at 3:56 PM, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> 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 <armbru@redhat.com>
>>>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>>>>> ---
>>>>>>>>  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	other threads:[~2016-06-19 15:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 13:57 [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully Thomas Huth
2016-06-15  3:10 ` David Gibson
2016-06-17  6:07   ` David Gibson
2016-06-17  6:49     ` Thomas Huth
2016-06-17 11:27     ` Mark Cave-Ayland
2016-06-17 11:36       ` Artyom Tarasenko
2016-06-17 12:44         ` Mark Cave-Ayland
2016-06-17 12:57           ` Artyom Tarasenko
2016-06-17 13:56             ` Mark Cave-Ayland
2016-06-19 15:26               ` Artyom Tarasenko [this message]
2016-06-19 17:28                 ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACXAS8CLxW6G2+1zxe-ff1ePhWpfB7M7PFLE_TUdBPgijcHyBg@mail.gmail.com \
    --to=atar4qemu@gmail.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=laurent.desnogues@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).