[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