Proxmox lockups door NVME drive?

[RobertMe]

Beste,

Een tijdje terug heb ik een nieuwe (zelfbouw) NAS samengesteld, dit op basis van:
pricewatch: Fujitsu D3644-B
pricewatch: Kingston A2000 500GB
pricewatch: Intel Core i3-9100 Boxed
pricewatch: Kingston KSM26ED8/16ME

Echter ervaar ik laatste dagen lockups van het systeem, waarbij de enige "fix" een reset is. Ik heb een keer na het aansluiten van een monitor errors gezien in relatie met de NVME drive, maar deze error helaas verder niet genoteerd dus die weet ik niet meer behalve dus "iets met NVME dat niet werkt(e)". Gevolg daarvan is echter dat ZFS waar (o.a.) het root filesystem de pool (rpool bij Proxmox) eruit gooit "Pool rpool has encountered an uncorrectable I/O failure and has been suspended." uit mijn hoofd (in ieder geval dat rpool suspended is). En dit heeft uiteraard als gevolg dat het hele systeem niet meer werkt en ik een reset moet doen.

Echter heb ik ook geen logging. Enerzijds heb ik het idee dat systemd / journald deze niet persistent doet opslaan (aangezien na een reboot er niks meer is), maar anderzijds vermoed ik dat in het geval van wel persistent opslaan die alsnog "de error" niet zal opslaan, want de disk doet/deed het niet en is door ZFS eruit gegooid.

Dingen die ik zelf al heb geprobeerd zijn, nouja, vrij weinig. Want ik heb geen idee waar te beginnen. Zoals aangegeven, ik heb 1x een error in relatie met de NVME drive gezien, en verder loopt het scherm vol met de ZFS errors (pool rpool suspended). Daarnaast heb ik dus geen logging waar iets uit kan blijken. En helaas heb ik niet eens concrete steps to reproduce.
Enige gok die ik heb is dat het te maken heeft met Docker, omdat beide dagen dat ik de errors had ik wat containers heb geupdate en geherstart. Waarbij ik de volgende (complexe ) setup draai:
1. Op Proxmox heb ik een unprivileged LXC container met alle trucjes om docker te draaien
2. Omdat in de LXC container ZFS niet werkt maak ik als "extra" een ZVOL aan
3. Deze ZVOL formateer ik met ext4
4. En het ZVOL wordt gemount op /var/lib/docker in de LXC container
Hierdoor kan Docker dus gewoon met overlayfs / de overlay2 driver werken. Maar of dit de I/O errors veroorzaakt heb ik geen idee van.

Overigens heb ik wel met smartctl de drive bekeken, maar daar blijkt "niks" uit. En heb ik dd een 100GB file laten schrijven (rechtstreeks op de rpool / in home drive binnen Proxmox).

Wie o wie kan mij dus hiermee helpen, of waar überhaupt te beginnen?
Mogelijke antwoorden hebben dan ook een bereik van concreet de NVME drive testen of deze faalt, tot andere hardware gerelateerde tips, tot aan tips om wel concrete informatie te krijgen over wat er mis gaat. Want Linux "ziet" dus wel iets en dumpt dat naar het scherm, maar aangezien ik het potentieel pas een half uur of nog later merk is het scherm al volgelopen met de ZFS errors m.b.t. suspended pool.

Alvast bedankt

[Thralas]

RobertMe schreef op zondag 29 maart 2020 @ 15:32:
Want Linux "ziet" dus wel iets en dumpt dat naar het scherm, maar aangezien ik het potentieel pas een half uur of nog later merk is het scherm al volgelopen met de ZFS errors m.b.t. suspended pool.

Zonder logging ga je dit niet oplossen, een beetje gissen is zinloos als de SMART logs leeg zijn.

Geen logging naar disk kunnen schrijven is vervelend, helemaal als je rootfs verdwijnt, maar er zijn voldoende alternatieven:

• Open ssh-sessie met `cat /dev/kmsg`. Heeft me nog nooit in de steek gelaten.
• netconsole
• Logs naar een ander filesystem schrijven

Enige dat ik me zo kan voorstellen is iets met powersaving - voorbeeld: CurlyMo in "Het grote zuinige server topic - deel 2"

[RobertMe]

@Thralas ik heb inderdaad net even gekeken naar het kunnen loggen. Systemctl / journalctl zou nu zowel persistent moeten loggen (gebeurde dus niet) en dan ook nog eens naar een andere ZFS pool. Hopelijk dat daar dus iets nuttigs bij zit.

Die SSH variant kan ik ook nog proberen. M'n oude NAS draait nog dus die kan ik gewoon 24/7 "laten meekijken".

De post van CurlyMo m.b.t. zijn m-sata had ik ook gezien (volg dat topic sowieso), maar heb (nog) niks van powertop draaien dus kans daarop lijkt mij klein, gezien het bij hem IIRC door powertop werd getriggerd.

Edit:
Intussen ook maar de SSH variant gestart in een screen + schrijven naar een file vanaf de oude NAS. Als het probleem dan weer optreed heb ik tenminste twee mogelijkheden tot logs terug toveren waarvan hopelijk eentje werkt.

[ Voor 17% gewijzigd door RobertMe op 30-03-2020 21:24 ]

[tonmes]

Voor mij is het herkenbaar met mijn vergelijkbare configuratie (D3642-B met de 1TB versie van de A2000). Ook ik had last van lockups, meestal na een aantal dagen. Omdat ik de A2000 ook als rpool gebruikte (en geen remote logging), was bij mij evenmin iets in de logging te zien. Toen ik een monitor aansloot, zag ik daar wel foutmeldingen die aangaven dat de A2000 disconnected was geraakt. Op basis van gevonden tips heb ik nog de link_power_management_policy naar medium gezet (zie tip eerder in dit topic), maar dat hielp ook niet. Ik heb de A2000 daarom maar in mijn (Windows) PC geplaatst. Daar doet 'ie het tot nu toe probleemloos (power management op medium), maar de PC staat ook niet langdurig (dagenlang) aan.
Met een reguliere SSD heb ik in proxmox sindsdien geen lockups meer gehad. Ik twijfel nu of ik het nog met een andere nvme-disk ga proberen. Ik weet immers niet of het aan de A2000, de D3642-B of een combinatie van beiden lag (of toch ergens een configuratie in proxmox/linux).

[RobertMe]

tonmes schreef op dinsdag 31 maart 2020 @ 17:49:
Voor mij is het herkenbaar met mijn vergelijkbare configuratie (D3642-B met de 1TB versie van de A2000). Ook ik had last van lockups, meestal na een aantal dagen. Omdat ik de A2000 ook als rpool gebruikte (en geen remote logging), was bij mij evenmin iets in de logging te zien. Toen ik een monitor aansloot, zag ik daar wel foutmeldingen die aangaven dat de A2000 disconnected was geraakt. Op basis van gevonden tips heb ik nog de link_power_management_policy naar medium gezet (zie tip eerder in dit topic), maar dat hielp ook niet. Ik heb de A2000 daarom maar in mijn (Windows) PC geplaatst. Daar doet 'ie het tot nu toe probleemloos (power management op medium), maar de PC staat ook niet langdurig (dagenlang) aan.
Met een reguliere SSD heb ik in proxmox sindsdien geen lockups meer gehad. Ik twijfel nu of ik het nog met een andere nvme-disk ga proberen. Ik weet immers niet of het aan de A2000, de D3642-B of een combinatie van beiden lag (of toch ergens een configuratie in proxmox/linux).

Hmm, mogelijk dan dus een compatibiliteitsissue. Lekker dan als dat zo is.

Overigens heeft die ook een hele tijd wel goed gedraaid. Dus weken achter elkaar (ergens in januari in elkaar gezet en heeft "tussendoor" goed gedraaid). Natuurlijk ook jammer dan dat omruilen dan sowieso niet meer gaat lukken gezien zichttermijn verlopen etc.

In ieder geval dan even afwachten wat de logging zegt als het weer optreedt. Maar het zou zomaar kunnen dat ik die ene keer dat ik wel heb gezien dat inderdaad iets van disconnected was.

[RobertMe]

En alweer een crash/lockup. Helaas bleek de logging via SSH nog niet te werken en faalde ZFS mount naar /var/log/journal (want al beschreven door systemd, oeps). Gelukkig een foto gemaakt voor reset.

nvme nvme0 I/O 513 QID 1 timeout, aborting
nvme nvme0 I/O 514 QID 1 timeout, aborting
nvme nvme0 I/O 515 QID 1 timeout, aborting
nvme nvme0 I/O 943 QID 2 timeout, aborting
nvme nvme0 I/O 944 QID 2 timeout, aborting
nvme nvme0 I/O 513 QID 1 timeout, reset controller
nvme nvme0 I/O 4 QID 0 timeout, reset controller

[CurlyMo]

Het kost je niks om toch even de link_power_management_policy te checken.

[RobertMe]

CurlyMo schreef op zondag 5 april 2020 @ 08:03:
Het kost je niks om toch even de link_power_management_policy te checken.

Goede opmerking, maar niet gedaan omdat:

1. Ik geen powertop draai
2. De comment van @tonmes aangeeft dat het niet werkt
3. Ik redelijk wat heb nagekeken van APST en niks geks zag
4. De foutmeldingen mij niet power related lijken
5. Ik gisteren de installatie gesloopt heb *

* Oude HDD erbij gezet voor mirror met de NVME drive. Vervolgens wat veel en snel gewisseld (opeenvolgend de een / ander op offline zetten zonder scrub/resilver tussendoor) en daardoor de pool gesloopt (conflicterende metadata?). Intussen wel bootable door een dataset niet meer te automounten, maar LXC is nu kapot. Dus systeem is nog steeds niet bruikbaar en even paar dagen laten draaien om misschien een error te triggeren is wat mij betreft dan ook geen optie meer in deze staat.
On the bright side: ik weet intussen wel dat de drive de nieuwste firmware bevat, dus daar lag het niet aan.

[CurlyMo]

@RobertMe Punt blijft dat het je niks kost het te verifiëren. Al het andere is eigenwijzigheid. @tonmes geeft aan alleen medium geprobeerd te hebben. Niet performance.

Ok, je installatie mollen helpt ook niet.

[RobertMe]

CurlyMo schreef op zondag 5 april 2020 @ 08:51:
@RobertMe Punt blijft dat het je niks kost het te verifiëren. Al het andere is eigenwijzigheid. @tonmes geeft aan alleen medium geprobeerd te hebben. Niet performance.

Ok, je installatie mollen helpt ook niet.

Intussen heb ik de boel weer volledig draaiende. Zondag herinstallatie gedaan op een oude (SATA) SSD en de belangrijke containers opnieuw aangemaakt en datasets van de andere / kapotte installatie over gezet. Vandaag de laatste beetjes gedaan.

Nu even de NVME SSD in mijn normale PC geplaatst en opgestart. Alle link power management policies staan op max_power. Dus of dat is niet het issue, of het andere (oudere) moederbord voorkomt lagere policies. Nu alleen nog even kijken of/hoe ik dit ga testen in combinatie met het Fujitsu bord.
Ik denk dat ik gewoon een clean install ga doen, de root pool over zetten vanaf de SSD waarop het nu draait maar meteen de boel zo ingericht dat de volledige rpool met alle children gebackupped wordt naar een los systeem, NVME drive terug plaatsen op het Fujitsu bord en dan weer zo verder draaien. En dan kan ik dan meteen weer op het Fujitsu bord kijken wat de power management policy is.

[raymondw]

#my 2c

Ik draai al jaren verschillende clusters thuis op consumer HW.
Moederborden, geheugen CPU's, alles is eigenlijk wel oke.
Op storage na, consumer flash drives zijn gewoon niet opgewassen tegen 24/7 gebruik.

