qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] .travis.yml: skip ppc64abi32-linux-user with plugins


From: Alex Bennée
Subject: Re: [PATCH] .travis.yml: skip ppc64abi32-linux-user with plugins
Date: Wed, 15 Jul 2020 09:02:05 +0100
User-agent: mu4e 1.5.4; emacs 28.0.50

David Gibson <david@gibson.dropbear.id.au> writes:

> On Tue, Jul 14, 2020 at 06:55:16PM +0100, Alex Bennée wrote:
>> We actually see failures on threadcount running without plugins:
>> 
>>   retry.py -n 1000 -c -- \
>>     ./ppc64abi32-linux-user/qemu-ppc64abi32 \
>>     ./tests/tcg/ppc64abi32-linux-user/threadcount
>> 
>> which reports:
>> 
>>   0: 978 times (97.80%), avg time 0.270 (0.01 varience/0.08 deviation)
>>   -6: 21 times (2.10%), avg time 0.336 (0.01 varience/0.12 deviation)
>>   -11: 1 times (0.10%), avg time 0.502 (0.00 varience/0.00 deviation)
>>   Ran command 1000 times, 978 passes
>> 
>> But when running with plugins we hit the failure a lot more often:
>> 
>>   0: 91 times (91.00%), avg time 0.302 (0.04 varience/0.19 deviation)
>>   -11: 9 times (9.00%), avg time 0.558 (0.01 varience/0.11 deviation)
>>   Ran command 100 times, 91 passes
>> 
>> The crash occurs in guest code which is the same in both pass and fail
>> cases. However we see various messages reported on the console about
>> corrupted memory lists which seems to imply the guest memory allocation
>> is corrupted. This lines up with the seg fault being in the guest
>> __libc_free function. So we think this is a guest bug which is
>> exacerbated by various modes of translation. If anyone has access to
>> real hardware to soak test the test case we could prove this properly.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: David Gibson <david@gibson.dropbear.id.au>
>> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
> Honestly, AFAICT the ppc64abi32-linux-user target is pretty much
> entirely broken anyway.  Many things about it appear to make no
> sense, it's difficult to work out what it's even supposed to be, and I
> strongly suspect no-one's actually used it in like a decade.

Should we think about marking it deprecated for 5.2?

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]