Mi baja a PC(i)m-nek?

Közösségi kerekasztal

Boldog faünnepet fórumtársak!

Van egy házi servernek használt PC-m, már lassan 1.5 éve megy gond nélkül, viszont az utóbbi hetekben produkált fagyást / újraindulást. Kb 24-30 órát működik, aztán jön az error, valahogy így néz ki: https://pastebin.com/nabHBxis

Alapvetően ezzel a konfiggal ment:
MOBO MSI B350 Gaming Plus
CPU AMD Ryzen 7 1700X
RAM 2 x 8GB Corsair Vengeance 3000 MHz
VGA Biostar nvidia 730
HBA kártya (LSI SAS2308) - 4 x 500 GB Crucial MX500 SSD
SSD WD Blue 250 GB
HDD 4TB Ironwolf
PSU Corsair HX750
OS Proxmox 8

Alapjáratban fut rajta egy konténer OTRS, egy konténer hálózati file-megosztás és egy Windows Server Veeam-el. Ezen felül, ha valamit tanulok/játszok/kipróbálok. Load minimális. A gép rendeltetési helye nem is nálam van, csak a debug folyamatra hazahoztam.

Nem írom oda, hogy minden próbálkozás után maradt a hibajelenség, csak felsorolnám, hogy mikkel próbálkoztam kb ilyen sorrendben: széthúztam - visszadugtam fixen minden kábelt; szétkaptam, kitakarítottam, újrapasztáztam mindent, amin van hűtőborda; próbáltam minimálisra venni a konfigot, hátha valamelyik komponens hibásodott meg; BIOS/UEFI reset / update; proxmox reinstall; másik SSD-re tettem Windows 10-et, de azzal is rebootol pár óra múlva, Even viewer-ben csak a szokásos 'shutdown unexpectedly'. Próbáltam Prime95-el hajtani, órákig megy, max hőfok 65C. Memtest többször végigment hibátlanul. Idle-ben meg freeze/reboot.

Ez után kezdtem el kicserélgetni a komponenseket, szépen egyesével: PSU, RAM, CPU, HBA, de még mindig hibázik - így gondoltam maradt az alaplap. Ebből nem tudtam cserét szerezni, vettem egy újat. A hiba továbbra is fennáll.
Viszont így már van 2 hasonló konfigurációm és mindkettő ugyanazt produkálja. Itt vannak egymás mellett, és random újraindulnak.
Ami közös bennük az már csak a villany, de ezen a körön van a desktopom is, annak semmi baja; valamint nem nálam kezdte el ezt a jelenséget, így nem is gondolnám, hogy a 230 a baja. Meg nem is egyszerre produkálják a jelenséget. Táp kábelt is próbáltam többet :D

A cserealkatrészek / cserekonfig:
MOBO ASrock B450M Pro4 (ez konkrétan új)
CPU AMD Ryzen 5 1600
VGA AMD Radeon 6450
RAM 2 x 8 GB G.Skill 3000 MHz
PSU Corsair GS700

Na most akkor mi a bánat lehet, hogy van 2 konfigom és ugyanúgy csontra fagy/újraindul mind a kettő x óra után? Volt egy hiábás alkatrészem, ami tönkrevág folyton egy másikat? Ezt hogy derítsem ki? Dobhatok ki most 2 konfigot ezért?

Köszönöm, ha van valakinek építő jellegű gondolata, igyekszek mindent kipróbálni, mert a Veeam-re szükségem van.

  • 2323 megtekintés

( Huncraft v | 2023. 12. 24., v – 12:00 )

Szerkesztve: 2023. 12. 24., v – 12:01

"Load minimális"

Pedig a dmesg alapján valami nagyon befogja néha az egyik CPU magot:

