Vreemde crashes op Debian server

[geez]

We hebben twee identieke Debian machines draaien als servers: gallery: geez (databeest). Beiden draaien Debian 9 (Stretch), gebruiken ECC RAM en zijn identiek op de HDDs na (de server in kwestie heeft 1x WD Red en 2x WD Green in plaats van 3x WD Red, maar dezelfde md-raid configuratie).

/boot en / draaien op een md raid1 van 2x Samsung 850 250GB SSDs, en /home draait op een md raid5 van de 3 HDDs.

Beiden servers draaien recente Linux kernels uit stretch-backports vanwege Ryzen compatibiliteit:

code:

root@fileserver:/# uname -a
Linux fileserver 4.12.0-0.bpo.2-amd64 #1 SMP Debian 4.12.13-1~bpo9+1 (2017-09-28) x86_64 GNU/Linux

Voor install hebben we ook een BIOS update gedaan. Beide servers draaien al 3 maanden als een zonnetje. Nu zien we sinds gisteren zeer vreemde crashes op één van de twee. Gisteren leek het één van de SSDs te betreffen:



Door de

code:

ata1.00: failed command: READ FPDMA QUEUED

dacht ik aan een brakke SATA kabel, plan was dan ook om die vanochtend te vervangen. Echter vanochtend kregen we een tweede crash die niets met de SSD te maken lijkt te hebben (Excuus voor de halve foto... er heeft iemand niet opgelet ):



Op het moment dat dit gebeurde kwam er schijnbaar nog wel nieuwe tekst langs in beeld, hij was niet volledig frozen, maar de server was verder totaal unresponsive op het netwerk en er kon ook niet getypt worden. Beide keren kwam na een reboot de server gewoon weer online.

Tot toe lijken de opties voeding, moederbord, CPU of RAM. RAM testen is makkelijk, we hadden nog 2x4GB non-ECC liggen die daarvoor (terwijl het ECC RAM nog onderweg was) ook een paar dagen prima gedraaid hebben, dus die zitten er nu in.

Ideeën:
- Hardware (lijkt mij het meest waarschijnlijk gezien de ander geen issues heeft)
- Kernel upgrade (4.13 is beschikbaar in stretch-backports)
- CPU microcode update? (Ryzen is een relatief nieuw platform)
- firmware-amd-graphics installen vanwege de discrete VGA (al zijn de servers headless)?
- Deze issue. Helaas weet ik het serienummer van de CPU niet, maar beide CPUs zijn tegelijk aangeschaft, begin augustus. Ik heb kill-ryzen.sh nog niet gedraaid, maar het lijkt me dat deze CPUs van na die issue zijn..

Maar, om de diagnose te bespoedigen wil ik toch even op de collectieve kennis leunen Alvast mijn dank.

[ Voor 22% gewijzigd door geez op 30-11-2017 18:30 ]

[valkenier]

Heb hier op Ubuntu ook een brakke HD. Vervanger ligt klaar. Maar daarbij onlangs ook CPU stuck for aantal seconden. Misschien toch related?

[Thralas]

geez schreef op donderdag 30 november 2017 @ 09:24:
Maar, om de diagnose te bespoedigen wil ik toch even op de collectieve kennis leunen Alvast mijn dank.

Gewoon Googlen. Dan vind je deze:

Bug 196683 - Random Soft Lockup on new Ryzen build

Daar staan 3001 mogelijke workarounds voor je probleem. Ik zou beginnen met de C-states, dat scheelt je het rebuilden van de kernel.

Zo'n read error wijst normaliter op een disk met bad sectors, maar gezien het een SSD is zou dat vreemd zijn. En nog belangrijker: de ATA status is {DRDY}, bij een echte disk error zou ook het ERR-vlaggetje moeten worden gezet denk ik. Google maar eens op READ FPDMA queued.

Ik kan me zo voorstellen dat een core ook kan hangen als 'ie eigenlijk een SCSI response had moeten uitlezen, met als gevolg dat libata een timeout detecteert.

Ik zou dus vooral investeren op die Ryzen lookup, en de SSD even beschouwen als collateral damage.

[geez]

Ik was even het crashen aan het afwachten met het nieuwe RAM. Tot nu toe alles prima met de server in kwestie, maar nu is echter de andere (!) server ook gecrashed, op wat lijkt dezelfde manier (al stond er niets in beeld). Syslog leeg, compleet frozen. Conclusie: Zeer waarschijnlijk dus geen hardware issue.

Heb inmiddels tevens bevestigd dat deze CPUs de nieuwste microcode draaien, en de kernels geupgrade naar 4.13.

Thralas: Dank voor de bug suggestie. Dit lijkt me een goede volgende optie. Ik heb een hoop rondgezocht op internet maar ben die niet eerder tegengekomen, wellicht omdat hij vaak verward werd met de segfault/compiler bug van vroege Ryzen CPUs.

