03:40 <davidlt[m]> rwmjones: run FUSDK 2022.03 + use only microSD (disconnect everything). Run stress-ng for 1 or 2 days (all stressors, one by one)

03:41 <davidlt[m]> Something like: stress-ng --verbose --seq 4 -t 10

03:41 <davidlt[m]> This one runs for 40-60 minutes, adjust -t option

03:41 <davidlt[m]> I would suggest compiling the latest stress-ng from GitHub

06:25 <davidlt[m]> I will need to look into kernel-tools today

06:25 <davidlt[m]> I see it failed overnight

06:26 <davidlt[m]> No matching package to install: 'libtracefs-devel'

06:26 <davidlt[m]> yeah, this package never managed to build on riscv64

07:16 <davidlt[m]> launched libtracefs, let's see why it fails

07:19 <davidlt[m]> and for the future builds as we towards F37/Rawhide we probably be running RC kernels with debug stuff enabled

07:20 <rwmjones> debug stuff is terrible for performance (on x86-64) .. do we really need it?

07:21 <davidlt[m]> do we want to diverge from upstream Fedora way of doing it? :)

07:21 <davidlt[m]> I could disable debug from time to time

07:21 <davidlt[m]> I think that already happens for a very short period of time until a new RC arrives

07:22 <rwmjones> I've been trying for a long time to dissuade jforbes from enabling debug in rawhide

07:22 <davidlt[m]> We could mix it, i.e. not all the builds have debug stuff.

07:22 <davidlt[m]> Technically I don't want to loose performance because of debug stuff, we don't have much of horse power on these SoCs.

07:23 <davidlt[m]> But we also need not to diverge too much from the path if we ever want to be "a proper thing".

07:24 <davidlt[m]> Again, we could do both while doing disk images.

07:24 <davidlt[m]> That would mean changing one line in kernel.spec IIRC and rebuilding again, and doing a new disk image.

07:24 <davidlt[m]> So cost of that is 1-2 days (technically less than a day).

07:25 <davidlt[m]> That assuming Unmatched level of performance. Also that we do this mainly on native hardware instead of QEMU.

07:25 <davidlt[m]> New boards are coming soonish, might change this picture.

07:27 <rwmjones> hopefully!

07:28 <davidlt[m]> BealgeBoard should happen next week IIRC.

07:28 <davidlt[m]> Embedded World 2022 starts: Tuesday

07:28 <davidlt[m]> , June 21

07:29 <davidlt[m]> So just in case prepare your wallet to spend money :)

07:45 <davidlt[m]> ha!

07:45 <davidlt[m]> So I sent the job to my boards and the package is built

07:45 <davidlt[m]> http://fedora.riscv.rocks/koji/buildinfo?buildID=196320

07:46 <davidlt[m]> I assume that it was constantly failing on older image + QEMU instance

07:46 <davidlt[m]> submitting kernel-tools

07:47 <davidlt[m]> that one takes 2 hours to build

07:47 <davidlt[m]> There continues to be an issue with "fedpkg sources" (I think).

07:48 <davidlt[m]> There we get connection timeout while fetching the sources.

07:49 <davidlt[m]> I also get impression that's less likely to happen on my board compared to rwmjones , just because it seems (based on curl output) that I managed to download sources a bit faster and thus not get into timeout situation too often.

07:49 <davidlt[m]> But it does happen on my board too. The kernel build was problematic, just on the edge of this timeout.

07:50 <davidlt[m]> Could be related to our hardware being damn slow, or maybe some crypto is also damn slow as we have no TRNG, no crypto accel.

07:51 <davidlt[m]> F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

08:00 <rwmjones> wasn't sure what to think about that, but the issue of getting accurate stack traces in perf is a real one that has affected us

08:08 <davidlt[m]> The impact of performance should be none to little (in majority of cases).

08:09 <davidlt[m]> I think, and you can back out of it on individual packages (as long as you have the benchmark data).

10:06 <davidlt[m]> fixing kernel-tools will take me a bit of time

11:28 <rwmjones> hmm, nufive just crashed while I was doing:

11:28 <rwmjones> $ git clone git@github.com:libguestfs/libguestfs.git

11:28 <rwmjones> it crashed at:

11:28 <rwmjones> Receiving objects: 100% (128775/128775), 390.56 MiB | 7.08 MiB/s, done.

11:28 <rwmjones> Resolving deltas: 10% (10219/101854)

11:28 <rwmjones> (which I think is compute intensive?)

11:28 <davidlt[m]> yeah

11:29 <rwmjones> is there some mechanism I don't understand by which the power shuts off when the CPU is overloaded?

11:29 <rwmjones> I'm doing the same on nujive now

11:29 <davidlt[m]> tons of crypto, haveged might have been also using quite some CPU to keep that entropy pool

11:30 <rwmjones> running vmstat 1 while doing this on nujive shows this step is basically CPU bound

11:30 <davidlt[m]> just in case reconnect the mini fan for Soc and disconnect the big one

11:31 <rwmjones> yup I was going to do that, but it'll have to be later b/c I've got a meeting in the office

14:59 <drewfustini> davidlt[m]: unfortunately, no news at Embedded World for Beagle other than the (ARM) BeagleBone AI 64... still have two designs with different RISC-V 64-bit SoCs but schedules have been tough this year... at this point we are just saying "later this year". They will get full promotion at RISC-V Summit but I hope it doesn't actually take until December for them to ship. But 2022 is a cruel year for supply chain.

15:02 <drewfustini> It's amazing that anything at all gets done these days. A design is not actually finished until you have the full quantity of all components for the initial production run physically in the hands of the assembly house. Before that point, there is a long cycle of small redesigns to accommodate substitutions for all sorts of components that never used to be an issue prior to the current supply chain crisis.