Hi, I know you tested your RAM, but have you tried more RAM or a different set, have you tried turning off XMP and running the RAM stock? RAM overclocking can sometimes cause glitches in a system.
Have you checked the OS or the OS drive? There might be some corrupted data or a bad memory block on the SSD
I noticed that the server login said Jellyfin, 8GB RAM is the minimum for Jellyfin, and you might need a little extra RAM. If it is doing transcoding work you will definitely need more RAM.
You might also consider a bigger power supply. A quick trip over to PC Part Picker to quickly model your system (Part List - Intel Core i5-9400F, Arc A750 - PCPartPicker) shows that the max power draw on those components is 385W If it is doing transcoding work it will sail over your power supply’s 350W.
Just some things I would try if I was chasing down a bug causing a crash.
If the system runs out of RAM it shouldn’t reboot (possibly crash or be very unhappy in general however), otherwise it’s broken memory management of the Linux kernel
Transcoding doesn’t take up much RAM in general so 8Gb should be fine however since the ARC series is still pretty new you might see some kind of driver bug which may take down the system so a newer kernel and video driver might resolve your issue however I have no idea how you change that using Ubuntu or if its even possible without breaking the package system. That being said, it might very well be some kind of heat, power related issue. The prompt doesn’t seem to the one where it outputs kernel output or such so without a log it’s hard to determine whats going on.
I haven’t as it never showed signs pointing to an issue with the BIOS until a few days ago but now I don’t have physical access so can’t do it.
The RAM stick doesn’t support XMP and is running at its JEDEC speed.
I would’ve like to but I don’t know how. Keep in mind that I don’t currently have physical access so I can only do it from the OS. However it won’t let me since I can’t unmount my root file system in the middle of using the system afaik. I can’t run fsck without unmounting.
Even with all that, I don’t think the problem is with the SSD. This SSD was used for something else, and it would have already caused problems then if it was actually bad.
8GB is a recommended number, not a hard requirement. I wrote that page, I know. If the system is running out of memory, the OS would kill processes to free memory instead of just crashing.
Every time it crashes it’s sitting idle doing a whole lot of nothing, and it never cut out in the middle of transcoding something for Jellyfin. If the power supply actually got overloaded it would restart instead of crash. I don’t think this is the problem.
I’ve performed multiple full system updates, including updating the kernel and the same behavior still persists.
There are no traces of the event in the system logs so I really can’t pinpoint the issue. This is why I have a capture card attached to the system in the first place, so that I can (hopefully) extract some useful information from the screen it crashed.
I do not know about Jellyfin’s encoding procedure, but Plex uses more RAM when it transcodes, and 8GB is Jellyfin’s base minimum. The Intel Arc is likely using QuickSync, but you are right that the kernel might need to be updated. The RAM, however is the quickest hardware change to make, and RAM can do weird intermittent things. As my uncle used to say, “it couldn’t hurt, and it might help.”
Power quality issues aren’t really a thing in my area. I have another system using the exact same model of power supply and it isn’t exhibiting the same behavior. This power supply was also a known good unit.
They don’t. Also, this PSU is rated for full 350w output on the +12V rail
Well, I have run out of patience, and the system is yours to fix, so good luck.
On that note … you do know that the Japanese capacitor thing is a marketing ploy. Sure there are great Japanese capacitors, but just like everything manufactured by any component manufacturer there are also some just fair Japanese capacitors. Also … How do you get D/C - D/C design … there has to be an A/C portion in the design somewhere.
I don’t think they would’ve bothered to use all Japanese caps and a DC-DC design if it was supposed to be a bargain basement grade unit.
Thant’s pure marketing speak, nothing more. If it weren’t for capacitor plague, they would even bother saying that.
Its also rated 350E on 12V rail and 350W total on all rails. That and is the point here. There is very little slack here. Your gpu alone is known to power spike up to 310W (ref. with different model here).
Generally recommended target psu for your config is around 500-550W. You are way below that. I would risk you psu size if it were high effciency unit from well known manufacturer, but it definitely isnt.
Historically fortron bronze certified units did not even pass basic conformace testing under normal load, so you get exactly what you pay for. Little. There are however no reviews or any actual data for this model, so we are going by well deserved reputation and pricepoint only.
Its nor risk worth the price difference between actually proven good units and this cheap ones.
Look its just 100 USD delta between this 500W platinum unit, that will last you years.
TLDR: Cheaping out on PSU is risky, cheaping out on “server” psu is even more unwise.
Try running both cpu and gpu stress test simultaneously and see if it triggers random unexpected shutdown. Proper power testing is out of the question, since we nobody here has either tools or expertise.
Power testing is very underserved area in tech journalism, outside of few enthusiast sites. It really shame, especially once you see how deep the rabbithole really goes.
There is really nothing else to be done here beside running basic tests and replacing components one by one.