Software-issue of hardware defect

[vanaalten]

Situatie: Linux Debian 'stable' machine gebaseerd op een Intel DH67CF moederbord. Draait 24/7 sinds 2011 of zo, met tussendoor een keer een harddisk-naar-SSD vervanging.

Machine is dus als een headless server in gebruik voor DNS, downloaden, mail, websites, met enkel een netwerk-aansluiting, USB aansluiting en voeding aangesloten.

Nou ben ik vorige maand verhuisd en sindsdien is de machine al een keer of vier vastgelopen - niet bereikbaar via SSH, geen bereikbare DNS- mail of webserver en na handmatig uit/aanzetten werkt het weer.

Logfiles: eigenlijk niets vreemds kunnen vinden. '/var/log/syslog' lijkt spontaan te stoppen (en daarna de nieuwe boot logging), enkel soms tussen het stoppen en starten een reeks nul-bytes.

Tot zover zou ik het nog een duidelijk hardware-defect noemen, tot zojuist: eerder vandaag probeerde ik wat te downloaden en dat ging bijzonder traag. Ook een file van buiten uploaden ging dusdanig traag dat het door een timeout faalde. En een uurtje later liep de machine vast.

Dus nu twijfel ik: loopt de machine vast doordat er in de netwerk-software iets volloopt, of wijst dit op een moederbord met o.a. stervende netwerk-controller? Hoe zou ik dat handig kunnen uitsluiten?

(en omdat ik twijfel tussen software of hardware als oorzaak, dit topic dus maar in NOS geplaatst)

[Hero of Time]

Het is mogelijk dat door het 24/7 aan staan de hardware dusdanig is 'versleten' dat het uitstaan vanwege je verhuizing de boel heeft laten 'afkoelen' dat het nu z'n gebreken is gaan tonen. Het is daarom jammer dat het systeem headless is, want als er iets vast zou lopen moet je dat op de TTY zien. Ook als dit resulteert in een kernel panic.

Mechanische schijven hebben dit ook wel eens, zolang ze blijven draaien is er weinig tot niets aan de hand. Reboots is geen issue, want ze stoppen dan niet. Maar zet 'm uit en je zit te bidden dat de schijf weer uit park komt en netjes op spint. Andere hardware kan vergelijkbare effecten krijgen.

Software kan je uitsluiten door het systeem wat nu draait in andere hardware te zetten en de huidige hardware voorzien van een andere disk met verse installatie en die een tijd laten draaien. Degene die vastloopt geeft uitsluitsel wat de reden is.

[vanaalten]

Mja, Klinkt niet onredelijk, wat je schrijft.
Een hardware-defect lijkt mij vooralsnog waarschijnlijker dan software, juist vanwege het gebrek aan log-info.

Binnenkort het ding maar even verplaatsen naar een plek waar ook een monitor staat, wellicht dat ik dan iets meer zie. Ook maar een andere voeding besteld - er zit nu een PicoPSU in, heeft altijd goed gewerkt maar desondanks heb ik er niet heel veel vertrouwen in (of de bijbehorende AC/DC adapter).

Gaat dat niet werken, dan ben ik al bezig met een backup-scenario in een wensenlijstje op te bouwen. Na 10 jaar mag het wel eens door iets nieuws vervangen worden (ook al is de i3-2100 krachtig genoeg voor wat ik nodig heb). Maar eerst eens kijken of het leven van dit ding nog verlengd kan worden.

[Hero of Time]

Als je weet hoe lang het ongeveer duurt voordat het systeem 'crasht' en de diensten die erop staan in die tijd offline mogen zijn, prik je er een USB stick in met een live omgeving en laat je dat even draaien. Heb je dat deel iig uitgesloten. Kan je ook een image maken van de schijf als backup en desgewenst in je wat meer energieslupende computer als VM draaien, in geval de diensten toch niet zo lang offline kunnen/mogen zijn.

[vanaalten]

Gisteren besloten om met 'iperf' eens een bandwidth monitor op te zetten: "iperf -s" met een nohup op een tweede Linux NAS en op de probleemmachine elke 5 minuten "iperf -c nas" en de output geformatteerd naar een file te dumpen - eens kijken wanneer het mis gaat en of er dan in de logbestanden wat te zien is.

Dus...