Mijn oplossing met falende drives was om toch over te gaan naar Enterprise materiaal.
Het huidige cluster draait op Micron MAX drives gekocht via V'EN'A : Piet Snot

Data verbruik is best hoog met redundante lokale mailservers, Gitlab, DNS, 3 HD cams via Zoneminder etc etc etc

Zou je adviseren om de consumer meuk er uit te gooien en voor wat stabielers te gaan.
Garantie? Nee
Maar het werkt nu ook niet goed

[Q]

Voor wat mijn mening waard is: ik vind het wat ver gaan om consumenten SSDs per definitie af te schrijven.
Laten we eerst maar eens zien of het een power management issue is.

En dan nog: het kan gewoon pech zijn, een incompatibiliteit tussen het moederbord en deze specifieke nvme drive. Firmware/Bios issue, of heel misschien een power issue, alhoewel ik die kans klein acht.

Ik draai met consumenten SSDs als boot schijven (geen intensieve workload) en dat gaat al jaren prima.Ik heb flink wat langdurige, zeer zware loads op datacenter en consumenten SSDs gedraaid (random I/O benchmarks met fio, voor uren) en nog nooit uitval gehad zoals in dit topic beschreven.

Misschien helpt het om met fio ook een zware io benchmark te starten, met een random read/write benchmark om zo een flinke load te genereren. Zo kun je ofwel consequent relatief snel het probleem reproduceren en ook dus snel vast stellen of aanpassingen tot het gewenste resultaat hebben geleid.

code:

fio –filename=/<folder>/testfile.bin --size=50G –direct=1 –rw=randrw –refill_buffers –norandommap –randrepeat=0 –ioengine=libaio –bs=4k –rwmixread=50 –iodepth=16 –numjobs=16 –runtime=3600 –group_reporting –name=4ktest

Dit geeft een lekkere 50% read/write mix en de qd en jobs zetten de SSD goed aan het werk.

[ Voor 39% gewijzigd door Q op 10-04-2020 22:41 ]

[rachez]

Q schreef op vrijdag 10 april 2020 @ 22:35:

En dan nog: het kan gewoon pech zijn, een incompatibiliteit tussen het moederbord en deze specifieke nvme drive.

Dat denk ik ook.

Heb je geen sata ssd liggen die je even als test kan gebruiken, of het daarmee ook optreedt?
Mijn ervaring met dit soort issues is dat je zaken moet gaan uitsluiten dmv hardware wisselen.

[RobertMe]

Q schreef op vrijdag 10 april 2020 @ 22:35:
Misschien helpt het om met fio ook een zware io benchmark te starten, met een random read/write benchmark om zo een flinke load te genereren. Zo kun je ofwel consequent relatief snel het probleem reproduceren en ook dus snel vast stellen of aanpassingen tot het gewenste resultaat hebben geleid.

code:

fio –filename=/<folder>/testfile.bin --size=50G –direct=1 –rw=randrw –refill_buffers –norandommap –randrepeat=0 –ioengine=libaio –bs=4k –rwmixread=50 –iodepth=16 –numjobs=16 –runtime=3600 –group_reporting –name=4ktest

Dit geeft een lekkere 50% read/write mix en de qd en jobs zetten de SSD goed aan het werk.

Dat kan ik nog wel testen een dezer dagen. Vooral het feit dat ik niet weet hoe het te triggeren maakt uitzoeken (en oplossen) "onmogelijk". Soms lijkt het tijden goed te gaan (eigenlijk dus 1 of 2 maanden tot 2, 3 weken terug) en de volgende keer is bv weer binnen 5 minuten na opstarten.

[RobertMe]

rachez schreef op vrijdag 10 april 2020 @ 22:42:
[...]


Dat denk ik ook.

Heb je geen sata ssd liggen die je even als test kan gebruiken, of het daarmee ook optreedt?
Mijn ervaring met dit soort issues is dat je zaken moet gaan uitsluiten dmv hardware wisselen.

Heb het nu sowieso op een antieke SATA SSD draaien (ik denk Intel 320, nog voordat SSDs "mainstream" waren (bah wat een verschrikkelijke term)). Maarja, dat dat nu goed gaat voor nog geen week (incl. de nodige reboots tussendoor) zegt dan ook weer niks. Enige optie dan met testen is dat ik ga draaien op het moederbord van m'n gewone PC, want die heeft ook een M.2 slot.

En die is toch kapot en al maanden niet meer gebruikt Op tijd van 1, 2 maanden zowel in oude / "nu half vervangen" NAS en m'n gewone PC falende HDD met bad sectors. Die laatste dan nog steeds niet naar gekeken.

[Wiebeltje]

Kijk ook eens in je bios en zet daar power saving opties uit. Ik heb ook ooit freezes gehad met Proxmox. Bij mij was het op mijn SATA SSD. ACPI was het als ik me niet vergis. Is inmiddels al een paar jaar geleden. Sindsdien draait ie 100% stabiel.

Feezes waren ook compleet random en echt eens in de x weken / maanden

[ Voor 14% gewijzigd door Wiebeltje op 10-04-2020 23:22 ]

[dcm360]

Q schreef op vrijdag 10 april 2020 @ 22:35:
Voor wat mijn mening waard is: ik vind het wat ver gaan om consumenten SSDs per definitie af te schrijven.
Laten we eerst maar eens zien of het een power management issue is.

En dan nog: het kan gewoon pech zijn, een incompatibiliteit tussen het moederbord en deze specifieke nvme drive. Firmware/Bios issue, of heel misschien een power issue, alhoewel ik die kans klein acht.

Ik draai met consumenten SSDs als boot schijven (geen intensieve workload) en dat gaat al jaren prima.Ik heb flink wat langdurige, zeer zware loads op datacenter en consumenten SSDs gedraaid (random I/O benchmarks met fio, voor uren) en nog nooit uitval gehad zoals in dit topic beschreven.

De vraag is dan wel, draai je ook Proxmox? Proxmox staat er om bekend dat het zeer veel writes naar de boot-disk doet, en veel consumenten-ssd's kunnen daar gewoon niet zo goed tegen.
Neemt niet weg dat ervaringen kunnen afwijken, bij mij is het tot zover half om half: Een stokoude Kingston SSDNow V+ V2 kan er meer overweg, net als de Intel 760P, maar 2 SSD's van Crucial (een M500 en MX200) gingen vrij snel al moeilijk doen. Ik zal de Intel Optane 900P ondanks de positionering van Intel maar niet meerekenen als consumentenschijf in dit geval, aangezien je in die prijscategorie ook al leuke schijven kan krijgen die gemaakt zijn voor gebruik in servers.

[Q]

@RobertMe Je lijkt meerdere issues te hebben met meerdere apparaten, maar focus ff op 1 ding en probeer dat af te ronden.

Mijn advies zou zijn:

1. Stop de NVME in je Fujitsu moederboard als hij er al niet in zit
2. Ga eens een uur lang die (apt install) fio draaien en 'kijken wat ie doet'. Doe dit een stuk of 3x als je in staat bent om het probleem te reproduceren. Dan weet je ook of 1 x crash geen eenmalige fluke is.
3. Ga eens een uur lang die fio draaien op een andere computer waar die NVME schijf in kan: geen problemen, dan is de NVME schijf prima. Ook problemen: NVME niet lekker?

Heb je de errors bij stap 2? Dat is ruk maar ook mooi: je kunt het probleem reproduceren.

Nu is het handig (en niet eerder!) om het advies van @Wiebeltje te implementeren.
Draai vervolgens weer de test van stap 2.

Als je direct Wiebeltjes oplossing implementeert zonder van te voren te testen dan heb je geen idee of het prolbeem is opgelost. Als je Wiebeltjes oplossing implementeert en daarna past gaat testen weet je niet of de fio test het probleem wel kan reproduceren.

[Q]

dcm360 schreef op vrijdag 10 april 2020 @ 23:06:
[...]

De vraag is dan wel, draai je ook Proxmox? Proxmox staat er om bekend dat het zeer veel writes naar de boot-disk doet, en veel consumenten-ssd's kunnen daar gewoon niet zo goed tegen.
Neemt niet weg dat ervaringen kunnen afwijken, bij mij is het tot zover half om half: Een stokoude Kingston SSDNow V+ V2 kan er meer overweg, net als de Intel 760P, maar 2 SSD's van Crucial (een M500 en MX200) gingen vrij snel al moeilijk doen. Ik zal de Intel Optane 900P ondanks de positionering van Intel maar niet meerekenen als consumentenschijf in dit geval, aangezien je in die prijscategorie ook al leuke schijven kan krijgen die gemaakt zijn voor gebruik in servers.

Nee ik doe niets met Proxmox, mijn situatie is niet zo vergelijkbaar. Wie weet heb je gelijk onder de condities van Proxmox.

Maar snappen doe ik het niet.

De M500 heeft een endurance van ~40 Gigabytes per dag aan writes voor 5 jaar. De MX200 heeft dat ook, grofweg (en daarbij keek ik naar het kleinste model).

Ga je mij vertellen dat Proxmox (meer dan) 40 gigabytes per dag naar de schijven schrijft?

Wat waren je problemen precies dan?
Wat waren de symptomen?

Ik heb zelf de MX200 (drie stuks) aan flink wat zware, langdurige load tests onderworpen inclusief volledige disk writes en ik heb nooit rare latency spikes ofzo tegen gekomen.

[ Voor 6% gewijzigd door Q op 10-04-2020 23:25 ]

[dcm360]

Q schreef op vrijdag 10 april 2020 @ 23:21:
[...]


Nee ik doe niets met Proxmox, mijn situatie is niet zo vergelijkbaar. Wie weet heb je gelijk onder de condities van Proxmox.

Maar snappen doe ik het niet.

De M500 heeft een endurance van ~40 Gigabytes per dag aan writes voor 5 jaar. De MX200 heeft dat ook, grofweg (en daarbij keek ik naar het kleinste model).

Ga je mij vertellen dat Proxmox (meer dan) 40 gigabytes per dag naar de schijven schrijft?

Wat waren je problemen precies dan?
Wat waren de symptomen?

Ik heb zelf de MX200 (drie stuks) aan flink wat zware, langdurige load tests onderworpen inclusief volledige disk writes en ik heb nooit rare latency spikes ofzo tegen gekomen.

Mijn 'router' heb ik nu een half jaar, en de TBW staat op 6.4TB, en daar draaien slechts 2 meestal idle VM's en een container op. Dat komt akelig dicht in de buurt van de 40GB/dag die je noemt, en ze zaten in een systeem waar ruim meer op draaide. TRIM werd destijds nog niet ondersteund door ZFS, dus de schijven moesten er zelf mee overweg kunnen.
Naast dat de schrijfsnelheid voor het wegschrijven van wat grotere bestanden met slechts een 10-tal MB/s ging, was het grootste probleem dat er latency spikes van seconden ontstonden. Daardoor werd timeshiften vanaf een dvb-tuner onbetrouwbaar.
De problemen bleven een tijdje weg na een volledige trim of secure erase, dus waarschijnlijk zouden mijn problemen nu voorkomen kunnen worden door regelmatig een zpool trim te draaien.

[Q]

dcm360 schreef op zaterdag 11 april 2020 @ 09:11:
[...]

Mijn 'router' heb ik nu een half jaar, en de TBW staat op 6.4TB, en daar draaien slechts 2 meestal idle VM's en een container op. Dat komt akelig dicht in de buurt van de 40GB/dag die je noemt, en ze zaten in een systeem waar ruim meer op draaide. TRIM werd destijds nog niet ondersteund door ZFS, dus de schijven moesten er zelf mee overweg kunnen.
Naast dat de schrijfsnelheid voor het wegschrijven van wat grotere bestanden met slechts een 10-tal MB/s ging, was het grootste probleem dat er latency spikes van seconden ontstonden. Daardoor werd timeshiften vanaf een dvb-tuner onbetrouwbaar.
De problemen bleven een tijdje weg na een volledige trim of secure erase, dus waarschijnlijk zouden mijn problemen nu voorkomen kunnen worden door regelmatig een zpool trim te draaien.

Het is helemaal waar dat datacenter SSDs gewoon 100% constante performance geven zonder latency spikes, zelfs als je ze helemaal vol maakt.

Consumenten SSDs kunnen zich onvoorspelbaar gedragen zoals jij beschrijft als ze goed vol zitten en ze continue blocks moeten erasen.

Maar dat lijkt niets te maken te hebben met het probleem wat de topic starter hier heeft.

Voor wat jouw situatie, je geeft zelf al antwoord: trim draaien op de consumenten schijfjes of dan maar een DC SSD kopen.

Wat me wel verbaasd is het feit dat jouw setup effectief ~0.45 MB/s schrijft 24/7/365 en dat vind ik niet normaal, ongeacht of je Proxmox draait of niet. Maar misschien mis ik hier kennis, is er een artikel ergens over dit fenomeen? Of heeft dit meer te maken met de workload van jouw specifieke situatie?

[RobertMe]

Update:
Vanmorgen geprobeerd om fio te draaien met de NVME drive in mijn PC, maar die leek het niet echt te doen. File werd ook niet groter dan 512B, in combinatie met dat ik daarna zag dat dmesg al stacktraces had gedumpt van voordat ik inlogde. Dus maar meteen een clean install gedaan van Proxmox.

@Q ik heb fio nu twee keer laten lopen. Een keer met de drive op mijn gewone PC en een keer op het Fujitsu bord. Pas bij de run op het Fujitsu bord viel mij de enorme dump aan performance (?) output op. Op PC had ik dat helemaal gemist En daar leek in een snelle blik geen fout in te zitten. Zijn er daarbij dus nog dingen om specifiek op te letten? Ik heb nu in ieder geval ook nog een derde run aan gezet.

@CurlyMo nu op de nieuwe installatie ook nog eens de power management policy gecheckt, en deze is ook daar max performance.
Maar wat ik me nu sowieso afvraag. scsi is volgens mij sata gerelateerd? Waar jij het probleem ook had met een m-sata drive. Maar in hoeverre is het dan überhaupt relevant voor een NVME drive?

En algemene vraag: in hoeverre kun je een M.2 drive niet goed aansluiten? In de zin van: kan een los contact dit issue veroorzaken en dat door het wisselen/opnieuw aansluiten dat probleem nu is opgelost.

[Q]

RobertMe schreef op zaterdag 11 april 2020 @ 15:13:
@Q ik heb fio nu twee keer laten lopen. Een keer met de drive op mijn gewone PC en een keer op het Fujitsu bord. Pas bij de run op het Fujitsu bord viel mij de enorme dump aan performance (?) output op. Op PC had ik dat helemaal gemist En daar leek in een snelle blik geen fout in te zitten. Zijn er daarbij dus nog dingen om specifiek op te letten? Ik heb nu in ieder geval ook nog een derde run aan gezet.

@RobertMe Het gaat in dit geval eigenlijk niet om de output van fio, alhoewel je die best even op pastebin kunt gooien (of wat uitkomt) voor analyse, lijkt me eigenlijk wel interessant.

Het doel was om - indien er iets niet goed zou zijn - om weer zo'n disconect te triggeren, zoals je die eerder hebt afgevangen. Fio is dan niet meer een zware load-test om het probleem te kunnen reproduceren.

Wat ik nu van jou echter begrijp, is dat FIO een uurtje of wat loopt en dan klaar is (hele drive is gelezen/beschreven) zonder dat jij eerder genoemde dikke errors kreeg, klopt dat?

[ChaserBoZ_]

Je hebt het over Proxmox en over een NAS; pass je je opslag door om de NAS virtueel te draaien op Proxmox, en dan ernaartoe connecten vanuit Proxmox ?

[RobertMe]

Q schreef op zaterdag 11 april 2020 @ 16:40:
Het doel was om - indien er iets niet goed zou zijn - om weer zo'n disconect te triggeren, zoals je die eerder hebt afgevangen. Fio is dan niet meer een zware load-test om het probleem te kunnen reproduceren.

Daar ging ik eigenlijk ook vanuit ja.

Wat ik nu van jou echter begrijp, is dat FIO een uurtje of wat loopt en dan klaar is (hele drive is gelezen/beschreven) zonder dat jij eerder genoemde dikke errors kreeg, klopt dat?

Klopt, hij heeft 1x 1 uur gedraaid in m'n PC en intussen 2x 1 uur op het Fujitsu bord. Alle drie de keren zonder problemen.

[RobertMe]

ChaserBoZ_ schreef op zaterdag 11 april 2020 @ 16:46:
Je hebt het over Proxmox en over een NAS; pass je je opslag door om de NAS virtueel te draaien op Proxmox, en dan ernaartoe connecten vanuit Proxmox ?

In principe bedoel ik daarmee hetzelfde. Proxmox zal de basis vormen voor m'n thuisserver / NAS / .... Samba ga ik dan in LXC container draaien, mountpoints. Verder staat Proxmox en de containers etc gewoon op de NVME SSD.

[RobertMe]

Nieuwe update:
Gisteren de NVME drive terug geplaatst, met gewoon Proxmox er op en dus weer als (enige) OS drive, en net was het weer raak. Tegen de tijd dat ik er achter kwam was output naar monitor uiteraard alweer vol gelopen met ZFS errors dus weer niks kunnen zien.
Denk dat ik maar die andere SSD ga bijwerken met de laatste dingen (afgelopen ~36 uur), want zijn nu twee onafhankelijke ZFS pools, en vervolgens de NVME drive in mirror er aan hangen. Dan kan die falen maar blijft systeem werken en heb ik dus ook logs. Gezien loggen van journalctl dus faalt door wegvallen root filesystem en die SSH variant het ook niet heeft gedaan toen ik die geprobeerd heb.
Reden om de oude SSD bij te werken en dan de NVME drive als mirror er aan toe te voegen is dat die SSD maar 120GB is en dus niet te gebruiken valt als mirror van de (500GB) NVME SSD.

Edit:
Overigens al de hele tijd vergeten te vermelden, en eerder ook niet echt bij stil gestaan. Elke keer als dit gebeurt reset ik het systeem. Daarna komt het BIOS met een hardware check ding waar niks uit komt. Die zet het systeem vervolgens uit en na 1 of 2 seconden weer aan en dan boot die gewoon.
Ik vermoed intussen dat dit gebeurt omdat die geen bootable drive kan vinden en de NVME drive tijdens de reset dus "dood" blijft en een volledige power cycle nodig is om deze weer operationeel te krijgen. Iets wat volgens mij ook overeen komt met bepaalde APST failures die ik met Google heb gevonden. Dat de drive bij puur een reset niet up komt en een power cycle nodig is.

[ Voor 28% gewijzigd door RobertMe op 13-04-2020 22:08 ]

[Q]

Vervelend dat die stomme fio tests duidelijk niet hebben geholpen om het probleem te kunnen reproduceren. Maar misschien is dit ook een clou.

Ik zou eigenlijk adviseren om even niets met mirrors te doen maar de oude SSD te gebruiken zonder de NVME drive. Niet teveel tegelijk.

Ik ben benieuwd of je met deze oude 120 GB SSD dezelfde issues krijgt of niet.

Het is erg belangrijk dat je de log output via een SSH sessie of anderszins remote kan afvangen zoals door anderen eerder is aangeraden want anders kom je nooit te weten wat er mis gaat.

Onder welk OS heb je die fio test gedaan?

Ik vind het wel speciaal dat een zware benchmark geen impact heeft op de NVME maar dat Proxmox de boel wel plat krijgt. Is het werkelijk een hardware of een 'driver' issue?

[ Voor 19% gewijzigd door Q op 13-04-2020 23:27 ]

[RobertMe]

Q schreef op maandag 13 april 2020 @ 23:25:
Ik zou eigenlijk adviseren om even niets met mirrors te doen maar de oude SSD te gebruiken zonder de NVME drive. Niet teveel tegelijk.

Ik ben benieuwd of je met deze oude 120 GB SSD dezelfde issues krijgt of niet.

In principe heeft dir van vorige week zondag middag / avond tot minimaal zaterdag goed gedraaid, zonder reboots etc. Dus die lijkt in zoverre zo snel geen issues te hebben. Maarja, dat heeft de NVME drive in het begin IIRC ook niet gehad. Alhoewel ik nu wel twijfel of die in eerste dagen na optuigen niet ook al was blijven hangen.

Het is erg belangrijk dat je de log output via een SSH sessie of anderszins remote kan afvangen zoals door anderen eerder is aangeraden want anders kom je nooit te weten wat er mis gaat.

Daar moet ik inderdaad nog onderzoek naar doen. I tried, but failed. Die SSH logging vanaf (oude) server/nas heb ik wel gedraaid maar had niks gedaan (misschien doordat SSH sessie te lang inactief was eruit geklapt? Geen idee). Kan evt. ook nog kijken om naar andere HDD (RAIDZ pool) te loggen. Even uitzoeken of/hoe de path van journald aan te passen.

Onder welk OS heb je die fio test gedaan?

Clean Proxmox install. Kan uiteraard ook nog kijken om op huidige installatie ook nog eens FIO te draaien.

Heb vorige week dus ook een clean install op die oude SSD gezet en daar weer alle containers en VMs op aangemaakt. Afgelopen weekend dan nieuwe Proxmox install op de NVME drive en daarop fio gedraaid. Maar daarna wel de volledige rpool van de oude SSD over gezet dus hij draait nu niet de identieke installatie.

Ik vind het wel speciaal dat een zware benchmark geen impact heeft op de NVME maar dat Proxmox de boel wel plat krijgt. Is het werkelijk een hardware of een 'driver' issue?

You tell me En zolang het niet te reproduceren is is het ook nogal lastig te debuggen. Anders kon ik bv met meer combinaties met hardware van m'n PC combineren. Zit ook al te denken om de NVME drive + alle HDDs aan moederbord + RAM + CPU + voeding + ... van m'n PC te hangen. Dus puur storage over nemen en klaar. Als het dan blijft werken is het dus niet perse een defecte drive. Maarjaz ook daarbij, wannneer werkt het? Een paar dagen uptime haalde ik eerst ook. Iets is de trigger, en zolang ik niet weet wat is het ook moeilijk te weten of de trigger er nog niet is geweest of het issue inderdaad niet meer optreedt.

[ Voor 13% gewijzigd door RobertMe op 14-04-2020 09:04 ]

[Q]

Eventueel kun je een syslog server optuigen (syslog daemon op externe interface laten luisteren) en dan al je syslog logging vanaf de debian/proxmox machine daar naartoe laten sturen.

Je kunt eventueel fio langer dan een uur laten draaien met --duration en dan hoe lang je wilt. Je kunt ook de qd en threads ophogen naar 32.

Kun je nog met een andere voeding testen?!

[RobertMe]

Q schreef op dinsdag 14 april 2020 @ 11:47:
Kun je nog met een andere voeding testen?!

Ook om die reden was ik aan het denken om de opslag over te zetten naar m'n gewone PC. Als het dan nog steeds mis gaat zal het dus aan de NVME drive of software liggen. Gaat het een aantal weken goed zal het dus aan iets anders qua hardware liggen (combinatie met moederbord, voeding, ...). En even de opslag aan andere PC hangen voor paar weken vind ik dan praktischer dan beetje bij beetje dingen vervangen en steeds weken wachten.