Dec 23 02:24:43 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:0:302816]
Dec 23 02:25:11 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 48s! [kworker/5:0:302816]
Dec 23 02:25:39 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 74s! [kworker/5:0:302816]
Dec 23 02:26:15 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 108s! [kworker/5:0:302816]
Dec 23 02:26:43 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 134s! [kworker/5:0:302816]
Dec 23 02:27:11 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 160s! [kworker/5:0:302816]
Dec 23 02:27:39 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 186s! [kworker/5:0:302816]
Dec 23 02:28:07 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 212s! [kworker/5:0:302816]
Dec 23 02:28:35 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 238s! [kworker/5:0:302816]
Dec 23 02:29:19 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 279s! [kworker/5:0:302816]
Dec 23 02:29:47 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 305s! [kworker/5:0:302816]
Dec 23 02:30:15 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 332s! [kworker/5:0:302816]
Dec 23 02:30:43 dave-pve kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 358s! [kworker/5:0:302816]

Én 3 okot tudok ami ilyet okozhat:

  • Vagy valami nagyon HW / kernel igényes folyamat fut az adott időben (ami tipikusan vagy sok CPU, vagy sok I/O ciklust kér). Érdemes megnézni, hogy van e valami folyamat ami akkor indul el scheduler-ből, vagy esetleg nem e szolgál ki túl nagy kérést egy klienstől (elképzelhető, hogy a hálózaton belül más fertőzött gép indít magas I/O-t, bár a schedulernek ezt szerintem le kéne tudnia kezelni)
    • Ha van valamilyen virtalizációs megoldás a gépen, akkor a VM körmére is nézz rá, főleg ha teljes core-t dedikáltál a VM-nek.
  • Vagy a CPU tápellátása nem teljesen jó (konnektorban meg kéne nézni mekkora ingadozások vannak, vagy elé rakni egy tápegységet ami ki tudja balance-olni az ideiglenes feszültség fel/le ugrásokat)
  • Ritka esetben CPU hiba - ilyenkor csak az működik, hogy az adott CPU magot elkülöníted ('isolcpus=5', vagy 'echo 0 > /sys/devices/system/cpu/cpu5/online' futásidőben ). Nézd meg, hogy mindig azonos magra jön e a soft lock - ha igen, akkor kezdhetsz gyanakodni, ellenkező esetben ezt a lehetőséget szerintem zárd ki.

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Amennyiben van remote csatolt háttértár (NFS / iSCSI), akkor ezt el tudom képzelni, de egy ilyen azér jóval nagyobb zajjal jár:
Ugye első körben a memória kezd elfogyni (nem flush-olt adat még fogja a memory page-eket), amit aztán egy OOMkill-es "razzia" követ (a kernel megpróbálja egyesével kinyírni a legtöbb memóriát használó process-t (már ha megengedtük neki), majd ha már nincs mit kigyílkolnia akkor szépen lassan az egész rendszer elhasal.
Maga az OOM event-ek általában eljutnak a dmesg-ig (hacsak nem valami remote disken van maga a log FS is ami épp nem elérhető), illetve ilyenkor nem csak 1 CPU core-on jön elő a probléma, hanem össze-vissza változik, annak függvényében, hogy épp melyik core-on futott az adott thread
// megjegyzés: általában a kernel próbálja a 0-ás core-on tartani a kernel thread-eket (feltéve, hogy az elérhető), szóval ez miatt én nem erre gyanakodnék

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szia!

Köszi, jó sok info meg kipróbálni való!

Vagy valami nagyon HW / kernel igényes folyamat fut az adott időben...

Magán a proxmox hoston nem fut scheduled job (legalábbis a default Debian jobokon kívül), a Windows Server-en lévő Veeam indul 22:00-kor, de max 15 perc alatt végezni is szokott. Nem szokott ilyenkor hibázni. 02:24-től fogalmam sincs mi lehet; most pl nem állt le, most 27 órája fut folyamatosan.

elképzelhető, hogy a hálózaton belül más fertőzött gép indít magas I/O-t

 Hát ez érdekes felvetés, következő leállás alkalmával izolálom a gépet..

Ha van valamilyen virtalizációs megoldás a gépen..

Van persze KVM (proxmox) de jelenség akkor is fennáll, ha nem futnak VM-ek, se LXC konténerek :\ Illetve, ha fogok egy másik SSD-t, teszek rá egy Win10-et, azzal is újra tud indulni.

Vagy a CPU tápellátása nem teljesen jó

Időszerű lenne egy UPS-t kapnia, lehet a 2 ünnep között meg is teszem, de januárban biztosan. Ami érdekes, hogy ez a helyszínen kezdődött és itthon nálam folytatódik. Ráadásul ezzel a 2 géppel van gond, a saját itthon PC-mmel meg nem és ugyanazon a fázison vannak. Sajna most ezt a legnehezebb kiszűrnöm.

Ritka esetben CPU hiba

Nem mondom, hogy lehetetlen, de egyszerre kettő? :D journalctl --since "5 days ago" | grep 'soft lockup' -ra egyelőre csak ezt az egy esetet adja ki, de ha megint előfordul megfigyelem, hogy melyik magra panaszkodik.

Nem mondom, hogy lehetetlen, de egyszerre kettő?

Bocs, nem vettem észre, hogy 2 külön CPU-val is ugyan úgy előjön. Bár az alaplapi csatlakozó még ez után is lehet ludas, de nem hiszem, hogy az lenne a probléma, inkább gondolom valami szoftveres nyavalyának.
Amit még javasolnék: Állíts fel egy "monitoring" scriptet ami mondjuk minden 5 percben elmenti a gép állapotát (a logok alapján bő 6 perc kellett a teljes megálláshoz, szóval 5 perccel még nagy eséllyel el tudod kapni mi zabálhatja épp fel a procit), és a legközelebbi crash után azt elemezd ki.

Nagyon régen (még AIX adminkodós koromban) erre nmon-t használtam nmon-analyserrel, mert cronban 1 sorból el lehetett intézni, hogy X percenként kimentse az adatokat, és az analyserrel egész jól vissza is lehetett követni mi és hogy történt, színes szagos grafikákkal, meg mindennel, miközben a logok napi szinten alig ettek valamit (20-30 MiB / nap).. Időközben mondjuk a project eléggé megkopott, de szerintem egy középkategóriás szerver / home PC igényeit a mai napig szépen el tudja látni.
// Persze ha van más tool amit inkább preferálnál, nyugodtan használd azt, a fenti az csak személyes ajánlás

Linkek:

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Köszi az olvasnivalókat :)