code:

11/09/2020 06:55:11  -  892.0 Mbyte/s
11/09/2020 07:00:11  -  891.7 Mbyte/s
11/09/2020 07:05:11  -  891.9 Mbyte/s
11/09/2020 07:10:11  -  891.7 Mbyte/s
11/09/2020 07:15:11  -  891.6 Mbyte/s
11/09/2020 07:20:11  -  891.7 Mbyte/s
11/09/2020 07:25:11  -  889.6 Mbyte/s
11/09/2020 07:30:11  -  13.9 Mbyte/s
11/09/2020 07:35:12  -  7.2 Mbyte/s
11/09/2020 07:40:11  -  8.3 Mbyte/s
11/09/2020 07:45:11  -  7.4 Mbyte/s

...strak om 07:30 zakt de boel in elkaar (en Mbyte/s moet Mbit/s zijn). Mja. Toen bedacht ik mij dat ik onlangs met een cron-job om 07:30 wondershaper aanzet om de bandbreedte van m'n server te beperken omdat 'ie anders mogelijk de internetverbinding vult tijdens het thuiswerken.

Ofwel, alles aan netwerkissues die ik dacht te hebben zijn daardoor verklaard - en het incidenteel vastlopen is vooralsnog niet gerelateerd. Vandaag maar eens de voeding vervangen door een nieuwe en dan een tijdje afwachten - en dan ook maar even een monitor & toetsenbord er aan, wellicht dat dat wat duidelijk maakt. Of dat het opgelost is.

Wondershaper vooralsnog maar even uitgezet om het niet onnodig verwarrend te maken. Plus, kan zomaar zijn dat de bandbreedtebegrenzing het bekijken van filmpjes liet stotteren...

[RobinJ1995]

Hardware failure lijkt me de minst-logische verklaring in dit geval. Als je het echt wil weten, dan kan je best het storage medium vervangen en het operating system opnieuw installeren, met zo weinig mogelijk services er op. Als het dan wel goed gaat, lijkt hardware failure unlikely.

[vanaalten]

Mja, ik denk dat het nu standaard hardware troubleshooten wordt.

Omdat ik in eerste instantie een relatie dacht te zien tussen netwerkverkeer, bandbreedte die terugliep en ogenschijnlijk volledig vastlopen, heb ik het topic hier geplaatst met de hoop dat er op OS-niveau misschien meer te vinden was dan ik in de logs kon zien.

Nu blijkt het netwerkprobleem een geval 'user error', dus blijft over een machine die op willekeurige momenten volledig blijft hangen (voor zover dat op een headless machine te beoordelen is). Zonder enige probleemindicatie in de logfile. Dus ik denk dat dit topic daarmee eigenlijk gewoon in PMG moet staan.

Het voordeel dat ik heb: ik heb twee vrijwel identieke machines - de andere, backup-machine, staat praktisch full-time uit, enkel 's-nachts even een paar minuten aan om een volledige harddisk-kopie te maken van de probleemmachine. Dus ik kan redelijk makkelijk hardware uitwisselen of zelfs de backup-machine in gebruik nemen, tot ik weet welke component de oorzaak is (of vaststellen dat het toch een OS-issue is).

Enige wat ik nu nodig heb is tijd - zeker omdat het vastlopen niet heel vaak gebeurd en zeker niet voorspelbaar is.

[Hero of Time]

vanaalten schreef op vrijdag 11 september 2020 @ 15:43:
Dus ik denk dat dit topic daarmee eigenlijk gewoon in PMG moet staan.

U vraagt, wij verplaatsen. Dus bij deze NOS -> PMG.

[vanaalten]

Meh. Vervangen van de voeding heeft niet geholpen, dus onlangs heb ik het systeem uit de TS vervangen door het systeem uit deze post. Hierbij heb ik enkel de SSD overgezet, dus die (de SSD hardware zelf, dan wel het OS er op) zijn nu nog de enige verdachten.

Probleem is nog steeds dat het (linux, Debian 'stable') systeem incidenteel crasht. Laatste echte vastloper liet geen enkele foutmelding in de logfiles zien, maar op het scherm wel een cryptische stack trace.

Maar wellicht nog een aanwijzing: systeem werkt nog prima, geen vastloper gehad, maar desondanks wel een cryptische foutmelding op het scherm:

