<jimwilson_>
inside the gcc dir, I ran check-gcc with -j[1234], that runs only the C testsuite
<jimwilson_>
I only got unreproducible failures with -j4, I only got correct results with -j1
<jimwilson_>
-j2 and -j3 gave correct number of ^FAIL lines in the output, but the summary line at the end has the wrong counts, that is produced by a shell script
<jimwilson_>
the shell script will call a python script if python is available
<jimwilson_>
so I think that there are two problems, one is the failure under load problem that we have seen before, and the other is that something is going wrong in either the shell or python script that combines result, that could be something that was miscompiled or buggy, needs more investigation
<jimwilson_>
-j4 also has the incorrect summary lines at the end, but the counts are wrong anyways because of things core dumping when they shouldn't
<davidlt[m]>
jimwilson_: have you tried down clocking your Unmatched to lower clock, e.g. 1.0GHz ?
<davidlt[m]>
Also I can rebuild packages on Unmatched (i.e. on a native system) and see if that helps, but we need to identify which packages would need rebuilding.
<davidlt[m]>
I noticed that rebuilding packages on Unmatched does some issues on some packages compared to QEMU VM.
davidlt has joined #fedora-riscv
davidlt has quit [Client Quit]
<jimwilson_>
I have a new board, so haven't done much with it, I returned the SiFive owned board when I quit
<jimwilson_>
with OE I had the unreproducible core dump under load problem, but not the problem with the script that produces summary line
<jimwilson_>
I will have to do more investigation, I only have one board and multiple things I want to do with it
<somlo>
does the current rawhide image (20211110.n.0.SiFive.Unmatched) assume there's a swap partition available somewhere specific? I just built a kernel with the initramfs.cpio image built in, then built a monolithic opensbi with that kerel and my dtb as payloads, and loaded that from /dev/mmcblk0p1 as `boot.bin`; cloned the root filesystem to /dev/mmcblk0p2 (from the fourth partition in the raw image), and it crashes and burns like this: