cyberpear has quit [Quit: Connection closed for inactivity]
davidlt has joined #fedora-riscv
davidlt has quit [Ping timeout: 252 seconds]
davidlt has joined #fedora-riscv
tg has quit [Quit: tg]
jcajka has joined #fedora-riscv
jcajka has quit [Ping timeout: 252 seconds]
jcajka has joined #fedora-riscv
zsun has joined #fedora-riscv
<skip77>
davidlt[m] (or anyone with experience in this): Have you ever experienced indefinite hangs on a bzip2 process in a risc-v buildroot? Particularly just as a long build is wrapping up?
<davidlt[m]>
skip77: Not on bzip2
<skip77>
Context is I'm beginning to play with bootstrapping Rocky Linux for risc-v, and I'm doing it in qemu on x86_64 hardware atm, as that's all I've got
<davidlt[m]>
Is it actually doing something?
<davidlt[m]>
Like did you try to connect to it via stress to see what's cooking inside?
<skip77>
I don't think so, I strace attached to it, and I don't see system calls or progress.
<skip77>
I'm not familiar w/ stress - let me look it up
<davidlt[m]>
So it's not using CPU and strage basically says it's stuck on some syscall?
<davidlt[m]>
But in general testing on multiple targets makes life a bit easier :) QEMU vs. physical hardware, to verify that it's not a QEMU bug (or HW).
<skip77>
Looks that way. I also ran into something like this when I tried a kernel compile a couple months ago
<skip77>
Makes me sad, because this is the end of a 30 hour gcc build :-/
<davidlt[m]>
I do use QEMU setup (a large one with 32-cores and 80GB RAM) and haven't seen this issue.
<davidlt[m]>
Well, be happy it's just 30 hours ;) Ours take 200+ hours :D
<davidlt[m]>
My advice would be to switch to a different compression lib for now.
<davidlt[m]>
zstd is the best for this
<davidlt[m]>
xz is no-go unless you want to waste a few days of your life a week
<skip77>
Well, I'd have to modify our gcc I think to do that.... I'll look at my options
<davidlt[m]>
Just set it to zstd to make your life go a bit faster.
<davidlt[m]>
It's a bootstrap and you seem to be in an early stage thus just hack around this issue for now.
<davidlt[m]>
As long as zstd, gzip, etc. works that should allow you to make forward progress.
<davidlt[m]>
The whole issue with bzip2 might just go away a bit later once you rebuild kernel, or QEMU version if updating, or anything else.
<davidlt[m]>
Once you have more of Rocky you can go back and start reverting these hacks back to Rocky defaults.
<skip77>
Well, speaking of workarounds and crazy ideas, I'm going to give something a shot :P
<skip77>
It's the silliest thing, literally a bzip process on the changelog. I can see the gcc binaries and libs have all been produced in the mock chroot, which makes me very happy. It was hard to even get this far lol
<skip77>
Do you use more than 8 virtual cores in your qemu setup? That's as high as it would let me go
<davidlt[m]>
Yeah, 32-cores.
<davidlt[m]>
Especially for the GCC build experimentations.
<davidlt[m]>
But you need U-Boot and Kernel support for that. Newer QEMU versions (last 2-3) will let you go past 8 vCPUs.
<davidlt[m]>
Max RAM tested on my side is 80GB.
<skip77>
Wow, I'll have to get more info from you later. I'm on qemu 7.0 atm, which I built for Rocky9
<davidlt[m]>
I would advice to switch to a Fedora 38 for the host :)
<davidlt[m]>
I also use virt-preview COPR repo to get latest version of QEMU.
<skip77>
Might be a good idea. I'm sort of using the hardware for another build project at the same time, so I have to kinda straddle things
<davidlt[m]>
QEMU has one problem right now. By default it runs on Sv48 and that will break some packages, like Golang.
<skip77>
Thank you, I'll keep that in mind.
<davidlt[m]>
Latest QEMU (very soon to be released) and newer kernel allow you to cap it to Sv39.
<davidlt[m]>
All available hardware is Sv39 only thus this problem doesn't show up.
<davidlt[m]>
Basically you want to run QEMU 8.0.0.
<davidlt[m]>
Or/and 6.3 kernel :)
<davidlt[m]>
Basically if you cannot update QEMU, you need a new kernel.
<davidlt[m]>
If you cannot update the kernel, you need a new QEMU :)
<skip77>
Right. God willing, I could make it to golang soon(tm)
<skip77>
So far I've got our glibc (2.34) and a bootstrap annobin done, and settled on a hodge-podge "bootstrap repo" of stuff from your excellent koji
<skip77>
It's clunky, but it seems to be working lol
<skip77>
Anyway, going to try a Crazy Idea(tm) to save this build, and if it doesn't work I suppose I'll just try again
<davidlt[m]>
Just keep hacking and increasing RPMs count :)
<davidlt[m]>
I hear those 64-core systems should be available relatively soonish
<davidlt[m]>
IIUC probably before the official summer season arrives :)
<davidlt[m]>
and TH1520 (C910, OoO, T-HEAD extensions, etc.) stuff is also here.
<davidlt[m]>
Their produced their 1st 2K unit batch, with next one in May.
<skip77>
omg, I think crazy idea worked(!)
<davidlt[m]>
What was it? some kind of symlink? :)
<skip77>
Hopped in to the bzip2 process w/ gdb. call (int) exit(0)
<davidlt[m]>
:D
<skip77>
It was already done writing, I checked the files in the buildroot myself. Just the changelog text files from 2002 and 2011. Weird and random
<skip77>
mock logs say rpms are being written right now
<davidlt[m]>
Saved!
<davidlt[m]>
Any plans to talk about this in some conf, like DevConf.CZ, Flock, etc.?
<skip77>
Um... I hadn't even considered that lol. I'll see if I can play with it and try and re-create it some more first
<davidlt[m]>
I almost managed to generate the 1st Fedora 38 image today, but failed due to stupid mistake on my part :(
<davidlt[m]>
I didn't not expect Fedora 38 to go GA on early target date :)
<davidlt[m]>
I used to 2-3 weeks delay :D
<skip77>
At this point I think just keeping up with the releases is impressive
<davidlt[m]>
I don't run boards 24/7 otherwise I would be on time, I guess.
<davidlt[m]>
There is only 3-4 boards right now that run 24/7 and those typically get heavy stuff like GCC.
<skip77>
Yeah, I saw gcc + annobin cooking in koji the other day
<skip77>
I'm there a lot, yanking different older artifacts for my bootstrap repo :P
<davidlt[m]>
I managed to catch up with GCC builds, but Jakub launched another one yesterday :)
<davidlt[m]>
We delete nothing since day 1 thus you can find all our RPMs (and logs).
<skip77>
I'm just lucky Rocky (RHEL) has a much slimmer set of packages, and it's very much more a "fixed point" on the versions
<davidlt[m]>
Oh yeah, CentOS Stream and Rocky (without EPEL) is way easier target.
<skip77>
I have a road ahead of me, but not nearly as long as a complete Fedora haha
<davidlt[m]>
I am happy to help building some packages if this becomes not-a-single-person-mission :)
<davidlt[m]>
/ after I get my Fedora 38 image out and running on the boards
<davidlt[m]>
skip77: you might want to get VF2 board, that one is getting upstream kernel support in v6.3.
<davidlt[m]>
Well, the same money spent here ( https://sipeed.com/licheepi4a ) are better value, but who knows how long before upstream support.
<davidlt[m]>
16GB of RAM, OoO cores, T-HEAD extensions (not used right now), kinda slow IO.
<skip77>
I have an original VisionFive that my company "gifted" to me, but that may not be useful for testing at this point
<skip77>
I understand it's quite old
<davidlt[m]>
Yeah, don't use it.
<davidlt[m]>
Not that, it's kinda a test chip with some mistakes.
<davidlt[m]>
JH7110 is kinda a true chip, but still just a stepping stone. JH8100-series are OoO cores with inhouse core IP.
<cwt[m]>
I just tested 6.3 (from starfive github) on my VF2 with Arch Linux.
<davidlt[m]>
JH7110 is not really a money making SoC too.
<thefossguy>
cwt[m]: rc7? Did the DTB issue I mentioned in #archlinux-riscv:matrix.org get fixed?
<davidlt[m]>
skip77: you might want to patch GCC to always link to libatomic, or backport upcoming changes to GCC 14 (and 13, special branch) to improve atomics situation
<davidlt[m]>
Which DT issue?
<davidlt[m]>
I kinda remember some emails, but don't recall.
<cwt[m]>
thefossguy: nope, either you still need to copy the right file to the old filename, or change fdtfile param in uEnv.txt
<thefossguy>
Well, the DTB that current build of firmware uses doesn't match up with what is in 6.3-rc7. But the board variants are upstreamed.
<thefossguy>
So you can just copy your board specific dtb to the generic name that the firmware expects and it boots
<davidlt[m]>
But U-Boot isn't upstreamed yet.
<thefossguy>
I'm talking about the uboot thats on the board, provided by the vendor :)
<davidlt[m]>
So it doesn't matter what existing bootloader binaries are doing (from my point of view).
<davidlt[m]>
As long as it boots with U-Boot patches posted for review, I am fine.
<cwt[m]>
btw, my board just gone offline, I think the reset/reboot driver is not working, gpu rtc crypto drivers also not working.
<davidlt[m]>
These issues are expected until things land. Let's call it "transition period".
<thefossguy>
davidlt[m]: Haven't tried that yet, was thinking of compiling uboot with efi support just for funsies
<thefossguy>
davidlt[m]: Yep, I think 6.5 ought to iron out most of these issues, at least from a "hey its a dev board, it boots and I have serial console" POV
tg has joined #fedora-riscv
<davidlt[m]>
Well, what I told StarFive last year: your 1st goal is just boot, nothing fancy.
<cwt[m]>
the good thing is the ethernet driver is better, now it can adjust MTU based on value returned from my DHCP.
<davidlt[m]>
Once it boots you can plug that into CI/CD and plug the rest.
<thefossguy>
Yep, need to get more VF2 now :p
<davidlt[m]>
I guess we can almost stamp VF2 with "supported by upstream" sticker :)
<cwt[m]>
I hope almost everything will be worked in 6.4 mainline.
<davidlt[m]>
Definitely not :)
<davidlt[m]>
It typically takes 6-18 months to get most of it.
<davidlt[m]>
Some of the things will not be upstreamed too.
<cwt[m]>
oh.. hardware random number generator also not working.
<davidlt[m]>
Heck, we didn't even finish FU740/SiFive HiFive Unmatched upstreaming :)
<davidlt[m]>
There are a few patches floating around.
<cwt[m]>
I don't care much about GPU, but I need crypto and HW Rng.
<davidlt[m]>
Same.
<davidlt[m]>
GPU most likely will happen from what I hear, but it's a larger effort, most likely not by StarFive.
<davidlt[m]>
IIRC TH1520 also has the same GPU.
<davidlt[m]>
I think, but I might be wrong.
<cwt[m]>
for GPU, I just want to use opencl with tensorflow for inference.
<cwt[m]>
never want to use GUI desktop on this board anyway.
zsun has quit [Quit: Leaving.]
<cwt[m]>
but it seem like StarFive is trying to promote this board as a Raspberry Pi replacement, they did a lot of things to make debian desktop image.
<alexsaezm>
Any board that you might recommend? Just to start playing with it
jcajka has quit [Quit: Leaving]
tg_ has joined #fedora-riscv
tg has quit [Ping timeout: 248 seconds]
<davidlt[m]>
VF2 is you want a decent perf, available today and almost upstream support.
<davidlt[m]>
Least friction experience.
<davidlt[m]>
If you want a better value for your money, but no upstream support (unknown ETA, if at all): https://sipeed.com/licheepi4a
<davidlt[m]>
Price should be very similar, OoO cores (thus way higher perf), 16GB RAM (higher capacity and higher freq; but tells nothing about their memory controllers or cache subsystem, etc.).
<davidlt[m]>
No PCIe thus only low speed I/O.
<davidlt[m]>
Well, USB 3.0 to NVMe adapter still would do wonders with it too.
<davidlt[m]>
I would avoid D1. It got upstream support, but definitely underpowered stuff.
<davidlt[m]>
There are other issues too.
<davidlt[m]>
There will be higher perf stuff too, but that will significantly raise the price range.
<davidlt[m]>
Only worth if you are an active developer and target riscv64 in particular basically.
pawning-cornmeal has joined #fedora-riscv
pawning-cornmeal has left #fedora-riscv [#fedora-riscv]
davidlt has quit [Ping timeout: 264 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]