is it always the same point per dimm where it freezes? If not, it might just be otherwise broken software of some kind ^^’
Some progress further than others, but its always about a bug being triggered in the CPU scheduler and/or SBI trap error
I’m only testing with the Fedora image on the wiki, so I’d expect it to just work?
well, I expected this whole board already to just work and that expectation wasn’t fulfilled ^^’
Be sure to use the newer:
fedora-disk-gnome-workstation_livecd-f38-20231010-033114.n.0-fix.raw
with the 2023-10-10 date rather than the older image which was previously linked in several places.
Well, I’ve switched to the Micron ram I purchased, and now I get an entirely different error around the same spot.
Only thing I have to try next is try switching to a different microSD card, otherwise I don’t think I have many other options to test. I also used the fix image.
I switched to a different PSU I had, and I actually managed to get to a login this time!!!
Specifically the EVGA 100-W1-0500
It appears all sticks of M393A4G43AB3-CWECO 32GB 2Rx8 that I previously said didn’t work, are detected correctly and am able to boot, allowing me to use 128GB memory.
The Micron MTA18ASF4G72PDZ-3GB2VI ram is also working.
1 Like
Congratulations. Keep us up to date if it’s stable now.
I’ve been using the board for a while, I have one stability problem I haven’t figured out (and am unsure I will figure out).
Large file transfers for extended periods of time, I will end up having a bunch of errors spammed about NVME errors, and then the FS will become unmounted.
I have experienced a similar problem with large transfers from SATA drives. It’s easily reproducible so hopefully once we are able to build and boot newer kernels we can perform some bisection testing of different kernels and also use some of the kernel debug tools to dig into what the problem is.
To reproduce my problem, I have installed “numactl” so I can monitor the memory usage (numactl -H) along with “free -m” while the transfer is on-going. reading from the storage device, the page cache fills with data read from the drive (as expected) but when the memory is close to full, something fails and the driver fails. The SATA activity LED for the drive being read blinks rapidly, but the driver appears to be hung or stuck and not actually transferring any data. SATA recovery fails similar to your NVMe failure.
I also have trouble with nvme. Note that they added additional bootargs in the vendor repository scripts: Add params to grub.cfg in Fedora image · sophgo/bootloader-riscv@01dc52c · GitHub
It mitigates the problem a bit for me, but does not solve it. I will probably hook up a sata ssd for the time being.
I’ll have to give those bootflags a try, hopefully they find a more longer-term solution that is stable.