uncured592

Salut, J'ai eu aussi une série de méchants kernel panic qui a duré plusieurs semaines sur mon serveur c'est une plaie à diagnostiquer, même avec un syslog externe sur un autre serveur j'avais que dalle. Comme toi, les traces syslog s'arrêtaient puis reprenaient au redémarrage, pas vraiment utile donc. Dans un premier temps je conseillerais de revoir la partie matos (cable sata, pate thermique et ventirad, ...) mais j'ai l'impression que c'est déjà fait. Consulte aussi ce thread : https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173 Il contient des informations spécifiques aux Ryzen qui ne semble pas aimer les C-States. D'ailleurs quelques conseils d'ordre général qui m'avait été donné par JorgeB : Load BIOS defaults and disable XMP (ou son équivalent chez AMD), overclocking, undervolting, or other performance tuning (y compris les c-state). Boot Unraid in Safe Mode, ensuring the any script and other third-party power-management changes are not applied. Initially test with the array stopped. If stable for at least 24 hours, start the array while leaving Docker and VMs disabled. If that remains stable, enable Docker and bring containers back in small groups. Despite the previous successful Memtest result, consider another extended test. Testing one DIMM at a time may help identify an intermittent DIMM, slot, CPU memory-controller, or motherboard issue. if another crash occurs, capture the beginning of the panic directly from the local console. The initial BUG/Oops lines, CPU/task information, registers, and complete call trace are the most important parts. Note aussi les heures de crash et regarde si ça ne correspond pas à des lancements de traitements (sur plex/jellyfin ou autre) ça peut t'aiguiller sur une piste. Si ta clef USB faiblit tu devrais voir des erreurs dans le syslog et/ou via la commande dmesg. Sinon tu peux aussi nous fournir un fichier diag et le retour de la commande dmesg histoire de voir s'il y a des trucs louches.

Two days later and still no issue despite some heavy load from a jellyfin stack I forgot to shut down. syslog/dmesg look clean. The parity check has finished with 3048 errors which is kind of expected considering all the kernel panic I had in the past week. Overall I think the culprit was the CPU cooler that was not correctly mounted which reduced its efficiency. The kernel panics were mostly during the night when the plex/jellyfin workload was happening (opening detection, ...) so precisely when the load was high on the p-cores. I'll have to find a way to send notifications in case of high temperature.

Small update : I have been running for two weeks without any issue, then I had more and more kernel panic, the server could not even make it to 24h of uptime, sometime a couple of hours. Of course it happened when I was not at home, I could barely reboot the server with my nanokvm with tailscale help. Anyway, I unracked the 4U server and made some cleanup : Change of the thermal paste of the CPU and I moved from the default intel cpu cooler to a Thermalright Phantom Spirit 120 SE. Changing the faulty sata cable. I have some doubt on the intel provided cpu cooler I was using : While unscrewing it I noticed that one of its mounting pins wasn’t properly inserted into the motherboard, the pressure wasn’t evenly distributed across the CPU die. When I had those kernel panics, once I kept a nanokvm session opened on the unraid GUI and I'm pretty sure it shown a temp at 95°C at the bottom of the ui. I also have some doubt on the CPU itself, as the 14700 has some thermal issue, but I couldn't find anything conclusive with stress-ng. The memory has also been tested with memtest86 (the version embedded with unraid) but I couldn't make it crash. The server has been restarted and I'm now waiting for to see if it is crashing again.

Comme te l'as suggéré @waazaa boot en safe mode. Tu peux aussi tester ta ram avec memtest.

Thank you ! I'll stay like this for a while to see if I have a kernel panic again (most likely tonight), then I'll follow your list. But I'll replace the sata cable for sure. Update : No kernel panic for the latest 24h and I was able to complete the parity check, as a side note there is also no more connectivity issue with my parity disk anymore.

Here's the unfiltered syslog from the external host. And the kernel panic time I remember : 27/08/2026 around 01h34 26/08/2026 at 04h05 syslog.zip

I have an external syslog on another host. Nothing in the logs, the server just stop logging, here it is : I suspect the kernel panic happened after 01h34. There are some issues before that (a faulty disk connectivity with ata8) but it was 30 minutes before.

Hello, Since a week I have frequent kernel panics, the uptime is < 24h. No hardware or software changes. Motherboard BIOS is up to date. My server is headless so I do not have a trace of the kernel messages. I do have a partial feedback from my kvm over ip : For now I tried : memtest86, OK. Disabling uneeded containers, no effect Following the latest kernel panic I disabled c-states and energy related features in the bios as the kernel messages seems to be energy efficiency related. unraid-diagnostics-20260826-1700.zip

I'm curious where you'll draw the line for docker compose management : I used portainer, komodo and now dockhand to manage my stacks on my unraid server, the compose files are hosted on private github repos. It is so easy to update my stacks on github (versioning, branching, ...) that I would never go back for less feature-wise.

Test en changeant le disque de port ou via un adaptateur usb ? Est-ce que le disque disparait aussi du bios ?

Hello, Jamais essayé pour ma part, cela dit je pense que ton usage est correct. Jette un coup d'oeil aux logs ou poste ton fichier diag dans le topic officiel du plugin officiel : https://forums.unraid.net/topic/120567-unassigned-devices-preclear-a-utility-to-preclear-disks-before-adding-them-to-the-array En tout cas c'est une erreur qui revient souvent. Sinon il semble qu'un mauvais cable sata peut causer ce genre d'erreur.

Pour ma part la vérif avait pris quelques secondes aussi, c'est les sauvegardes au début qui étaient le plus long.

Salut, J'ai récupéré ma base avec ce soft il y a quelques temps : https://github.com/ChuckPa/DBRepair Il fonctionne plutot bien, il suffit d'entrer dans le conteneur comme tu l'as déjà fait, et de se mettre au même niveau que le /config. Un wget de l'URL du script sur le dépot github, ne pas oublier un chmod +x pour le rendre executable et de lancer le script. Après depuis le script tu peut arrêter proprement PMS et faire des traitements sur la base (check/repair/...) En tout cas pour moi ça m'a évité de faire une RAZ de la base.

I know that it is also determined by the hardware but I think there may some options to have unraid be more power efficient out of the box : Powertop (already available thanks to a package from mgutt) TLP (https://github.com/linrunner/TLP) cpu-autofreq (https://github.com/AdnanHodzic/auto-cpufreq) If one want to make its unraid server more power efficient it is a real challenge with limited options. I think helping people achieving this would be a great feature as depending of where you live energy efficiency is something important.

Hi, Be sure that your docker.img file is on your cache disk and not on your array.