All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: Artyom Tarasenko <atar4qemu@gmail.com>
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>
Subject: Re: [Qemu-devel] [PATCH v2] ppc / sparc: Add a tester for checking whether OpenBIOS runs successfully
Date: Fri, 17 Jun 2016 14:56:04 +0100	[thread overview]
Message-ID: <57640174.70901@ilande.co.uk> (raw)
In-Reply-To: <CACXAS8A613Xa+KUrR1sxK8OcYEL40=CAVxkt18OJR1f+m7+F+w@mail.gmail.com>

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

> On Fri, Jun 17, 2016 at 2:44 PM, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> On 17/06/16 12:36, Artyom Tarasenko wrote:
>>
>>> Hi Mark,
>>>
>>> On Fri, Jun 17, 2016 at 1:27 PM, Mark Cave-Ayland
>>> <mark.cave-ayland@ilande.co.uk> 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 <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?


ATB,

Mark.

  reply	other threads:[~2016-06-17 13:57 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 [this message]
2016-06-19 15:26               ` Artyom Tarasenko
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=57640174.70901@ilande.co.uk \
    --to=mark.cave-ayland@ilande.co.uk \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=blauwirbel@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.