Thank you for your input. I have noticed stall errors as well. I have noticed that the community tends to do that (such as the psu) and move on. I tried to detail as much info about my setup as I could and when I use my desk fan on it, it runs flawlessly (meaning never freezing or locking up on me). I may buy another Pi 5 and see if i'm getting the same results. My Pi shouldn't be locking up at 63c, but once it reaches that, it does. When that occurs I see what looks to be kernel errors and unable to write to memory errors. I'm not sure if one of the chips has an extra sensitivity to heat for some reason. When the desk fan stays on it, I never see those errors and it just works. Perhaps a defective temp probe as well.Ok... I'm going to throw my hat in the ring here with my findings, as I have had similar issues with the same unit RPi5 8gb, failing to copy files over 1gb over the network, to a USB 3.0 thumbdrive.
At first I went down the UAS rabbit hole... and none of the suggested approaches had any affect on the situation (nor did they change how the drive was recognized by the machine, though that was without UAS already, for whatever reason)
Then I tried changing the page file size, from 16k to 4k, forcing it to use a different kernel, according to another suggestion. And that had no effect.
Then I went down the swap file size path, and increased the size of the swap file from 512mb to 4096mb, just to see if anything changed. and if anything, it got worse. I've been monitoring the file copy process with several different utitilties, and for the most part none of them indicate a spike in CPU, Memory or Swap usage. With one exception... Glances, shows a spike in IO_WAIT times, over and over until the copy process fails.
So I went further down the swap file path and tried the approach discussed in this thread:
https://www.reddit.com/r/linux/comments ... wait_when/
And that had a DRASTIC effect on the behaviour, and finally allowed the copy process to complete. So something in the IO Scheduler/Swap file setup is causing this. There are still surges in IO_WAIT times, and the transfer speed isn't particularly good... but, it doesn't fail.
Anyhow, I don't typically get involved in these discussions, or seek support for any issues I may have on the Linux front. But this finding seemed significant and relevant to this issue, so perhaps it will point someone more knowledgeable than myself in the right direction in tracking down this issue. (and I would like to see the Linux community in general, stop blaming new users for their issues, when they seek assistance... like dismissing it as a power supply issue. It's not helping anyone)
- Jeremy
Statistics: Posted by Fee — Sat Jan 04, 2025 10:34 pm