En fio langer draaien heb ik ook aan gedacht, ik vraag me alleen af of dat veel uit maakt. De drive wordt niet zwaar belast namelijk, maar wel continu, door bv PostgreSQL en InfluxDB die er op draaien (respectievelijk voor Home Assistant en Telegraf die ook in de containers draait). Wat wel zou kunnen is fio eens draaien in een container en VM. Mogelijk dat dat onderdeel is van het issue en het dan toch driver/software gerelateerd blijkt te zijn.

[ZaZ]

Ik heb op ZFS i.c.m. NVME ook al de nodige problemen gehad met proxmox.
Dit heeft voor mij de issues opgelost (wel eerst effe oude settings ergens noteren voor de zekerheid)

in

/etc/sysctl.conf

vm.swappiness=1
vm.min_free_kbytes=524288
vm.dirty_ratio=2
vm.dirty_background_ratio=1

en in

/etc/modprobe.d/zfs.conf

options zfs l2arc_headroom=4
options zfs l2arc_headroom_boost=8
options zfs l2arc_feed_min_ms=10
options zfs l2arc_write_max=134217728
options zfs l2arc_write_boost=268435456
options zfs l2arc_noprefetch=1

Als de file er niet is, dan gewoon aanmaken.
Na het wijzigen moet je rebooten.

[Q]

@ZaZ Wat is het verhaal achter deze oplossing?

Het lijkt wel te impliceren dat het een combinatie is van kernel en ZFS versie. Een NVME drive die er uit klapt, dat mag never nooit gebeuren. Hoe brak je configuratie van je software / fs ook is.

@RobertMe Je zou in plaats van ZFS even geen RAID kunnen gebruiken en gewoon XFS, dat zou ook een interessante test kunnen zijn.

[ Voor 21% gewijzigd door Q op 14-04-2020 14:13 ]

[RobertMe]

ZaZ schreef op dinsdag 14 april 2020 @ 13:59:
Ik heb op ZFS i.c.m. NVME ook al de nodige problemen gehad met proxmox.
Dit heeft voor mij de issues opgelost (wel eerst effe oude settings ergens noteren voor de zekerheid)

in

/etc/sysctl.conf

vm.swappiness=1
vm.min_free_kbytes=524288
vm.dirty_ratio=2
vm.dirty_background_ratio=1

en in

/etc/modprobe.d/zfs.conf

options zfs l2arc_headroom=4
options zfs l2arc_headroom_boost=8
options zfs l2arc_feed_min_ms=10
options zfs l2arc_write_max=134217728
options zfs l2arc_write_boost=268435456
options zfs l2arc_noprefetch=1

Als de file er niet is, dan gewoon aanmaken.
Na het wijzigen moet je rebooten.

Dit ga ik vanavond dan maar even toepassen en hopen dat het dan is opgelost. Hopelijk dat dit dan inderdaad de oorzaak is.

[ZaZ]

Q schreef op dinsdag 14 april 2020 @ 14:12:
@ZaZ Wat is het verhaal achter deze oplossing?

Het lijkt wel te impliceren dat het een combinatie is van kernel en ZFS versie. Een NVME drive die er uit klapt, dat mag never nooit gebeuren. Hoe brak je configuratie van je software / fs ook is.

Je hebt inderdaad wel een kernel van 5.3.13 of hoger nodig. Kan je gewoon pveupgrade uitvoeren en dan heb je 'm.

Het verhaal erachter is dat vaak dagelijks last had van 'hangers'. Vaak kon ik nog zien dat voordat de boel in elkaar stortte, de IO delay omhoog schoot en uiteindelijk altijd eindigde dat in een situatie dat er bepaalde kernel locks actief bleven en zo zoetjes aan service na service tegen een lock aanliepen en er steeds minder van de 'machine' overbleef en uiteindelijk je alleen nog kon rebooten. Vaak doet eerst SSH het nog wel maar ook die brokkelt als het ware af. De kernel waits zijn onmogelijk op te heffen.

Toen ik het probleem met verschillende hardware tegen begon te komen ging ik anders zoeken. Ik zag twee overeenkomsten. De eerste was dat alle machines met NVME drives en ZFS werkten en de ander dat ze door mij beheerd werden. Ik ging er natuurlijk in eerste instantie vanuit dat ik zelf wel iets verkeerd zou doen maar ik kon het maar niet vinden. Op random momenten verschenen locks en bijna altijd als er eerst veel disk activity was (het migreren of klonen van VM's in mijn geval).
Als test heb ik een van de machines (ik heb er 9 die allemaal het probleem hadden) naar EXT4 gegooid in een LVM om te kijken of dat verschil maakte en terwijl ie eerst minimaal een paar keer in de week vastliep, bleef ie nu 40 dagen stabiel draaien. Daarna die machine terug naar ZFS en die had meteen weer problemen. Toen wist ik dat ik het in die hoek moest zoeken. Ben later wat filmpjes van Linus Tech Tips en van Wendel van Level1Linux tegengekomen die ook dit soort problemen tegen zijn gekomen. De theorie was dat de storage te snel is en de kernel daar niet lekker mee om kan gaan. Ik ga zelf niets beweren maar wanhopig als ik was ben ik wel met de settings gaan spelen om zo min mogelijk swap e.d. op de storage te doen.
En zo ben ik uiteindelijk uitgekomen op deze settings en de machines draaien nu allemaal al 86 dagen stabiel.

[Q]

Jouw verhaal doet mij aan iets denken:

Ik was met FIO een ZVOL aan het benchmarken. Het resultaat:

1. Een Load van 50+
2. Bijna geen I/O - alles hangt
3. killall -9 op fio helpt niet

Dit was op reguliere harde schijven.

Dit gedrag had ik naar mijn weten niet als ik een file op ZFS gebruikte, maar een ZVOL was drama.
Dit was met een reguliere Ubuntu 18.04 kernel.

Ik begin me af te vragen waarom je eigenlijk ZFS wil draaien met Proxmox. MDADM + LVM of MDADM met XFS en qcow2 images lijkt me net zo makkelijk. ZFS is toch al niet zo super met zware random I/O belasting zover ik weet.

Ik heb wat benchmarks gedaan met ZFS op harde schijven en random I/O performance van MDADM was stukken beter, getest met RAID10, dus in een vergelijkbare configuratie.

[ Voor 12% gewijzigd door Q op 14-04-2020 16:47 ]

[RobertMe]

Q schreef op dinsdag 14 april 2020 @ 16:46:
Jouw verhaal doet mij aan iets denken:

Ik was met FIO een ZVOL aan het benchmarken. Het resultaat:

1. Een Load van 50+
2. Bijna geen I/O - alles hangt
3. killall -9 op fio helpt niet

Vanmiddag heb ik hem een uur laten lopen binnen een LXC container waarbij de file naar een ext4 partitie op een ZVOL werd geschreven, zonder issues.

Ik begin me af te vragen waarom je eigenlijk ZFS wil draaien met Proxmox. MDADM + LVM of MDADM met XFS en qcow2 images lijkt me net zo makkelijk. ZFS is toch al niet zo super met zware random I/O belasting zover ik weet.

Omdat ZFS support is ingebakken en XFS + MDADM bij mijn weten niet. En "omdat ZFS" überhaupt. Momenteel maak ik elk kwartier een snapshot van de volledige installatie die wordt gereplicate naar de RAIDZ pool + een Orange Pi met een disk eraan. Oftewel, super simpele backups. Daarnaast ook meteen bescherming tegen bitrot etc, en sinds 0.8 ook native encryptie, per dataset.

[RobertMe]

Aan eind van de middag dus de mogelijke oplossing van @ZaZ toegepast, maar net bleek de boel alweer zo dood als een pier te zijn. Toen ik er achter kwam was scherm alweer vol gelopen met "pool rpool has detected unrecoverable I/O errors". Morgen dus maar eens werk maken van goede logging... Om moedeloos van te worden dit. Vooral gezien het systeem in het begin goed heeft gedraaid en daardoor intussen "mission critical" is (Home Assistant die er op draait bv en daardoor essentieel i.v.m. automatisch schakelen verlichting, maar bv ook Pi-Hole).

[Q]

Het is een kwestie van uitsluiten, ik ben niet overtuigd dat dit een hardware issue is.

In de periode dat dit alles wel goed draaide, welke versie van proxmox draaide je? Kun je een fors oudere (of nieuwere) versie testen?

Ik trap misschien open deuren in en ik heb niet meer helder wat je al hebt gedaan. Maar als dit alles prima gedraaid heeft:

Wat is er nu veranderd?

[ Voor 25% gewijzigd door Q op 14-04-2020 21:37 ]

[RobertMe]

Q schreef op dinsdag 14 april 2020 @ 21:34:
Het is een kwestie van uitsluiten, ik ben niet overtuigd dat dit een hardware issue is.

In de periode dat dit alles wel goed draaide, welke versie van proxmox draaide je? Kun je een fors oudere (of nieuwere) versie testen?

Boel is in januari opgezet. En ik ben sterk aan het twijfelen of ik het niet eerder ook heb gehad. En als een dikke gok moet doen zou ik bijna zeggen dat het mis gaat nadat ik een film heb gekeken. Uiteraard gedeeld vanaf dit systeem, met video op de RAIDZ pool (met traditionele HDDs, doh). Dat zou dan in ieder geval een vorm van steps to reproduce kunnen geven.

[Q]

Lastig allemaal, want dat zou kunnen betekenen dat dit nooit goed is geweest en dat we zo heel moeilijk oorzaken kunnen uitsluiten: hardware zou op tafel kunnen liggen.

N=1 maar ik heb dagen geworsteld met een RAID array waarbij opeens semi-willekeurig disks uitvielen. Voeding vervangen en het probleem was weg.

Lukt het in ieder geval nu om met fio consequent het ding om zeep te helpen zodat je op zijn minst het probleem kunt reproduceren?

[RobertMe]

Q schreef op dinsdag 14 april 2020 @ 21:42:
Lastig allemaal, want dat zou kunnen betekenen dat dit nooit goed is geweest en dat we zo heel moeilijk oorzaken kunnen uitsluiten: hardware zou op tafel kunnen liggen.

Jip, soort van hopelijk dat het dadelijk weer mis gaat, gezien ik film verder aan het kijken ben

Lukt het in ieder geval nu om met fio consequent het ding om zeep te helpen zodat je op zijn minst het probleem kunt reproduceren?

Neen, met fio nog geen enkele keer het probleem kunnen triggeren, sadly.

[Thralas]

RobertMe schreef op dinsdag 14 april 2020 @ 21:28:
Morgen dus maar eens werk maken van goede logging...

Reminder, overweeg de netconsole eens te laden, dat kan echt bijna niet misgaan (als je het tenminste opvangt aan de andere kant).

[RobertMe]

Thralas schreef op dinsdag 14 april 2020 @ 21:58:
[...]


Reminder, overweeg de netconsole eens te laden, dat kan echt bijna niet misgaan (als je het tenminste opvangt aan de andere kant).

Intussen met wat moeite aan de praat gekregen in combinatie met m'n oude thuisserver / nas, waarop ik netcat binnen screen heb draaien (in combinatie met tee om zowel output als file te krijgen).

Eerste poging was uiteraard om het met de module-load tijdens boot te doen. Met interface / dev op eno1, van Proxmox, werkte dat ook... even. Dit omdat Proxmox een bridge aanmaakt en eno1 daaraan wordt toegevoegd en vanaf dan werkt netconsole niet meer, op die interface. In eerste instantie geprobeerd met vmbr0 als interface, maar ook dat werkt niet, omdat die pas later wordt aangemaakt.
Nu heb ik ook nog een antieke USB netwerkkaart (uit de tijd dat Ziggo nog Essent @Home hete en je die kreeg meegeleverd), maar ook die wou het niet doen. Ik vermoed doordat eerst netconsole wordt geladen en daarna pas de USB devices. Nu dus maar @runtime netconsole geconfigureerd. Maar na een reboot moet ik dat dan uiteraard weer opnieuw doen.

[RobertMe]

RobertMe schreef op donderdag 2 april 2020 @ 17:35:
En alweer een crash/lockup. Helaas bleek de logging via SSH nog niet te werken en faalde ZFS mount naar /var/log/journal (want al beschreven door systemd, oeps). Gelukkig een foto gemaakt voor reset.


[...]

En de volgende lockup (van gisteravond al), en wederom hetzelfde:

31174.622525] nvme nvme0: I/O 552 QID 1 timeout, aborting
[31174.622525] nvme nvme0: I/O 552 QID 1 timeout, aborting
[31174.626971] nvme nvme0: I/O 553 QID 1 timeout, aborting
[31174.626971] nvme nvme0: I/O 553 QID 1 timeout, aborting
[31174.627364] nvme nvme0: I/O 554 QID 1 timeout, aborting
[31174.627364] nvme nvme0: I/O 554 QID 1 timeout, aborting
[31174.627732] nvme nvme0: I/O 555 QID 1 timeout, aborting
[31174.627732] nvme nvme0: I/O 555 QID 1 timeout, aborting
[31174.628092] nvme nvme0: I/O 556 QID 1 timeout, aborting
[31174.628092] nvme nvme0: I/O 556 QID 1 timeout, aborting
[31205.341792] nvme nvme0: I/O 552 QID 1 timeout, reset controller
[31205.341792] nvme nvme0: I/O 552 QID 1 timeout, reset controller
[31236.061059] nvme nvme0: I/O 20 QID 0 timeout, reset controller
[31236.061059] nvme nvme0: I/O 20 QID 0 timeout, reset controller