code:

Sep 30 08:24:30 vanaalten systemd[1]: Started Getty on tty4.
Sep 30 08:24:30 vanaalten systemd[1]: Started Getty on tty2.
Sep 30 08:24:30 vanaalten kernel: [159962.295249] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.19.0-11-amd64 #1 Debian 4.19.146-1
Sep 30 08:24:30 vanaalten kernel: [159962.295338] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H470M-ITX/ac, BIOS P1.20 05/18/2020
Sep 30 08:24:30 vanaalten kernel: [159962.295348] RIP: 0010:cpuidle_enter_state+0xb9/0x320
Sep 30 08:24:30 vanaalten kernel: [159962.295352] Code: e8 9c b5 b0 ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 ce a7 b6 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
Sep 30 08:24:30 vanaalten kernel: [159962.295354] RSP: 0018:ffffbe03019a3e90 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
Sep 30 08:24:30 vanaalten kernel: [159962.295358] RAX: ffff9c1bcf5620c0 RBX: 0000917c1fc829ea RCX: 000000000000001f
Sep 30 08:24:30 vanaalten kernel: [159962.295360] RDX: 0000917c1fc829ea RSI: 000000002c13c01d RDI: 0000000000000000
Sep 30 08:24:30 vanaalten kernel: [159962.295362] RBP: ffff9c1bc4d13000 R08: 0000000000000002 R09: 0000000000021980
Sep 30 08:24:30 vanaalten kernel: [159962.295363] R10: 0001a685134b4b1d R11: ffff9c1bcf5610a8 R12: 0000000000000003
Sep 30 08:24:30 vanaalten kernel: [159962.295365] R13: ffffffff94aba518 R14: 0000000000000003 R15: 0000000000000000
Sep 30 08:24:30 vanaalten kernel: [159962.295368] FS:  0000000000000000(0000) GS:ffff9c1bcf540000(0000) knlGS:0000000000000000
Sep 30 08:24:30 vanaalten kernel: [159962.295370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 30 08:24:30 vanaalten kernel: [159962.295372] CR2: 0000561438923229 CR3: 00000001ef40a006 CR4: 00000000003606e0
Sep 30 08:24:30 vanaalten kernel: [159962.295374] Call Trace:
Sep 30 08:24:30 vanaalten kernel: [159962.295386]  do_idle+0x228/0x270
Sep 30 08:24:30 vanaalten kernel: [159962.296362]  cpu_startup_entry+0x6f/0x80
Sep 30 08:24:30 vanaalten kernel: [159962.296367]  start_secondary+0x1a4/0x200
Sep 30 08:24:30 vanaalten kernel: [159962.296373]  secondary_startup_64+0xa4/0xb0

De twee 'Getty' meldingen waren toevallig op hetzelfde moment als de kernel error, al zie ik daar niets kwalijks in.

Is er hier iemand die zo'n call trace kan uitleggen?

[RobinJ1995]

Is dat all wat er in de stack trace zit, of gaat die nog verder?

[vanaalten]

RobinJ1995 schreef op donderdag 1 oktober 2020 @ 10:52:
Is dat all wat er in de stack trace zit, of gaat die nog verder?

Dat was alles wat er in stond.

Ik heb wel een paar weken geleden van een echte harde crash een foto gemaakt (kwam niet in de logfile terecht, dus kon alleen een screenshot maken - klik voor de grote leesbare versie):


Dat was met de oude hardware, maar lijkt er nu dus op dat het niet aan de hardware lag. Net zelf even op internet zitten speuren... en lijkt er op dat het geen hardware of user error is, maar gewoon een fout in de kernel zelf: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968335

Dus ik ben niet alleen hiermee.
Nu alleen afwachten of met de 4.19.0-11-amd64 kernel inderdaad is opgelost - al lijkt mijn recente calltrace daar een negatieve aanwijzing voor te zijn.

(zou dus wel betekenen dat ik onnodig voor €1100 twee nieuwe systemen heb gekocht...)

[RobinJ1995]

"Interrupt took too long" -- Mogelijk een driverprobleem. Going on a hunch here... Heb je Realtek netwerkapparatuur er in zitten?

[vanaalten]

Bij de screenshot was dat nog een Intel DH67CF, zonder andere insteekkaarten. Die gebruikte alleen een Intel NIC, dus nee: geen Realtek. En die "interrupt took too long" lijkt los te staan van de crash - je ziet die melding al twee keer voor de crash en die na de crash is ook duidelijk later.

En volgens dit topic zou het ook niets ernstigs zijn.

[Hero of Time]

Die foto lijkt wat overeenkomsten met https://bbs.archlinux.org/viewtopic.php?id=257466 te hebben. CPU bug.

De andere melding, cpuidle_enter_state, lijkt op power management van de CPU te lijken. Nou was er vroeger, iig heb ik het bij servers gezien, een issue met C1 states en kon het systeem vastlopen of crashen.

Kijk dus eens of je iets van power management hebt ingesteld om de CPU in idle te zetten zodat het minder energie gebruikt.

[vanaalten]

Hero of Time schreef op donderdag 1 oktober 2020 @ 17:26:
Die foto lijkt wat overeenkomsten met https://bbs.archlinux.org/viewtopic.php?id=257466 te hebben. CPU bug.

De andere melding, cpuidle_enter_state, lijkt op power management van de CPU te lijken. Nou was er vroeger, iig heb ik het bij servers gezien, een issue met C1 states en kon het systeem vastlopen of crashen.

Kijk dus eens of je iets van power management hebt ingesteld om de CPU in idle te zetten zodat het minder energie gebruikt.

Dat heb ik op zich wel, maar niets heel exotisch - vooral C1, C2, C3 enzovoorts enabled.
Maar goed, dit begon dus op een 10 jaar oude Intel DH67CF bord met iets van een core-2-duo processor of zo, maar nu heb ik de hardware dus vervangen door iets moderns - en nu heb ik daarmee dus ook al een vastloper gehad. In beide gevallen een Intel processor, in beide gevallen dezelfde SSD, maar daar houden de overeenkomsten wel op.

Dus, eh... CPU bug, maar dan in twee verschillende CPU's?

Volgens dit topic zou het zich pas voorgedaan hebben met de Debian 4.19.0-10 kernel - zelf heb ik dat niet zo in de gaten gehouden, maar zou best kunnen.

Ik wacht enkel nog op een nieuwe crash zodat ik (a) een foto van het scherm kan maken en de precieze foutmelding ook van het nieuwe systeem heb, en (b) ik weet of de 4.19.0-11 versie het al opgelost heeft.

[Hero of Time]

vanaalten schreef op donderdag 1 oktober 2020 @ 19:26:
Dus, eh... CPU bug, maar dan in twee verschillende CPU's?

Stel je nou een retorische vraag, of ben je echt Spectre en Meltdown vergeten? Natuurlijk kan je dezelfde bug te pakken hebben. C1 state is niet echt nieuw te noemen en als dat nog steeds gezeik levert, dan maakt de leeftijd van de CPU ook niet echt uit. Zet 't eens uit. Wat heb je te verliezen? Hooguit het probleem.

[vanaalten]

Hero of Time schreef op donderdag 1 oktober 2020 @ 19:30:
[...]

Stel je nou een retorische vraag, of ben je echt Spectre en Meltdown vergeten? Natuurlijk kan je dezelfde bug te pakken hebben. C1 state is niet echt nieuw te noemen en als dat nog steeds gezeik levert, dan maakt de leeftijd van de CPU ook niet echt uit. Zet 't eens uit. Wat heb je te verliezen? Hooguit het probleem.

Ah, excuses! Ik dacht dat je een defect in mijn specifieke CPU bedoelde maar nu zie ik in dat je een design-fout in de CPU bedoelde.

Ik wacht nog even af of ik een nieuwe crash krijg (en dan ook de precieze foutmelding erbij kan vastleggen) zodat ik dat bugreport wat er al staat kan aanvullen. En als ik een van die reacties daar mag geloven, dan zou het probleem in een iets oudere kernel (4.19.0-9) nog niet aanwezig zijn. Da's ook wel interessant om te bevestigen. Ja, dan heb ik wel mogelijk een security-bug in m'n systeem, maar daar maak ik mij niet zoveel zorgen om: ik ben niet interessant genoeg om direct aan te vallen en heb geen onbetrouwbare andere mensen op dit systeem.