edit: Saillant detail: Heb die hele thread eens doorgelezen. Zoals iemand daar ook noemt, lijken de lockups onafhankelijk te zijn van stress/activiteit op de server. If anything, lijkt idle een belangrijke conditie te zijn. In alle gevallen zijn de servers in de vroege ochtend (tussen 3 en 6) gecrasht. Ik heb namelijk al stress testen gedraaid met stress-ng, en dat lijkt niets te doen. Dat zou inderdaad wijzen op iets met C-states. Ik probeer nu uit te vinden wat de debian kernel parameters zijn, om te zien of ik de boot parameter kan toepassen.

edit2: De Debian kernel maakt geen gebruik van de relevante config optie waardoor ik de boot parameter had kunnen gebruiken, en kernel recompilen is inderdaad pijnlijk. Op dit moment draai ik 24/7 stress-ng op beide servers met 3 cores op 100%, om te kijken of ze dan beiden een week stabiel blijven; dit heeft nog niemand getest dus wellicht kan ik een resultaat toevoegen aan de bug op kernel.org. Hopelijk komt er binnenkort een microcode/BIOS update die het probleem fixt zonder C6 uit te moeten schakelen..

Óók interessant: Probleem is pas op komen dagen na 3.5 maand stabiel draaien. In die tijd 1 random Apache crash gezien op kernel 4.9 (eigenlijk te oud voor Ryzen), verder 100% stabiel. Nu 3 crashes over twee machines in 6 dagen?

[ Voor 54% gewijzigd door geez op 05-12-2017 16:12 ]

[nike]

Ik toevallig ook al 2 dagen bezig met mijn debian machine. Hierop staat proxmox met aantal vms.
Na alles geupdated te hebben had ik ineens vastlopers. Vms bleven hangen en vaak ook de machine.
Nu alles terug gezet en een kernel terug, en nu alles weer stabiel...... Maar wat het nu precies was gee. Idee ook syslog leeg en geen bezondere dingen.

[geez]

@nike : Welke kernel draaide je die niet stabiel was, en welke is wel stabiel?

[nike]

@geez op de vm draai is nu 4.9.0-4-amd64, proxmox draaid op 4.10.15-1

Hellaas heb ik net weer een crash gehad. de VM (gbs) hing, en deze keer heeft hij heel de machine meegenomen en de rest van de vm's ook.
Ik vermoed toch dat mijn gbs vm de boosdoender is want toen ik deze vm op een andere server had draaien crashe hij ook. nu heb ik hem op die andere gezet en nu crashed die.

Dus ik denk conslusie: de software en of die kernel op de gbs VM met 4.9.0-4-amd64 is niet goed.
Ik ga morgen denk ik een kale debian installeren en dan de gbs software er op.

[josvane]

@geez je geeft aan dat ze beide nu crashen. Er zit een verschil tussen wd red en wd green wat issues kan geven met een raid. Weet ik vanuit dit filmpje YouTube: Black Dwarf - Hard Drive Replacement Q&A

[duiveltje666]

nike schreef op dinsdag 5 december 2017 @ 20:59:
@geez op de vm draai is nu 4.9.0-4-amd64, proxmox draaid op 4.10.15-1

Hellaas heb ik net weer een crash gehad. de VM (gbs) hing, en deze keer heeft hij heel de machine meegenomen en de rest van de vm's ook.
Ik vermoed toch dat mijn gbs vm de boosdoender is want toen ik deze vm op een andere server had draaien crashe hij ook. nu heb ik hem op die andere gezet en nu crashed die.

Dus ik denk conslusie: de software en of die kernel op de gbs VM met 4.9.0-4-amd64 is niet goed.
Ik ga morgen denk ik een kale debian installeren en dan de gbs software er op.

Klinkt ook als een niet gepatchte Proxmox .. die heeft 4.13 nu als kernel ..

[nike]

Op de server die crashde had ik juist alles naar de nieuwste gepatched.
Ik vermoed dat de nodejs update roet in het eten gooit.
Als ik mydomoathome update neemt ie nodejs mee.

Toevallig wilde in een sonos api installeren met ook die nodejs en toen crashde het ook.
Nu beide niet geinstalleerd en alles draaid nog.....ik wacht even af.

[geez]

@josvane : De tweede die nu gecrasht is heeft uitsluitend (identieke) WD Red disks. Daarnaast hebben beide servers SSDs in raid1 als root, (HDDs zijn /home), dus klinkt wat sterk dat dit een oorzaak kan zijn van dit probleem. Desalniettemin interessant, zal het filmpje straks even kijken.

@nike : Wat zijn de specificaties van het systeem waar je over praat? Ook een Ryzen systeem?

Servers zijn dit keer beide online gebleven zonder problemen (met stress test aan). Één nacht is echter te kort om wat zinvols te zeggen..

Update: 5 dagen later nog steeds stabiel, met 3 en later 1 core op 100% met stress-ng. Probleem lijkt dus die uit de kernel.org bug te zijn, CPU C6 state. Voor nu houd ik de systemen even zo, hopend op een microcode/BIOS update..

Update 2: Na een maand nog steeds stabiel. Helaas is er in de tussentijd nog geen oplossing voor die C6 bug verschenen Dus denk dat ik C6 maar ga uitzetten...

[ Voor 28% gewijzigd door geez op 10-01-2018 07:59 ]