Gevolgd door kilometer lange stacktraces van processen die twee minuten niet reageerde.
Wat ik nog zo'n beetje bij elkaar heb gegoogled is de kans groot dat het een hardware of firmware issue is. Vaak dat vervangen van de drive helpt (Lenovo zou zelfs een hele terugroepactie hebben gedaan), en ook een kernel dev die aangeeft "de drive reageert niet, we proberen een reset, waarna de drive nog steeds niet werkt, alles duid daarbij op een issue met de drive". Wat min of meer ook overeen komt met dat de drive niet terug lijkt te komen bij een reset. Als in: bij gebruik van reset start het Fujitsu bord een diagnostics tool waarbij mijn vermoeden is dat dat gebeurt omdat die geen bootable disk vind. Omdat daarna een power off + cold start wordt gedaan werkt die weer wel. Zet ik de PC uit (5 sec knop inhouden) en weer aan boot die volgens mij ook direct door.
Enige wat ik dus nog kan proberen is de drive op andere hardware proberen (dus zoals ik al heb aangegeven eens de NVME drive + HDDs dan maar ook aan m'n PC hangen en zo laten draaien met ander mobo + CPU + RAM + voeding + ...). Werkt het dan wel zit het potentieel toch in de hoek van hardware combinatie, werkt het dan nog niet zal de drive defect zijn.

Edit:
Blijkbaar had ik nog iets gemist. Onder de kilometers lange stacktraces staat nog:

[31387.305474] nvme nvme0: Device not ready; aborting reset
[31387.305474] nvme nvme0: Device not ready; aborting reset
[31387.329616] nvme nvme0: Abort status: 0x7
[31387.329616] nvme nvme0: Abort status: 0x7
[31387.333960] nvme nvme0: Abort status: 0x7
[31387.333960] nvme nvme0: Abort status: 0x7
[31387.334296] nvme nvme0: Abort status: 0x7
[31387.334296] nvme nvme0: Abort status: 0x7
[31387.334629] nvme nvme0: Abort status: 0x7
[31387.334629] nvme nvme0: Abort status: 0x7
[31387.334957] nvme nvme0: Abort status: 0x7
[31387.334957] nvme nvme0: Abort status: 0x7
[31507.854626] nvme nvme0: Device not ready; aborting reset
[31507.854626] nvme nvme0: Device not ready; aborting reset
[31507.855062] nvme nvme0: Removing after probe failure status: -19
[31507.855062] nvme nvme0: Removing after probe failure status: -19

[ Voor 16% gewijzigd door RobertMe op 16-04-2020 06:56 ]

[RobertMe]

Raar, zojuist de NVME drive + HDDs om gezet naar m'n PC. Uiteraard wil ik ook nu weer netconsole gebruiken om in geval van fout de error te zien, maar... er komt geen data binnen. Volgens dmesg is de module netjes geladen en geconfigureerd, maar aan de andere kant ontvang ik dus niks. Doe ik een test via netcat -u <oude server/nas> 6666 dan komt de data daarvan wel gewoon binnen. Iemand een idee hoe dat kan? Ik doe ook precies hetzelfde als wat ik vanmorgen nog gedaan heb:

sudo modprobe netconsole netconsole=@192.168.1.29/enx0040f4973f49,@192.168.1.2/

Interface naam gecontroleerd en die is uiteraard correct, maar anders geeft die daarvan ook een error (zoals nu nog tijdens boot).

Edit:
Over vmbr0 doet die het dan weer wel

[ Voor 4% gewijzigd door RobertMe op 16-04-2020 20:31 ]

[_JGC_]

Probleem is waarschijnlijk je A2000 drive. Ik kom zojuist een topic tegen in OT waar op Windows de stornvme.sys driver een BSOD geeft met een Kingston A2000, zoek je verder op internet, vind je die problemen meer. Mensen swappen die Kingston drive voor een Samsung en probleem is weg. Gezien je timeout problemen denk ik eerder dat het aan je NVME SSD ligt dan aan Proxmox of je andere componenten.

[RobertMe]

_JGC_ schreef op zaterdag 18 april 2020 @ 16:25:
Probleem is waarschijnlijk je A2000 drive. Ik kom zojuist een topic tegen in OT waar op Windows de stornvme.sys driver een BSOD geeft met een Kingston A2000, zoek je verder op internet, vind je die problemen meer. Mensen swappen die Kingston drive voor een Samsung en probleem is weg. Gezien je timeout problemen denk ik eerder dat het aan je NVME SSD ligt dan aan Proxmox of je andere componenten.

Gekke is wel dat hij het nu goed/beter doet op het andere moederbord. Maar uiteraard is dat nog "maar even" (~1,5 dag). Dus ik durf zeker niet mijn handen in het vuur te steken dat die het nu wel goed doet.

Edit:
Toch maar even gegoogled op "Kingston A2000 crash OR bsod OR timeout". Ik ga vandaag of morgen Azerty maar eens mailen om te kijken of ik kan swappen...

[ Voor 10% gewijzigd door RobertMe op 18-04-2020 16:41 ]

[RobertMe]

Korte update:
Geen contact opgenomen met Azerty. Maar systeem draait nog steeds goed, met de NVME drive (+ HDDs) in dat andere systeem.

Twee oorzaken die ik daarvoor kan bedenken:
1. Voeding gerelateerd (het nieuwe systeem heeft geen nieuwe omdat ik nog een relatief nieuwe heb, die nu nog in oude server/nas zit en tzt dus over gezet wordt, systeem draaide dus op een voeding van verschillende jaren (5+ denk ik) oud)
2. Het oude (Gigabyte) moederbord doet iets anders dan het nieuwe (Fujitsu) moederbord. Bv doordat het ouder is en daardoor nog een oudere standaard/protocol/... gebruikt waardoor de drive niet "crasht".

Waarschijnlijk dat ik hem nu nog een weekje as-is laat draaien. Blijft het dan werken dan volgende week een "combi" proberen met of de huidige voeding op het Fujitsu bord of die voeding wat ik gebruikt heb met Fujitsu bord gebruiken met het Gigabyte bord. Oftewel: een mix van (mobo + CPU + RAM) vs voeding.

Maar zonder steps to reproduce blijft het natuurlijk moeilijk om iets zinnigs te zeggen. Werkt het nu al een week doordat het scenario toevallig niet is opgetreden (hetzelfde als dat het volgens mij een maand stabiel heeft gedraaid voordat de weekelijkse issues begonnen), of omdat het gewoon echt een werkende combinatie is en het probleem niet kan optreden.

[RobertMe]

Late update.

Vanmorgen heb ik het systeem (gedeeltijlijk) omgebouwd. Waarbij die draait met definieve hardware, alleen dan met de andere (nieuwere) voeding (uit mijn PC). En een uur later bleek al dat die weer "dood" was. Dus dat is het niet.

Opties die dan nog over blijven:
1. Hardware incompatibiliteit tussen het moederbord en de NVME drive
2. Defect NVME slot op het moederbord
3. Een ander gek issue potentieel alsnog gerelateerd aan voeding(?), potentieel misschien ook installatie issue ("kortsluiting" met de kast)

Ik heb intussen wel "voor de heb" een PCIe NVME adapter. Misschien dat ik daarmee dus eens ga proberen. Dus de NVME drive niet rechtstreeks via het NVME slot op het moederbord maar via die adapter. Daarmee zou ik ook kunnen uitsluiten dat het bv om een manco slot gaat. Hier en daar kom je op internet nog wel eens verhalen tegen dat het ruilen van het moederbord het probleem ook magisch oplost.

Edit: crash numero twee voor de dag zit er intussen ook al op. Nu draait die op de PCIe naar NVME adapter. Het zal mij benieuwen of het verschil gaat maken.

Overigens voor de duidelijkheid. De NVME drive heeft "in mijn PC" (dat moederbord + CPU + RAM, ...) dus verschillende weken aan een stuk perfect gewerkt, en afgelopen week ook met wat dingetjes hier en daar de boel gereboot en daarna ook geen issues gehad. Het lijkt dus echt iets in de combinatie van NVME drive + mobo + CPU + RAM (+ kast) te zijn. SATA kabels voor overige HDDs zijn gebruikt in beide configuraties dus geen issue. Voeding nu dan dus ook gebruikt met beide configuraties.

Mijn vermoeden nu gaat dus of uit naar een incompatibiliteit tussen NVME drive en mobo, of wellicht een slechte aansluiting die soms een bitflip of whatever geeft. Waarbij dat laatste nu dus uitgesloten kan worden middels die PCIe M.2 NVME adapter. Immers weet ik nu met redelijke zekerheid dat dd drive zelf niet kapot is / geen issues met connector.

[ Voor 35% gewijzigd door RobertMe op 16-05-2020 14:14 ]

[RobertMe]

En vandaag de boel waar meer terug ingebouwd in m'n PC... Gisteren ook weer twee lockups gehad met de NVME drive in de PCIe M.2 NVME adapter. Dus het ligt niet aan het M.2 slot...

Een dezer dagen maar eens kijken om de Samsung 950 Pro (uit mijn hoofd) van uit de PC op het Fujitsu bord te zetten en kijken of die dan wel paar dagen (dan wel idle) up blijft. Want dat is het enige wat ik nog niet geprobeerd heb.

Heb wel zowel op het Fujitsu bord en het Gigabyte wordt nu een nvme get-feature -f 0x0c -H /dev/nvme0 gedaan, en die is identiek. Ik weet alleen niet of dit de juiste manier is om te bepalen of de drive op beide moederborden met dezelfde (APST) configuratie draait.

[mrmrmr]

Misschien ligt het aan een probleem met SSD's die niet goed met power saving om kunnen gaan. Powertop 2.12 heeft daar een oplossing voor ingebouwd.

Uit de release notes:
tuningsysfs: use med_power_with_dipm for SATA link power management

Ik heb niet alle berichten in detail gelezen, wel las ik dat je eerder ook maximum performance hebt geprobeerd, dus of dit het oplost is niet zeker. Wel de moeite waard om het te controleren denk ik.

Aanpassen van settings met hdparm zou ook kunnen helpen.

[RobertMe]

mrmrmr schreef op woensdag 3 juni 2020 @ 23:19:
Misschien ligt het aan een probleem met SSD's die niet goed met power saving om kunnen gaan. Powertop 2.12 heeft daar een oplossing voor ingebouwd.

In hoeverre kunnen fixes in powertop effect hebben op een systeem waarop powertop (nog) niet wordt gebruikt? In andere woorden: kan powertop met het wijzigen van settings bugs fixen die niet by default gefixt zijn? En gaat het hierbij om de fix die Intel heeft gedaan? Lijkt me sterk dat als de bug de drive laat crashen dat ze dat dan fixen via powertop en niet door een kernel fix.

Uit de release notes:
tuningsysfs: use med_power_with_dipm for SATA link power management

SATA link power management lijkt mij niet van toepassing op een NVME drive? Diezelfde vraag heb ik eerder ook al gesteld naar aanleiding van de max_performance suggesties. Ook dat leek in zoverre te gaan over SATA / AHCI, wat mij geen betrekking lijkt te hebben op NVME drives.

Aanpassen van settings met hdparm zou ook kunnen helpen.

Dit gaat over een laptop waar power management de SSD laat terugschakelen? Als de boel op accu draait wordt een ander power management profiel naar de drive gestuurd waardoor deze "terug klokt" met als gevolg, door vaagheid van de spec, dat deze extreem veel trager kan gaan lopen.
Nu lijkt het mij al sterk dat dit door een vage bug bij een vaste PC wordt getriggerd, maar dat de SSD compleet "dood" gaat en zelfs bij een reset niet up komt lijkt mij dan nogal raar? Als in: na zo'n lockup is een power down vereist, anders herkent het BIOS de drive niet eens.

---

Overigens, zoals ik zojuist dan ook in zuinige server topic schreef: Na contact met Azerty kreeg ik de optie om de SSD te retourneren. Na expliciete navraag zou dit inclusief volledige refund zijn, ondanks dat ik de SSD al een maand of 3, 4 in gebruik heb gehad (en 8TB gelezen en 16TB geschreven, respectievelijk dus 16 en 32 keer de totale capaciteit. "Zo goed als nieuw" ging dus niet echt meer op). Maar uiteindelijk ervoor gekozen om (met een kleine korting) een Samsung 970 Evo Plus aan te schaffen. Dit omdat ik niet perse een fan ben van het retourneren van (gebruikte) data dragers. En dat dan in combinatie met dat de SSD op een ander moederbord wel een teken van leven blijft geven. Potentieel dus dat ik de SSD binnenkort in mijn normale PC zet (als vervanging van een 256GB Samsung NVME drive van aantal jaren terug). Of als alternatief een USB adapter laten komen. Dan wordt het een throwaway USB stick en als die kapot is dan so be it.

En na mijn, vele, vele, verwoede pogingen om de boel aan de praat te krijgen, inclusief het continu ombouwen van hardware, vind ik het intussen wel goed geweest. Deze SSD komt niet meer op het Fujitsu bord en ik ga niet verder experimenteren. Tenzij er een zeer hoopgevende suggestie langs komt / firmware update / .... Maar ook in dat geval: de Samsung zit nu erin en werkt. Kijken of de Kingston ook werkend te krijgen is is dan niet meer belangrijk. En de uptime / 24/7 beschikbaarheid vind ik dan belangrijker. Gezien bv ("essentiele") domotica erop draait.

[mrmrmr]

@RobertMe Je hebt gelijk dat SATA instellingen geen invloed hebben op PCIe drives.

Powertop wijzigt systeeminstellingen en kan dus dingen oplossen op die manier. Dat is niet het doel van de tool, maar het kan een neveneffect zijn.

Het ging me om de de APM settings in de tweede link. Eerste antwoord.

[RobertMe]

mrmrmr schreef op donderdag 4 juni 2020 @ 09:24:
Het ging me om de de APM settings in de tweede link. Eerste antwoord.

Dat begreep ik ja. En dat komt toch neer op: zet de drive op full beans (254), wat Linux standaard ook stuurt als die op netstroom draait. Waar een lagere waarde (80h dan) gebruikt wordt als die op de accu draait. Waarbij het exacte gedrag dan aan de fabrikant van de HDD/SSD ligt en in zijn geval de SSD extreem deed throttlen om zuinig te zijn.

Overigens ook daarbij: in hoeverre werkt hdparm, en APM, op NVME drives? Want NVME heeft APST voor power control. Welke ik overigens ook al gecontroleerd had op basis van oudere Linux bugs waarbij APST niet altijd goed werkte en je zelf de mogelijkheden moest controleren en zelf de juiste waarde instellen.

Maar ik blijf ook erbij dat het gewoon een crappy drive is. De kans op een softwarefout lijkt mij relatief klein, gezien het zowel onder Linux als Windows gebeurt (Google op A2000 + stornvme.sys en je staat verbaasd over het aantal resultaten). Ook bevestigd doordat de drive met dezelfde data / OS wel op het andere moederbord werkt. Waarbij een fout van Fujitsu mij ook lijkt uitgesloten aangezien de problemen ook optreden met andere (merken) moederborden en nu de Samsung weer wel correct werkt etc.

[_JGC_]

NVME en compatibiliteit is soweiso een gok. Je hebt te maken met drive, moederbord/bios en driver.
Laatst een Lenovo laptop nieuw uit doos. Ik kiep de preinstall eraf, schone Windows 10 erop, binnen een halfuur BSOD. Consistent BSOD bij het ontwaken uit slaapstand. Uiteindelijk vanalles geprobeerd om er vervolgens achter te komen dat de drive in RAID modus werd aangestuurd. Op AHCI gezet en probleem was weg.
Waarschijnlijk had het wel gewerkt met de drivers die Lenovo in de preinstall heeft zitten, maar zowel de standaard drivers van Windows 10 als de drivers van de Lenovo website triggerden keer op keer een BSOD bij ontwaken uit de slaapstand.
Hetzelfde model laptop heb ik inmiddels een aantal keren verkocht, vorige exemplaren waren uitgerust met een Samsung, WD of Hynix SSD, deze had een onherleidbaar ding waar je op typenr of firmware versie alleen uitkomt bij Lenovo.

[FireDrunk]

_JGC_ schreef op donderdag 4 juni 2020 @ 10:12:
NVME en compatibiliteit is soweiso een gok. Je hebt te maken met drive, moederbord/bios en driver.
Laatst een Lenovo laptop nieuw uit doos. Ik kiep de preinstall eraf, schone Windows 10 erop, binnen een halfuur BSOD. Consistent BSOD bij het ontwaken uit slaapstand. Uiteindelijk vanalles geprobeerd om er vervolgens achter te komen dat de drive in RAID modus werd aangestuurd. Op AHCI gezet en probleem was weg.
Waarschijnlijk had het wel gewerkt met de drivers die Lenovo in de preinstall heeft zitten, maar zowel de standaard drivers van Windows 10 als de drivers van de Lenovo website triggerden keer op keer een BSOD bij ontwaken uit de slaapstand.
Hetzelfde model laptop heb ik inmiddels een aantal keren verkocht, vorige exemplaren waren uitgerust met een Samsung, WD of Hynix SSD, deze had een onherleidbaar ding waar je op typenr of firmware versie alleen uitkomt bij Lenovo.

Wel prachtig dat je AHCI noemt op een NVMe drive. Dat kan namelijk niet. Wat jij dus had was een M.2 SATA drive. Dat is _heel_ anders.

Binnen de AHCI/SATA standaard zijn er DevSlp (of DevSleep) functies, binnen NVMe zijn er nog veel meer power states (Zag er zo al 5 in de spec staan).

Dat brengt natuurlijk heel wat extra complexiteit met zich mee. Veel van die lichte bugs zijn op te lossen door het aantal power states wat je wil toestaan te limiteren. Volgens mij zijn er Linux Kernel opties om die NVMe Power States te limiteren. (net als dat je dat met P en C states vroeger wel eens kon doen).

Zo presteerde een ESXi server 20% beter als je C1 states uit zette vroegah

[_JGC_]

FireDrunk schreef op donderdag 4 juni 2020 @ 10:52:
[...]

Wel prachtig dat je AHCI noemt op een NVMe drive. Dat kan namelijk niet. Wat jij dus had was een M.2 SATA drive. Dat is _heel_ anders.

Na omschakelen naar AHCI werd dat ding aangestuurd door stornvme, dus het was geen M2 SATA ding (dan had ie met msahci gewerkt). Intel heeft een fakeraid option ROM en een fakeraid NVME driver die RAID kan doen met NVME drives. Totaal onzinnig in een laptop met 1 drive, maar Lenovo zet het standaard aan.

[FireDrunk]

Wat er dan dus gebeurt, is dat je BIOS met je OS AHCI praat, en je BIOS/UEFI weer NVMe praat met je drive.
Als je die functie uit zet, praat je blijkbaar direct NVMe met de drive.

Dan heb je dus nog steeds te maken met de power saving functies van AHCI als die functie aan staat. Je OS kan immers geen NVMe praten met de drive (in de eerste situatie).

Wel een ranzige optie overigens...

[jdruwe]

Ik heb ook de Kingston A2000 in mijn NUC steken en heb ook een crash elke zoveel dagen, enorm vervelend Ik gebruik de NUC om home assistent op te draaien voor mijn domotica. Ik zou ook home assistent rechtstreeks kunnen draaien op de NUC en vraag me af of ik de crashes dan nog zou hebben. Ik heb ook ondertussen een SATA SSD besteld voor mij pc (crucial mx500), misschien kan ik daar ook eens proxmox op proberen draaien. @RobertMe wat denk jij aangezien je hetzelfde probleem had?

[ Voor 71% gewijzigd door jdruwe op 06-08-2020 23:52 ]

[RobertMe]

jdruwe schreef op donderdag 6 augustus 2020 @ 23:47:
Ik heb ook de Kingston A2000 in mijn NUC steken en heb ook een crash elke zoveel dagen, enorm vervelend Ik gebruik de NUC om home assistent op te draaien voor mijn domotica. Ik zou ook home assistent rechtstreeks kunnen draaien op de NUC en vraag me af of ik de crashes dan nog zou hebben. Ik heb ook ondertussen een SATA SSD besteld voor mij pc (crucial mx500), misschien kan ik daar ook eens proxmox op proberen draaien. @RobertMe wat denk jij aangezien je hetzelfde probleem had?

Ik durf wel met 99% zekerheid te zeggen dat het issue aan de A2000 ligt. Op Google (en hier in de Pricewatch), vindt je ook voldoende Windows gebruikers die issues hebben met deze SSD. Dus het ligt zeker niet aan Proxmox. Met die Crucial SSD zal het dan ook zijn opgelost. Mijn issues zijn in ieder geval weg nadat ik een Samsung 970 EVO heb geplaatst.

[jdruwe]

RobertMe schreef op vrijdag 7 augustus 2020 @ 09:48:
[...]

Ik durf wel met 99% zekerheid te zeggen dat het issue aan de A2000 ligt. Op Google (en hier in de Pricewatch), vindt je ook voldoende Windows gebruikers die issues hebben met deze SSD. Dus het ligt zeker niet aan Proxmox. Met die Crucial SSD zal het dan ook zijn opgelost. Mijn issues zijn in ieder geval weg nadat ik een Samsung 970 EVO heb geplaatst.

Thx, dan ga ik die crucial SSD die eigenlijk voor mijn PC bedoeld was (call of duty werd elke keer maar groter en groter haha) wel in mijn NUC steken en proberen die A2000 in de pc te steken, is wel al een ouder moederbord dus geen idee of dat eigenlijk wel gaat zo een m.2 aansluiting

Ik wil ook proxmox niet opgeven aangezien het gewoon zo een zalig product is en omdat ik dan gwn meerdere vm's kan draaien ipv enkel hassio... daarvoor is de hardware veel te goed

[ Voor 10% gewijzigd door jdruwe op 07-08-2020 11:27 ]

[Michidez]

Hier nog iemand die een A2000 heeft gekocht voor Proxmox.

Zover ik kan lezen heeft niemand deze fatsoenlijk werkende gekregen? Ook pakweg firmware updates helpen niet?


De mijne zit namelijk nog in het doosje, dus zonder fix ga ik proberen deze te retourneren.

[RobertMe]

Michidez schreef op vrijdag 7 augustus 2020 @ 12:27:
Hier nog iemand die een A2000 heeft gekocht voor Proxmox.

Zover ik kan lezen heeft niemand deze fatsoenlijk werkende gekregen? Ook pakweg firmware updates helpen niet?


De mijne zit namelijk nog in het doosje, dus zonder fix ga ik proberen deze te retourneren.

Firmware update voor de drive was er niet, BIOS update fixte niks.

Maar het gebeurt ook niet altijd. Ik heb de drive wel een tijd kunnen draaien op een ouder Gigabyte moederbord, zonder problemen. Het issue zal dus niet gegarandeerd optreden. En in eerste instantie had ik met het Fujitsu bord had ik de eerste weken ook geen issue, en ineens werd het vaker en vaker.

[jdruwe]

RobertMe schreef op vrijdag 7 augustus 2020 @ 12:41:
[...]

Firmware update voor de drive was er niet, BIOS update fixte niks.

Maar het gebeurt ook niet altijd. Ik heb de drive wel een tijd kunnen draaien op een ouder Gigabyte moederbord, zonder problemen. Het issue zal dus niet gegarandeerd optreden. En in eerste instantie had ik met het Fujitsu bord had ik de eerste weken ook geen issue, en ineens werd het vaker en vaker.

Heb je met die samsung waar je nu proxmox op draait eigenlijk nog soortgelijke crashes gehad?

[RobertMe]

jdruwe schreef op maandag 10 augustus 2020 @ 19:03:
[...]


Heb je met die samsung waar je nu proxmox op draait eigenlijk nog soortgelijke crashes gehad?

Nope, werkt als een tierelier.

Zou ik de Samsung nog eens kopen? Waarschijnlijk niet. Dan zou het denk ik een WD Blue worden, die in dezelfde prijsklasse als de A2000 zit. Maar ik betaalde nu liever wat meer met zekerheid van betrouwbare Samsung dan weer een gokje nemen.

[jdruwe]

UPDATE: Ik gebruik nu al 10 dagen de crucial SSD zonder de problemen die ik voorheen had, erg tevreden

[Thralas]

RobertMe schreef op vrijdag 7 augustus 2020 @ 09:48:
Ik durf wel met 99% zekerheid te zeggen dat het issue aan de A2000 ligt.

In de tussentijd kreeg mijn A2000 spontaan last van dezelfde kuren (terwijl het maanden probleemloos werkte); na enig uitzoekwerk bleek de workaround om APST selectief te disablen te werken.

Dat heb ik destijds hier gedocumenteerd: Controller failure due to broken APST support

Nadat net iemand dezelfde problematiek in ander een topic beschreef, viel me op dat iemand blijkbaar de moeite heeft genomen om een quirk upstream te submitten: nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs

Bij deze dus een reminder: mocht iemand nog een Kingston A2000 hebben en problemen ondervinden; als je de laagste powerstate uitzet (of even wacht tot die patch in je kernel landt) dan werkt 'ie probleemloos..

[RobertMe]

Thralas schreef op zondag 14 februari 2021 @ 19:11:
[...]


In de tussentijd kreeg mijn A2000 spontaan last van dezelfde kuren (terwijl het maanden probleemloos werkte); na enig uitzoekwerk bleek de workaround om APST selectief te disablen te werken.

Dat heb ik destijds hier gedocumenteerd: Controller failure due to broken APST support

Nadat net iemand dezelfde problematiek in ander een topic beschreef, viel me op dat iemand blijkbaar de moeite heeft genomen om een quirk upstream te submitten: nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs

Bij deze dus een reminder: mocht iemand nog een Kingston A2000 hebben en problemen ondervinden; als je de laagste powerstate uitzet (of even wacht tot die patch in je kernel landt) dan werkt 'ie probleemloos..

Goed om te lezen dat er nog steeds gewerkt wordt hieraan, en er dus ook een workaround in de Linux kernel voor komt.

Maar, moet ik er dan bij zeggen, persoonlijk vertrouw ik de SSD dan nog steeds niet. Misschien dat die als upgrade in mijn PC komt (moederbord waar die destijds wel goed op leek te werken). Maar persoonlijk vertrouw ik de SSD nog steeds niet mijn data toe, noch als schijf in mijn thuisserver waar o.a. domotica op draait en dus 24/7 stabiel moet zijn.

[AeroDawn]

Ik post normaal niet op dit forum, maar kwam toevallig op deze post uit via een Google-search omdat ik quasi exact hetzelfde probleem ondervind. Soms lukte het booten niet, maar nu blokkeert het systeem geregeld na een half uur.

Mijn config:
Mobo: Fujitsu D3644-B
SSD: Kingston A2000 250GB
CPU: Intel Pentium Gold 5400
RAM: Kingston KSM26ED8/16ME

Systeem draait nu ongeveer 2 maand voordat de eerste problemen kwamen. Ik ga de suggesties hierboven ook eens proberen.

[ Voor 9% gewijzigd door AeroDawn op 05-04-2021 12:18 ]

[_JGC_]

Voor deze bug is begin dit jaar een workaround in de kernel opgenomen. Schakel de pve-no-subscription repository in en doe een update, dan ben je van dit probleem af.

[AeroDawn]

Ok bedankt! Heb de update geprobeerd (met pve-no-subscription) maar issue kwam nog steeds voor. Heb toen nvme_core.default_ps_max_latency_us = 4000 ingesteld in /etc/default/grub en de issue is verdwenen (niet meer voorgekomen sinds eerste melding).

[ Voor 5% gewijzigd door AeroDawn op 07-04-2021 09:01 ]

[Kitser]

AeroDawn schreef op woensdag 7 april 2021 @ 09:00:
Ok bedankt! Heb de update geprobeerd (met pve-no-subscription) maar issue kwam nog steeds voor. Heb toen nvme_core.default_ps_max_latency_us = 4000 ingesteld in /etc/default/grub en de issue is verdwenen (niet meer voorgekomen sinds eerste melding).

Ik heb deze oplossing ergens anders ook gevonden alleen daar zetten ze het op 0.
Hoe ben jij bij 4000 gekomen?
Kan je een klein beetje uitleggen wat dit precies doet?

Ik heb hem nu op 0 staan. En kreeg net toch nog één error op de console. Maar voor de rest draait het wel stabiel (2 uur)
Geen idee of dat zo blijft natuurlijk......

@RobertMe had jij dit ook al geprobeerd?

[ Voor 3% gewijzigd door Kitser op 13-04-2021 17:25 ]

[RobertMe]

Kitser schreef op dinsdag 13 april 2021 @ 16:55:
@RobertMe had jij dit ook al geprobeerd?

Neen. De drive ligt hier alweer bijna een jaar in het doosje in een lade. De recentere (mogelijke) oplossingen heb ik dus niet meer geprobeerd. En daarnaast was het voor mij toentertijd ook een gevalletje "vertrouwen kwijt in het ding, er komt een nieuwe".

[Kitser]

RobertMe schreef op dinsdag 13 april 2021 @ 17:45:
[...]

Neen. De drive ligt hier alweer bijna een jaar in het doosje in een lade. De recentere (mogelijke) oplossingen heb ik dus niet meer geprobeerd. En daarnaast was het voor mij toentertijd ook een gevalletje "vertrouwen kwijt in het ding, er komt een nieuwe".

Snap ik. Ik sta ook op dat punt.
Maar heb nu dit "GRUB_CMDLINE_LINUX=nvme_core.default_ps_max_latency_us=5500" in /etc/default/grub staan. Die 5500 las ik ergens anders als reactie van Kingston zelf.
Voorlopig gaat het goed.

Maar heb toch ook vast deze besteld pricewatch: WD Blue SN550 250GB (WDS250G2B0C)

Bij de eerste de beste error die ik nog van die Kingston krijg gaat de WD erin.
Overigens heb ik die geGoolgled en daar zijn dezelde problemen mee en met dezelfde oplossing.
Maar daarvan kan ik alleen maar reviews vinden waarbij het is opgelost met het toevoegen van bovenstaande.

Mocht het over een dag of 10 nog vlekkeloos draaien kan de WD altijd nog terug gestuurd worden.

Ik vraag me alleen af of 10 dagen dan genoeg is?
@RobertMe hoelang heb jij als langste kunnen draaien voordat er problemen kwamen?

[ Voor 5% gewijzigd door Kitser op 13-04-2021 18:03 ]

[Thralas]

Kitser schreef op dinsdag 13 april 2021 @ 16:55:
Ik heb deze oplossing ergens anders ook gevonden alleen daar zetten ze het op 0.
Hoe ben jij bij 4000 gekomen?
Kan je een klein beetje uitleggen wat dit precies doet?

Zie het wiki-artikel waar ik hier naar link: Thralas in "Proxmox lockups door NVME drive?"

Het getal specificeert de grootst mogelijke acceptabele exit latency (des te dieper de power saving mode, des te langer het duurt om eruit te komen).

De problematische power state heeft een exit latency van 15000 µs (15 ms). In het voorbeeld zet ik daarom de maximum acceptabele latency op die van de voorlaatste power saving entry (2000 µs), dan gebruikt hij die nog wel, maar de diepste probleemstate niet.

Getallen als 4000 of 5500 zijn overgenomen zonder te begrijpen wat het doet. Die zijn voor de A2000 verder equivalent aan 2000 - want de beschikbare sleep states hebben latencies van 2000 µs resp. 15000 µs - het maakt dus ook niet uit.

Ik heb hem nu op 0 staan. En kreeg net toch nog één error op de console. Maar voor de rest draait het wel stabiel (2 uur)

Dat zal dan een ongerelateerde error zijn (welke?).

Geen idee of dat zo blijft natuurlijk......

Waarschijnlijk wel. Er is nog niemand die problemen heeft ervaren na het disablen van de 4e power state.

[Kitser]

Thralas schreef op dinsdag 13 april 2021 @ 19:21:
[...]


Zie het wiki-artikel waar ik hier naar link: Thralas in "Proxmox lockups door NVME drive?"

Het getal specificeert de grootst mogelijke acceptabele exit latency (des te dieper de power saving mode, des te langer het duurt om eruit te komen).

De problematische power state heeft een exit latency van 15000 µs (15 ms). In het voorbeeld zet ik daarom de maximum acceptabele latency op die van de voorlaatste power saving entry (2000 µs), dan gebruikt hij die nog wel, maar de diepste probleemstate niet.

Getallen als 4000 of 5500 zijn overgenomen zonder te begrijpen wat het doet. Die zijn voor de A2000 verder equivalent aan 2000 - want de beschikbare sleep states hebben latencies van 2000 µs resp. 15000 µs - het maakt dus ook niet uit.


[...]


Dat zal dan een ongerelateerde error zijn (welke?).


[...]

Waarschijnlijk wel. Er is nog niemand die problemen heeft ervaren na het disablen van de 4e power state.

Bedankt voor je uitleg. Al vind ik het nog steeds moeilijk om het helemaal te begrijpen. Maar dat ligt meer aan mij dan aan jouw uitleg ;-)
Ik ben hier pas sinds zondag mee bezig.

