Re: buildds: rv-osuosl-01 vs rv-mullvad-03
On 31 Aug 2022, at 21:21, Aurelien Jarno <aurel32@debian.org> wrote:
>
> On 2022-08-31 19:10, Aurelien Jarno wrote:
>> Hi,
>>
>> On 2022-08-31 17:46, Mathieu Malaterre wrote:
>>> Hi Manuel !
>>>
>>> On Wed, Aug 31, 2022 at 3:49 PM Manuel A. Fernandez Montecelo
>>> <manuel.montezelo@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wed, 31 Aug 2022 at 13:49, Mathieu Malaterre <malat@debian.org> wrote:
>>>>>
>>>>> Would you have an explanation for the repeated failures (FTBFS) of
>>>>> highway on rv-plct-04 / rv-plct-06 & rv-plct-07 ?
>>>>>
>>>>> As mentioned previously I cannot reproduce it on my side neither
>>>>> schroot / nor real hardware.
>>>>
>>>> I scheduled another rebuild, it ended up in rv-plct-03, trying again
>>>> to see if we have more luck now...
>>>>
>>>> As for the failures in rv-plct-xx machines, yeah, there have been
>>>> reports in the last few days in several packages, not sure what's
>>>> going on -- aurel32 checked and one possible cause is high
>>>> temperature, but no definitive conclusions yet.
>>>>
>>>> Maybe it would be good to disable them temporarily, or add some delay
>>>> so the more stable machines get more chances and so to avoid this
>>>> affecting and causing alarm and mistrust among maintianers.
>>>
>>> Ok, thanks for the update.
>>>
>>> While on the subject (no finger pointing - just curiosity). Could
>>> someone confirm why I am seeing old packages on riscv-64:
>>>
>>> [...]g++-12_12.1.0-8 gcc-12_12.1.0-8[...]
>>>
>>> ref:
>>>
>>> * https://buildd.debian.org/status/fetch.php?pkg=highway&arch=riscv64&ver=1.0.1-2&stamp=1661954239&raw=0
>>
>> This is a combination of gcc-12 being late to be built due to a first
>> FTBFS on a not really stable buildd and broken mirrors due to the rsync
>> security update. Anyway that's not the issue here.
>>
>> The illegal instruction is the following one and comes from inline
>> assembly code in highway:
>>
>> 0x0000003f861eaf0a <+92>: add a5,a5,sp
>> => 0x0000003f861eaf0c <+94>: rdcycle a3
>> 0x0000003f861eaf10 <+98>: rdcycle a4
>
> This is a shorter reproducer:
>
> ---o---
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main()
> {
> uint64_t t;
>
> asm volatile("rdcycle %0" : "=r"(t));
>
> printf("cycles: %ld\n", t);
> }
>
> ---o---
>
> It works fine on
> - QEMU running a 5.18.16-1 kernel
> - Hifive Unleashed running a 5.10.28 kernel
> - Polarfire Icicle running kernel 5.18.14-1
>
> However it produces a SIGILL on
> - Hifive Unmatched running a 5.18.14-1 kernel
> - Hifive Unmatched running a 5.18.16-1 kernel
>
> I do not have any real explanation for the issue, and I don't know if
> this issue is new or not. I am a bit reluctant to test older kernel
> version on remote hosts. Any ideas or test is therefore welcome.
For some reason, Linux writes 0x2 to scounteren, disabling userspace
access to anything other than the time CSR. Hardware isn’t required to
allow the counters to be disabled, though, so probably all the cases
where it works are ones where the hardware hardwires them to enabled.
This is silly in my opinion, real-world code does query it; Clang even
has a target-independent __builtin_readcyclecounter intrinsic for it.
Though it looks like AArch64 might be in the same camp here?
In FreeBSD we just leave it accessible...
Jess
Reply to: