Re: intermittent hang, s390x host, bios-tables-test test, TPM

[Stefan Berger]

On 1/10/23 14:27, Daniel P. Berrangé wrote:
> On Tue, Jan 10, 2023 at 01:50:26PM -0500, Stefan Berger wrote:
> > On 1/6/23 10:16, Stefan Berger wrote:
> > > This here seems to be the root cause. An unknown control channel
> > > command was received from the TPM emulator backend by the control channel 
> > > thread and we end up in g_assert_not_reached().
> > >
> > > https://github.com/qemu/qemu/blob/master/tests/qtest/tpm-emu.c#L189
> > >
> > >
> > >
> > >           ret = qio_channel_read(ioc, (char *)&cmd, sizeof(cmd), NULL);
> > >           if (ret <= 0) {
> > >               break;
> > >           }
> > >
> > >           cmd = be32_to_cpu(cmd);
> > >           switch (cmd) {
> > >    [...]
> > >           default:
> > >               g_debug("unimplemented %u", cmd);
> > >               g_assert_not_reached();                <------------------
> > >           }
> > >
> > > I will run this test case in an endless loop on an x86_64 host and see what we 
> > > get there ...
> >
> > I could not recreate the issue running the  test on a ppc64 and x86_64
> > host. There we like >100k test runs on ppc64 and >40k on x86_64. Also
> > simulating the reception of an unsupported command did not lead to a
> > hang like shown here.
>
> Assuming your ppc64 host is running an little endian OS, and
> we're only seeing the test failure on s390x, then it points towards
> the problem being an endianness issue in the TPM code. Something
> missing a byteswap somewhere along the way ?

Yes, my ppc64 machine is also little endian. If the issue  was not an 
intermittent but a permanent
failure I would look for something like that. I would think it's more some sort 
of initialization
issue, like a value on the stack that occasionally set to an undesirable value 
-- maybe even in a
dependency.

   Stefan

> With regards,
> Daniel