Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Fossil (Wikipedie) byl vydán ve verzi 2.22. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
David Malcolm se ve svém příspěvku na blogu vývojářů Red Hatu rozepsal o vylepšeních statické analýzy (volba -fanalyzer) v GCC 13.
Byla vydána nová stabilní verze 23.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Stoat. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Příspěvek na blogu CZ.NIC upozorňuje na nový útok na weby v Česku. Na honeypotech na Turrisech byla zaznamenána nová aktivita útočníků - probíhající útok na FTP servery, které se vyskytují na stejné IP adrese, jako aktivní WEB server.
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2023.05. Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Linux Foundation Europe představila projekt RISE (RISC-V Software Ecosystem), jehož cílem je urychlit vývoj open source softwaru pro architekturu RISC-V.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu pro jednodeskové počítače na platformě ARM, byl vydán ve verzi 23.05. Přehled novinek v Changelogu.
Minulý týden proběhla openSUSE Conference 2023. Mimo jiné bylo oznámeno přejmenování systému MicroOS Desktop. MicroOS Desktop GNOME byl přejmenován na openSUSE Aeon a MicroOS Desktop Plasma na openSUSE Kalpa.
Thom Holwerda z OSnews si všímá, že vývoj operačního systému MINIX je prakticky mrtvý. Jeho hlavní autor, Andrew Tanenbaum, formálně odešel do důchodu v roce 2014 a příspěvky do kódu v následujících letech vůbec ustaly. Stav projektu shrnuje diskuze z roku 2020. Sice vyšlo najevo, že Intel používal MINIX v Management Engine, ale změny nezveřejňoval.
zaujimave je, ze vzdy sa to stane v nociNespouští se něco cronem? Nebo nesnaží se ten procesor nějak ACPI uspat, což se mu nepovede?
Zkus něco zkompilovat. Velice dobrý test paměti a CPU je třeba kernel Linuxu nebo něco většího, třeba wine.
Pokud to projde, tak je pes zakopán jinde.
mal som na jednom serveri podobny problem a vysledok z testovani bol ze je vadny procak...
mal som tam quadcore, v logoch som videl ze cpu2 a cpu3 "haluzia"... rekompiloval som kernel s vypnutym SMP, takze sa "pouzivalo" len cpu0 a problem zmizol... a druhy test spocival vo vymeneni cpu za iny :)
bez dump-u mozes len tipovat ze kde "asi" moze byt problem .. prekompiluj si kernel s podporou crash dumpu .. po crashi budes moc skumat co sa stalo .. s downtime na nabootovanie noveho kernelu asi problem mat nebudes, kedze sa to rebootuje tak raz za tyzden same :)
sorry za formatovanie, nejaky blud
skor naopak - teraz hladas v kope sena .. nemas nic solidne co by ti napovedalo v com je problem .. dump je zaklad .. google ti poradi ako postupovat pri analyze crashu a pripadne ta nakopne potom dalej..
inak si nespomenul - vidis dovod rebootu v logu ? (reboot after panic alebo pod. )
Skús podtaktovať procesor(y). Buď cez cpuspeed, alebo lepšie v biose.
Alebo vybrať ten prvý a nechať len ten druhý. A naopak.
Ja som raz mal podobný prípad - ale to bolo v čase 1GHz procesorov. Podtaktoval som ho na 800 MHz v biose a bežal bez problémov.
Tiskni
Sdílej: