dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
<davidlt[m]> As expected Meteor Lake is at Computex
<davidlt[m]> I just hope 16K monitor doesn't become a reality :)
jcajka has joined #fedora-riscv
<cwt[m]> I'm upgrading to F38 vis chroot on my Arch Linux.
<cwt[m]> s/vis/via/
<cwt[m]> with bind mount /boot and /lib/modules, I hope I should be able to run dracut to create a working initramfs image for F38.
<Eighth_Doctor> <davidlt[m]> "I just hope 16K monitor doesn'..." <- it'll happen... I'm pretty sure it already exists at an industrial level, it'll take a few years before it becomes available in the prosumer/consumer space
<davidlt[m]> Conan Kudo: there is one at Computex, but not a final panel, I think.
<Eighth_Doctor> doesn't surprise me
<davidlt[m]> I just cannot imagine driving 16K as any meaningful FPS.
<Eighth_Doctor> well, the memory requirements mean that GPU architectures will need to change
<davidlt[m]> Not gonna happen :) I mean adding more memory to GPU is not what Nvidia wants to do :)
<Eighth_Doctor> indeed
<davidlt[m]> That would make then useful for other workloads (AI, HPC, etc.)
<Eighth_Doctor> even ignoring that, it's not cost-effective to bolt on 64GB+ of VRAM on a GPU
<davidlt[m]> There is already agreements that forbid you using gaming GPUs for scientific workloads IIRC.
<Eighth_Doctor> ReBAR already gives us a bit of an out here
<Eighth_Doctor> and we may see more on that path
<davidlt[m]> GDDR6 chips aren't that expensive IIRC.
<cwt[m]> <cwt[m]> "with bind mount /boot and /lib/..." <- Ha, selinux blocked me from booting 🤣
<davidlt[m]> There will be new images today.
<Eighth_Doctor> <davidlt[m]> "GDDR6 chips aren't that expensiv..." <- GDDR6X, however, is not yet standardized by JEDEC, and development on GDDR7 and HBM4 are both ongoing
<davidlt[m]> Yeah, but I doubt we will see HBM on consumer hardware again.
<Eighth_Doctor> depending on how things go, I'm not so sure
<Eighth_Doctor> ReBAR changes things significantly, as does the need for consumer access to AI/ML capabilities
<davidlt[m]> I get impression ReBAR is a mixed bag for existing game catalog.
<davidlt[m]> And you also get different results on AMD and Intel.
<davidlt[m]> I guess (but don't know, didn't check too) that Intel Arc was designed with ReBAR in mind.
<Eighth_Doctor> It was
<Eighth_Doctor> but yeah, ReBAR is a bit weird for games, but it'll be needed to allow for VRAM overflow to system memory
<davidlt[m]> There aren't a lot of bandwidth on the system memory. Traditionally.
<davidlt[m]> Apple uses LPDDR5 with tons of channels.
<davidlt[m]> Nvidia in their Keynote at Computex mentioned that their latest greatest HW thing is also LPDDR5.
<Eighth_Doctor> yeah
<davidlt[m]> From what I have seen the current AMD APU iGPUs are starving for bandwidth. Performance goes quite up with faster DDR5.
<davidlt[m]> And finally AMD seems be going for "Mega APU" to go against Apple M chips.
<davidlt[m]> I just hope they will go beyond 2 channels to feed that massive iGPU.
<davidlt[m]> Also LPDDR5 has way higher capacities.
<davidlt[m]> Sasmsung sells 144Gb (18GB) per chip.
<cwt[m]> <cwt[m]> "Ha, selinux blocked me from..." <- relabeled and booted. my VF2 is on F38 now.
<rwmjones> cwt[m]: I missed all that .. are you running it with an F38 kernel?
<cwt[m]> rwmjones: I run it with my kernel that built from StarFive source.
<rwmjones> ah ok, sensible
<cwt[m]> I found something weird, my mosh session with byobu got killed while I ran git clone. However, when I mosh back there is no error message in dmesg.
<cwt[m]> It happened 3 times already, and it never happened on Arch.
<davidlt[m]> Check SELinux and Audit logs (or disable them).
<cwt[m]> Like this?
<cwt[m]> type=ANOM_ABEND msg=audit(1685442058.212:271): auid=1000 uid=1000 gid=1000 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1747 comm=746D75783A20736572766572 exe="/usr/bin/tmux" sig=6 res=1AUID="cwt" UID="cwt" GID="cwt"
<davidlt[m]> Yes, see if there is something that blocked something.
<cwt[m]> hmmm, it didn't get killed if I use pure tmux not byobu.
<davidlt[m]> It seems that tmux got abort. Not sure if coredump is generated for these or not.
<davidlt[m]> Try coredumpctl list
<davidlt[m]> I think coredumpctl debug would launch gdb for the last coredump.
<cwt[m]> Will try it tomorrow. I have to go home now.
<davidlt[m]> I see I have some SIGABRT on my laptop :)
<davidlt[m]> Top crashing things for me: Element, Firefox, GNOME Shell :)
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<davidlt[m]> Lacks README :)
<thefossguy> I never asked what are the differences between the mmc, nvme and sda images
<davidlt[m]> sda is the original from the Koji
<davidlt[m]> mmc is full thing (incl. firmware) for SD card
<davidlt[m]> nvme is just /boot and rootfs without firmware
<thefossguy> Gotcha
unlord has quit [Ping timeout: 240 seconds]
zsun has joined #fedora-riscv
unlord has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
zsun has quit [Quit: Leaving.]
<davidlt[m]> Basically the as previous, just more images (just in case).
<davidlt[m]> The LEDs are controlled in a different way now.
<davidlt[m]> Otherwise test, test, test :)
<davidlt[m]> The next one will follow soonish with 6.3.X kernel.
<davidlt[m]> Which exactly I don't know, that will depend on when 6.3 lands in Fedora (there were issues reported, especially with XFS IIRC).
<davidlt[m]> Also I keep monitoring the queue for 6.3 kernel patch backports.
<nirik> davidlt: any reason some of the files under alt/risc-v/disk_images/Fedora-Developer-38-20230519.n.0.SiFive.Unmatched.and.QEMU are mode 640? that messes up miroring...
<davidlt[m]> nirik: no reason, change it to what you need.
<davidlt[m]> It seems there is just one file like that.
<nirik> yeah, ok.
jednorozec_ has joined #fedora-riscv
kalev_ has joined #fedora-riscv
jednorozec has quit [*.net *.split]
kalev has quit [*.net *.split]
jednorozec_ is now known as jednorozec
tg has joined #fedora-riscv
nirik- has quit [Changing host]
nirik- has joined #fedora-riscv
nirik- is now known as nirik99
fuwei has joined #fedora-riscv