Az askubuntu fórumos ötletek alapján sajna mindegyiken végigmentem: BIOS update, memtest megvolt, swap meg nincs bekapcsolva :\
A suse fórumon szépen leírja, hogy miért van ez, de sajna nem tudom, hogy hajnali kettőkor, amikor az ég világon semmi dolga nincsen miért lesz egyszer csak busy, ráadásul amikor még csak VM / konténer se fut rajta. Host memory-t sem tartom nagyon kevésnek..

( efel | 2023. 12. 24., v – 14:52 )

Hasonló gépen rcu_nocbs=0-15 nekem segített.
 

( bennyh | 2023. 12. 24., v – 16:30 )

Szerkesztve: 2023. 12. 24., v – 16:32

Az hogy AMD :D, írom ezt AMD-s géptulajként...

SSD hiba?

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Amúgy viccet félretéve sajnos igen. 1. generációs Ryzen mindkettő. Ennek volt nagyon sok gyerekbetegsége. "Performance marginality problem" vagy valami ilyesmi néven futott a leggyakoribb probléma. De voltak machine check exceptiont dobáló példányok is. És asszem ez a generáció volt a ami powersave C-state-ekhez kapcsolódóan idle állapotban tudott lefagyásokat produkálni. A topikindító problémája ez utóbbira gyanúsan emlékeztet.