Maar ik begrijp dus dat je het beste een equivalent van 2000 zijn. Ik heb hem nu op 4000 gezet

Waarschijnlijk wel. Er is nog niemand die problemen heeft ervaren na het disablen van de 4e power state.

Is 4000 dan de 4e power state? Of ik dat 4*2000=8000?

Overigens draait het nu met 4000 sinds gisteren eind van de middag stabiel zonder errors betreffende nvme.

[Thralas]

Kitser schreef op woensdag 14 april 2021 @ 13:30:
Is 4000 dan de 4e power state? Of ik dat 4*2000=8000?

Nee, dat betekent slechts dat alle states met een latency lager dan 4000 µs gebruikt worden. De eerstvolgende state van de A2000 heeft 2000 µs.

Daarom is instellen van 4000 µs in de praktijk gelijk aan 2000 µs. Tenzij je meerdere NVMe-SSDs hebt.

[Kitser]

Thralas schreef op woensdag 14 april 2021 @ 20:33:
[...]


Nee, dat betekent slechts dat alle states met een latency lager dan 4000 µs gebruikt worden. De eerstvolgende state van de A2000 heeft 2000 µs.

Daarom is instellen van 4000 µs in de praktijk gelijk aan 2000 µs. Tenzij je meerdere NVMe-SSDs hebt.

