Může uspání jader CPU způsobit problém?

[mikesznovu]

Máte někdo zkušenost, že by příkaz vypnutí  jednoho nebo několika CPU v linuxu
   přes

Kód: [Vybrat]

echo 0 | sudo tee /sys/devices/system/cpu/cpu#/online
mohl po uspání do RAM a následném probuzení způsobit problém že se se něco pokazí? myslím tím třeba zatuhnutí  při uspání, při probuzení, samo-reset, nebo že se prostě zasekne a vypne (při sleep nebo probuzení)

[Reklama]

[RDa]

A to je takovy problem to vyzkouset zda STR jede na vsech jadrech nebo pada jen pri vypnutych?

Tu souvislost muzes odhalit sam, a pokud tam je.. tak pred STR si je probud, ne?

[mikesznovu]

Odhaluju příčinu zamrznutí  (od uspání uběhlo 12 hodin) a  napadlo mě co když ty cpu  offline je recept na takovýhle neprobuzení.
Stalo se mi totiž že uspaný SBC se neprobral, bohužel nezjistim proč a v jakym byl stavu. Probudit nešel, monitor hlásil no signal, ale síťovka blikla při paketu.
Mám podezření že k probuzení došlo ale z nějakého důvodu zatuhl těsně po probuzení .
Pokud by došlo k selhání (výpadku) napájení,, nalezl bych ho spuštěný, reagoval by na ping.

Takhle jsem ho nalezl v stavu, , JAKO když ho vypnu(softwarově nebo podržením čudlu)
Ale zároveň je možné, že byl spuštěný, jelikož připojená wifikarta blikala., taky byl pasivní chladič míírně teplý(ale stav běhu bych podle toho určil s hodně níkzou jistotou)

v journalctl --file jsem vyšťoural že uspaný byl  OK (i když je místo, kde se mohou vci po**rat když kernel  usne, ještě může dělat něco firmware)

Kód: [Vybrat]

find /var/log/journal -type  f   -exec bash -c 'echo  $(journalctl  --file  {} |wc -l)   {} ;' ";"

PM: suspend entry(deep)
ale už jsem nenašel nic potom (pm suspend exit)
 

Takže nevím... vím,že jsem předtim asi4/8 dal offline.

ale:
Tak já jsem to zkoušel (asi 4x, ruzne kombinace) a pokaždé se probral.... takže tím to nebude

A nebo je možné, že byl v nějakém metastavu to se taky vzácně může stát ()

[RDa]

A ono to nejde resit jinak? Treba nejaky low power rezim, ktery nahazuje mobil pri zamknute obrazovce, pokud se jedna o SBC, tak to po hw strance nebude mit daleko k tomu. Pochybuji ze lze poznat rozdil ve spotrebe na tom SBC, kdyz to vetsinou nema poradny power management a oddelene napajeci domeny pro zarizeni.

[mikesznovu]

Tak teď tomu fakt nerozumím. Nechal jsem ho běžet.  Zapnu monitor(ve vypnutém stavu  USB hub monitoru jako kdyby neexistoval), vidím hýbat se spořič. ťuknu na klávesu nebo stisknu myš aby se spořič  spakoval a obraz zmizí ->černá obrazovka (Nemusí nutně znamenat že příčinou bylo ťuknutí na tu klávesu, mohlo to klidně být samotné zapnutí monitoru)
... Nereaguje na pingpakety (umím si ručně vstříknout záznam  do ip neigh ip lladr dev xxx  nebo L2 broadcast), síťovka jen svítí oranžově, neblikne když přichází pakety. Nereaguje ani na krátký stisk vypínacího čudlu...


Ubuntu MATE tam je nějaké LTS, tuším 18 nebo 21.



do spánku jsem ho nedával, jen jsem vypnul switch(abych nešoupával konektory ) a monitor. Jediné co v něm bylo zapojené je barrel napájecí konektor, HDMI,eth kabel do vypnutého switche a USB kabel do USB hubu v monitoru (downstream: myš a klávesnice)

Snad asi jediné co zbývá je UART...

[Reklama]

[František Ryšánek]

Zkuste utrousit víc informací :-)

Co je zač ten motherboard, jak stará platforma, nebyl by novější BIOS? Zažil jsem na starším notebooku, že se občas nedokázal probudit ze suspendu, a určitého pozitivního vlivu bylo možno dosáhnout hraním s acpi_osi.

Je to funglovka, nebo má něco naběháno? = snažíte se to rozchodit čerstvé, nebo Vám to pár let fungovalo a najednou to zlobí? Pokud B je správně, tak na software se nesahalo, nebo proběhl nějaký upgrade/update distra?

Z čeho to startuje? Nemůže být problém v tom, že se neprobudí disk?

[k3dAR]

Zkuste utrousit víc informací :-)

Co je zač ten motherboard, jak stará platforma, nebyl by novější BIOS? Zažil jsem na starším notebooku [...]

BTW: info dal male, nicmene:

[...] Stalo se mi totiž že uspaný SBC se neprobral [...]

[František Ryšánek]

BTW: info dal male, nicmene:

[...] Stalo se mi totiž že uspaný SBC se neprobral [...]

