qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Helge Deller" <deller@gmx.de>,
	qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sven Schnelle <svens@stackframe.org>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH] tests/boot-serial-test: Allow the HPPA machine to shudown
Date: Fri, 24 Jan 2020 08:02:40 +0100	[thread overview]
Message-ID: <0e5d2965-4249-2499-db5e-ee6dd88afb54@redhat.com> (raw)
In-Reply-To: <1c474db4-a9b6-1103-b34d-c37a5338a91e@redhat.com>

On 23/01/2020 22.37, Philippe Mathieu-Daudé wrote:
> On 1/23/20 7:29 PM, Philippe Mathieu-Daudé wrote:
>> On 1/23/20 5:39 AM, Thomas Huth wrote:
>>> On 23/01/2020 01.36, Philippe Mathieu-Daudé wrote:
>>>> The boot-serial test uses SeaBIOS on HPPA, and expects to read the
>>>> "SeaBIOS wants SYSTEM HALT" string, see [*]:
>>>>
>>>>   122 void __VISIBLE __noreturn hlt(void)
>>>>   123 {
>>>>   124     if (pdc_debug)
>>>>   125         printf("HALT initiated from %p\n", 
>>>> __builtin_return_address(0));
>>>>   126     printf("SeaBIOS wants SYSTEM HALT.\n\n");
>>>>   127     asm volatile("\t.word 0xfffdead0": : :"memory");
>>>>   128     while (1);
>>>>   129 }
>>>>
>>>> A 'SYSTEM HALT' would really halts the CPU, but SeaBIOS implements
>>>> it as an infinite loop.
>>>>
>>>> If SeaBIOS does not use the expected serial port but another device,
>>>> we might poll the console indefinitely while the machine is halted.
>>>>
>>>> Allow the HPPA machine to 'shutdown'. When it does, we'll get
>>>> a qtest error:
>>>>
>>>>    $ make check-qtest-hppa
>>>>      TEST    check-qtest-hppa: tests/qtest/boot-serial-test
>>>>    ** (tests/qtest/boot-serial-test:31924): ERROR **: 01:12:37.604:
>>>> Failed to find expected string. Please check
>>>> '/tmp/qtest-boot-serial-sjxoM6Q'
>>>>    ERROR - Bail out! FATAL-ERROR: Failed to find expected string.
>>>> Please check '/tmp/qtest-boot-serial-sjxoM6Q'
>>>>    make: *** [tests/Makefile.include:628: check-qtest-hppa] Error 1
>>>
>>> The tests are run with -no-shutdown. Why does qemu exit in that case?
>>
>> Because the HPPA firmware called HALT.
>>
>>> Sounds like a bug in another place, and not in the boot-serial-test.
>>
>> Yes, the bug is elsewhere, but with the bug the boot-serial-test hangs
>> forever.... No output on the console, qtest waiting indefinitely.
> 
> Richard explained me on IRC what you probably meant, which was not
> obvious to me at first.

I think I also did not really understand what you tried to do here ;-)

The -no-shutdown is required, too, otherwise you could get a race
between the test reading the serial output and the termination of QEMU,
see commit 7150d34a1d60851d73d6ab6783b12b1d25e68f86, and I think we need
that for HPPA, too.

> Now I found in check_guest_output():
> 
>     /* Poll serial output... */
>     while (1) {
>         ...
>         /* Wait at most 360 seconds.  */
>         now = time(NULL);
>         if (now - start >= 360) {
>             break;
>         }
>         g_usleep(10000);
>     }
> 
> $ QTEST_QEMU_BINARY=hppa-softmmu/qemu-system-hppa \
>   time tests/qtest/boot-serial-test -k
> /hppa/boot-serial/hppa:
> ** (tests/qtest/boot-serial-test:18604): ERROR **: 22:33:25.010: Failed
> to find expected string. Please check '/tmp/qtest-boot-serial-sZq7ljM'
> Command terminated by signal 5
> 0.31user 0.66system 6:00.07elapsed 0%CPU
> 
> Indeed the test fails after 6min, I guess I didn't expect that much
> while testing interactively.

Yeah, the huge timeout is ugly, but it is required for very slow hosts,
see commit 627fce617868df87b3757375a2a0318ad2beb381.

So if you want to "fix" your problem, I think you could maybe add a
check for the QEMU events here instead. Or add a check to see whether
the registers of the guest change between iterations to make sure that
the guest is still alive (that way you also handle the case that the
guest crashed and loops forever in a "branch self" instruction). Or
simply continue with the 360s timeout, it's long, but it should trigger
only in case of other bugs, so it's maybe not worth the effort to add
more logic here.

 Thomas



  reply	other threads:[~2020-01-24  7:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  0:36 [PATCH] tests/boot-serial-test: Allow the HPPA machine to shudown Philippe Mathieu-Daudé
2020-01-23  3:27 ` Richard Henderson
2020-01-23 18:37   ` Philippe Mathieu-Daudé
2020-01-23  4:39 ` Thomas Huth
2020-01-23 18:29   ` Philippe Mathieu-Daudé
2020-01-23 21:37     ` Philippe Mathieu-Daudé
2020-01-24  7:02       ` Thomas Huth [this message]
2020-01-24 10:33         ` Philippe Mathieu-Daudé

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=0e5d2965-4249-2499-db5e-ee6dd88afb54@redhat.com \
    --to=thuth@redhat.com \
    --cc=deller@gmx.de \
    --cc=f4bug@amsat.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=svens@stackframe.org \
    /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).