Oke. 👍🏻.
Ik hou het gewoon zo denk ik. Voorlopig is het super stabiel. Dus ik ben al lang blij dat er slimmere mensen dan mij zijn en weten hoe dit werkt en voor de oplossing hebben gezorgd.
Thanks!

[barrymossel]

_JGC_ schreef op maandag 5 april 2021 @ 12:24:
Voor deze bug is begin dit jaar een workaround in de kernel opgenomen. Schakel de pve-no-subscription repository in en doe een update, dan ben je van dit probleem af.

Hier dus niet. Ik draai op de laatste kernel en vannacht om 2 uur was het weer einde verhaal. Waarschijnlijk omdat toen een backup begon.

Vertrouwen is hier volledig weg en heb dus ook maar een andere (MX500 SATA) besteld.
Is de A2000 nog wel fatsoenlijk voor opslag te gebruiken en heeft dit issue daar geen invloed op?

[Thralas]

barrymossel schreef op dinsdag 27 april 2021 @ 11:59:
Hier dus niet. Ik draai op de laatste kernel en vannacht om 2 uur was het weer einde verhaal. Waarschijnlijk omdat toen een backup begon.

Heb je de workaround ook toegepast? Of met grote zekerheid vastgesteld dat je kernel de fix heeft (i.e. commits nalopen)?