Mějte prosím shovívavost se starším člověkem :-)
Zkratku SBC znám jako "Single Board Computer". Tam kde dělám, výrobci do této kategorie řadí všelijaké x86 boardíky v mechanických formátech PC104, 3.5" biscuit, 5.25", někteří dokonce ITX a PICMG, nemluvě o všelijakých proprietárních a "otevřených" miniaturních formátech (ETX, Q7 a mnohé další). Většina toho v mém dohledu jsou PCčka, tu a tam nějaký ARM - jenom odhaduji, že mimo moji bublinu jsou ARMové desky mnohem populárnější a možná mají co do počtu prodaných kusů většinu trhu...

[mikesznovu]

Je to Odroid XU4, s Arm-em, s úložištěm  v podobě  eMMC destičky místo obligátních microSD.

Neprovozuju ho moc často(jednou za čas ho yhátnu), takže o spolehlivosti nemohu moc mluvit. Ale už ho pár let mám, na SW jsem nesahal,  naběháno toho moc nemá, .

Snad zváštnost je, že jede z 2A USB nabíječky, zdroj mám také, ale tím jak to nezapínám každý měsíc, nemohu tvrdit, kdy to jelo, kdy byly probl=my

(Vím, že u některých nabíječek(spíš powerbank) je zvláštnost, že  při detekci nízkého odběru udělají shutdown), ale tady jsem na to nenarazil.

Taky jsem nenarazil na situaci, kdyby nabíječka   řekla žravému odroidu you shall not draw. (ta nabíječka má charakteristiku, že někde za 2A začne hodně snižovat napětí) a mmjiné umí i 9V (takové ty quickcharge)

K měření odběru jsem se nedostal, ale ta nabíječka napájely i RPI které bych šacoval na mnohem měnší odběr(nemám to čerstvé, ale v idle 5V krát 100až 140mA) než toto "monstrum""

PS: pro zopakování: nastaly 2 různé jevy, prvně freeze se týkal suspend/resume, druhý při nonstop-běhu(screensaver))

[František Ryšánek]

Hele... suspend/resume byl tradičně tu a tam vachrlatej i na PCčkách, kde pro to má BIOS standardizované služby (dřív APM, později ACPI).

Ten ODROID s ARMem, má něco jako ACPI/EFI? Spíš pochybuju... ten suspend/resume bude spíš proprietární záležitost. Zahlédl jsem nějaké zmínky o závislosti na binárním blobu... Probuzení ze "suspend to RAM" nebo odemčení ze screensaveru (uspaný pouze video výstup? nebo změna video režimu) může mít nějaký společný zádrhel - bug v klubku ovladačů pro grafiku.

[Jan Fikar]

Tak u XU4 píší, že je potřeba 5V 4A zdroj a 6A pokud se používá s USB3 diskem. Raspberry Pi 4 oficiální zdroj má 3A a pro starší Raspberry Pi 1-3 je to jen 2,5A.

https://wiki.odroid.com/odroid-xu4/hardware/hardware

A jaký je důvod vypínání jader? Někdy dokonce spotřeba s vypnutým jádrem stoupne. Tak bych to nedělal.

[Ivan Brezina]

Kdysi hodne davno jsem videl situaci na AMD kdy hlavni CPU nesmelo provadet zadne IO operace, kdyz vedlejsi CPU bootovalo (Intel s tim nemel problem).

[mikesznovu]

Acpi tam není, myslim, ze ta je nějaké  dtb(o), lspci neeistuje

Ale mám zkušenost,že vždy když když dojde odroid přepálí spotřebu, dojde vždy k resetu a bootuje. A to se těžko stane v probuzení nebo při spánku nebo unlock screensaveru


Jinak zkoušel jsem probuzení a nikdy to nekleklo na nedostatek elektriky. Paradoxně když jsem 10x dal sleep+resumr nikdy nezamrznul

[Jan Fikar]

Ale mám zkušenost,že vždy když když dojde odroid přepálí spotřebu, dojde vždy k resetu a bootuje. A to se těžko stane v probuzení nebo při spánku nebo unlock screensaveru

Bych si myslel, že to takhle nejde zjednodušit. Když je nestabilní napájení, tak buď se to resetuje anebo jen zatuhne (pokud nemáte HW watchdog, ten by ten zatuhnutý SBC sám restartoval). Nejprve bych vyřešil napájení, aby se to prostě nedělo kvůli chvilkovému poklesu napětí a pak bych pátral dál.

[Vít Šesták (v6ak)]

Některý HW řeší brown-out, tedy při poklesu napětí se vypne, a zapne se až zase po zvýšení. Ale pokud brown-out neřeší (může jít i jen o vypnutou ochranu), pak pokles napětí pod nějakou úroveň může udělat leccos.

Raspberry Pi umí detekovat příliš nízké napětí a upozornit na něj. Aspoň pokud ten pokles není příliš strmý, aby Raspberry Pi nebylo schopno reagovat. Možná bude Odroid mít něco podobného.

A ekonomický pohled: možná investovat pár stovek do dobrého zdroje bude levnější než čas strávený laděním.