Ami viszont ellene szól, hogy ezek a hibák vagy azonnal, dobozból frissen kibontott CPU-nál jelentkeztek, vagy - ha szerencséd volt a silicon lotteryn - akkor soha. Olyanról (1. gen Ryzenek kapcsán) eddig nem hallottam, hogy idővel alakult volna ki a fentiek közül bármelyik probléma.

Régóta vágyok én, az androidok mezonkincsére már!

Teljesen off jelleggel, kíváncsiságból ránéztem hardveraprón milyen áron mennek a 2000-es szériájú Ryzen-ek, ezek elvileg már bugfixált kiadások. R5 2600-as, sőt néha 2600X is van már 15eFt-ért is. R7 2700-as 22eFt.

Wow, ezeknek jól bezuhant az áruk! Az én (jóval öregebb és csak 4 magos) Core i7 4790-emet legolcsóbban 25eFt-ért láttam...

Régóta vágyok én, az androidok mezonkincsére már!

"..Core i7 4790-emet legolcsóbban 25eFt-ért láttam..."

Just found this amazing item on AliExpress. Check it out! HUF20,523.90 | Intel Core i7-4790 i7 4790 3.6 GHz Quad-Core CPU Processor 8M 84W LGA 1150
https://a.aliexpress.com/_mM0X1mk

Postával együtt..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A régi procik ott a legolcsóbbak, viszont ott általában nem kapsz melléjük hűtőt, meg esetleg sokára ér ide Kínából. Érdemes azért szétnézni több helyen, hátha kicsivel drágábban, de hűtőstől, vagy megbízhatóbb helyről pár ezresést felbukkan, gyorsabban kiszállítják, stb..

Viszont én a topiknyitó kolléga helyében nem cserélnék procit, hiszen ha nem a mostani 1700-ese a hibás, akkor potyára költ rá. Jó, persze az upgrade sose haszontalan, de most csak próbából megvetetni valamit, ami adott esetben nem szükséges, az gáz. Sose jó ötlet csak pénzégetéssel megoldani egy problémát.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

azt hiszem én is ráfutottam sandy briggel 2018-2019 körül (4.15 -ös kernel talán), úgy emlékszem nálam az volt a baj, hogy a szoftveres throttling szabályozás nagy terhelés mellett túl lassú volt és a hw hővédelem le tudta kapcsolni a gépet. Így a kernel általi szabályozás helyett a proci beépített megoldására kellett váltani: intel_pstate=disable

Aztán gondolom változott a kernelben ez. Előtte és utána is ment jól, de volt pár hónap, amikor párszor megszopatott és ezért betettem a paraméterek közé.

Ez érdekes, amit írtok, mert nekem is volt (sőt van, csak inkább már BSD-vel használva) Sandy Brige procis gépem, amit ebben az időben, ezzel a kernellel használtam, és SEMMI gond nem volt vele, default intel_pstate-tel elfutott atomstabilan, gyönyörűen.

Ami engem régen szopatott, azok a korai Intel iGPU-k driverei voltak, egyes login managerek szerettek szórakozni velük, meg X.org alatt is le kellett tiltani az xf86-video-intel drivert miattuk, és alternatív KMS-Glamour driverrel használni. De a procikkal baj nem volt.

Ryzenből csak rövid ideig volt 1. genesem, egy Ryzen 7 1700, azzal sem volt baj, meg jó ideje van egy 2600-as, azzal sincs semmi.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Laptopokban akkoriban már divat volt gyenge hűtéssel, a throttlingra támaszkodva kihajtani a gépet. 
Valamit optimalizáltak a kernelben, ami szarul viselkedett és nem reagált elég gyorsan, triggerelve a hővédelmet. Aztán később gondolom rájöttek, mert később a következő lts verziós kernelltől megint nem tapasztaltam. 

https://askubuntu.com/questions/1063363/laptop-cpugpu-overheating-after…

( hokuszpk | 2023. 12. 24., v – 17:52 )

ha nem probaltal volna bele masik procit, aszondanam, hogy adjal egy pici pluszos offsetet a cpunak.

smartok rendbenvannak ?

HUP te Zsiga !