Je zou namelijk de eerste zijn waar het niet werkt. En niet de eerste in dit topic die roept dat z'n kernel de fix heeft terwijl dat helemaal niet zo is.

[barrymossel]

Thralas schreef op dinsdag 27 april 2021 @ 12:16:
[...]


Heb je de workaround ook toegepast? Of met grote zekerheid vastgesteld dat je kernel de fix heeft (i.e. commits nalopen)?

Je zou namelijk de eerste zijn waar het niet werkt. En niet de eerste in dit topic die roept dat z'n kernel de fix heeft terwijl dat helemaal niet zo is.

Het is een latere kernel dan waarbij de fix is toegepast, dus lijkt me dat deze kernel (5.4.106-1-pve) ook de workaround bevat.
Handmatig heb ik de workaround niet zelf (meer) toegepast, aangezien deze in de kernel zou zitten.

Maar buiten dat word ik huiverig van de term workaround en ben ik net als @RobertMe het vertrouwen een beetje kwijt. Best vervelend als je domotica systeem en website er volledig uitliggen. Dan liever wat meer zekerheid.

Daarnaast is het ook meteen een upgrade van 250GB naar 1TB, aangezien ik de schijf ook voor wat lokale opslag (foto's en een sporadische film) naast m'n NAS wil gebruiken. En als die Kingston voor wat extra opslag kan dienen ben ik helemaal a happy chap.

[Thralas]

Die versie heeft de fix inderdaad.

Het zou opmerkelijk zijn als je issues dan alsnog aan de A2000 liggen. Werkt voor iedereen namelijk prima.

[Kitser]

Sinds een tijdje heb ik naast de Kingston A2000 NVME drive ook een Samsung SSD,
Nu begin ik toch weer fouten te krijgen.



In mijn grub staat:
nvme_core.default_ps_max_latency_us=5500

Is er iets wat ik nu anders moet doen?

[ Voor 76% gewijzigd door Kitser op 04-06-2021 11:09 ]

[Thralas]

Is dat ook de port van je A2000? Wat laat lspci -v zien? Ziet er in ieder geval uit als een heel ander probleem.

Met andere oplossingen. Zoals hier beschreven, bijvoorbeeld.

[ Voor 6% gewijzigd door Thralas op 03-06-2021 22:38 ]

[Kitser]

Thralas schreef op donderdag 3 juni 2021 @ 22:38:
Is dat ook de port van je A2000? Wat laat lspci -v zien? Ziet er in ieder geval uit als een heel ander probleem.

Met andere oplossingen. Zoals hier beschreven, bijvoorbeeld.

Dit is de output van lspci -v

code:

root@192.168.80.249's password:
Linux proxmox-prodesk 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08                                     :47 +0100) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun  3 21:52:30 2021
root@proxmox-prodesk:~#  lspci -v
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 0                                     7)
        Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Co                                     re Processor Host Bridge/DRAM Registers
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information: Len=10 <?>
        Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06) (p                                     rog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company HD Graphics 530
        Flags: bus master, fast devsel, latency 0, IRQ 130
        Memory at e0000000 (64-bit, non-prefetchable) [size=16M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 3000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [40] Vendor Specific Information: Len=0c <?>
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [100] Process Address Space ID (PASID)
        Capabilities: [200] Address Translation Service (ATS)
        Capabilities: [300] Page Request Interface (PRI)
        Kernel driver in use: i915
        Kernel modules: i915

00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controlle                                     r (rev 31) (prog-if 30 [XHCI])
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      USB 3.0 xHCI Controller
        Flags: bus master, medium devsel, latency 0, IRQ 126
        Memory at e1120000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [70] Power Management version 2
        Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci

00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal                                      subsystem (rev 31)
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      Thermal Subsystem
        Flags: fast devsel, IRQ 18
        Memory at e114b000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [50] Power Management version 3
        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
        Kernel driver in use: intel_pch_thermal
        Kernel modules: intel_pch_thermal

00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1                                      (rev 31)
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      MEI Controller
        Flags: bus master, fast devsel, latency 0, IRQ 129
        Memory at e114c000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [50] Power Management version 3
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: mei_me
        Kernel modules: mei_me

00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT Redirection (rev                                      31) (prog-if 02 [16550])
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      KT Redirection
        Flags: 66MHz, fast devsel, IRQ 19
        I/O ports at 3080 [size=8]
        Memory at e114a000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [50] Power Management version 3
        Kernel driver in use: serial

00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI                                      mode] (rev 31) (prog-if 01 [AHCI 1.0])
        Subsystem: Hewlett-Packard Company Q170/Q150/B150/H170/H110/Z170/CM236 C                                     hipset SATA Controller [AHCI Mode]
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 127
        Memory at e1148000 (32-bit, non-prefetchable) [size=8K]
        Memory at e114f000 (32-bit, non-prefetchable) [size=256]
        I/O ports at 3088 [size=8]
        I/O ports at 3090 [size=4]
        I/O ports at 3040 [size=32]
        Memory at e114d000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [70] Power Management version 3
        Capabilities: [a8] SATA HBA v1.0
        Kernel driver in use: ahci
        Kernel modules: ahci

00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (                                     rev f1) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 120
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: e1000000-e10fffff
        Capabilities: [40] Express Root Port (Slot+), MSI 00
        Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [90] Subsystem: Hewlett-Packard Company 100 Series/C230 Se                                     ries Chipset Family PCI Express Root Port
        Capabilities: [a0] Power Management version 3
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Access Control Services
        Capabilities: [220] #19
        Kernel driver in use: pcieport

00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
        Subsystem: Hewlett-Packard Company Q150 Chipset LPC/eSPI Controller
        Flags: bus master, fast devsel, latency 0

00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      Power Management Controller
        Flags: fast devsel
        Memory at e1140000 (32-bit, non-prefetchable) [disabled] [size=16K]

00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      HD Audio Controller
        Flags: bus master, fast devsel, latency 64, IRQ 131
        Memory at e1144000 (64-bit, non-prefetchable) [size=16K]
        Memory at e1130000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
        Subsystem: Hewlett-Packard Company 100 Series/C230 Series Chipset Family                                      SMBus
        Flags: medium devsel, IRQ 16
        Memory at e114e000 (64-bit, non-prefetchable) [size=256]
        I/O ports at efa0 [size=32]
        Kernel driver in use: i801_smbus
        Kernel modules: i2c_i801

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (                                     rev 31)
        Subsystem: Hewlett-Packard Company Ethernet Connection (2) I219-LM
        Flags: bus master, fast devsel, latency 0, IRQ 128
        Memory at e1100000 (32-bit, non-prefetchable) [size=128K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] PCI Advanced Features
        Kernel driver in use: e1000e
        Kernel modules: e1000e

01:00.0 Non-Volatile memory controller: Kingston Technologies Device 2263 (rev 0                                     3) (prog-if 02 [NVM Express])
        Subsystem: Kingston Technologies Device 2263
        Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
        Memory at e1000000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/8 Maskable+ 64bit+
        Capabilities: [70] Express Endpoint, MSI 00
        Capabilities: [b0] MSI-X: Enable+ Count=16 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [158] #19
        Capabilities: [178] Latency Tolerance Reporting
        Capabilities: [180] L1 PM Substates
        Kernel driver in use: nvme

Heb de melding in de bovenstaande post even veranderd in been foto van de huisige meldingen (die andere waren van been andere post die een soort geljke melding had). Dit is wat nauwkeuriger.

In de post waarnaar je linked staat dat je "pcie_aspm=off" moet toevoegen.
Maar waar je doe je dat?

Misschien nog een ander stukje interessante informatie:
Ik heb m'n Proxmox server weer op een monitor aangesloten omdat ik na een reboot niet meer op de webui en op de command prompt kon komen.
Toen ik hem op een monitor aansloot kwamen dit soort meldingen voorbij:




Blijkbaar is er ook iets met de e1000e LAN adapter.

Geen idee of beide met elkaar te maken hebben, hoor. Maar misschien komen jullie hier wijs uit?

[RobertMe]

3 jaar later, SSD weer in gebruik genomen, in een ander systeem (TopTon mini PC als zijnde router). Meteen de firmware update gedaan, die overbodig zou moeten zijn door kernel "fixes"/workarounds. Ding heeft een aantal dagen " 24/7" gelopen ("24/7" in de zin dat ik het ook geïnstalleerd en geconfigureerd heb dus zo nu en dan een reboot).
Gisteren in gebruik genomen, vanmorgen een crash/vastloper(?). Op basis van dat het systeem een serial console port heeft daar een laptop aan gehangen. Eerder vanavond "afgekoppeld" nog geen half uur later " internet". Maar weer met 5 sec knop inhouden het systeem tot leven gewekt, dom dom niet meteen weer serial console er aan gehangen. Nog geen 5 minuten later " internet ". Intussen weer de console kabel er aan hangen en op het Proxmox systeem waarmee deze draad begon via SSH ingelogd, tmux geopend, SSH geopend naar systeem met de A2000, en cat /proc/kmsg gedaan zoals in een van de eerste posts werd aangegeven als zijnde debug methode. Maar natuurlijk blijft die nu vrolijk draaien. Lijkt wel een heisenbug zo.... Maar ik acht op basis van de symptomen toch dat de kans heel groot is dat die kernel workarounds & firmware updates hun werk niet doen. Uiteraard kan het ook een ander issue zijn dat de crash veroorzaakt. Maar zou wel toevallig zijn.