Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: mikesznovu 05. 02. 2023, 18:52:57
-
Máte někdo zkušenost, že by příkaz vypnutí jednoho nebo několika CPU v linuxu
přes
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í)
-
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? :)
-
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)
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 ()
-
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.
-
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 :D ) 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...
-
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?
-
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 [...]
-
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...
-
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))
-
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.
-
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.
-
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).
-
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
-
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.
-
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.
-
Tak to mě podrž.... Po 2 měsících se probral...
journalctl --no-hostname -k -r
May 07 15:29:57 kernel: wake enabled for irq 165
May 07 15:29:57 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
May 07 15:29:57 kernel: OOM killer disabled.
May 07 15:29:34 kernel: Freezing user space processes ... (elapsed 0.068 seconds) done.
Mar 03 00:48:46 kernel: Filesystems sync: 0.276 seconds
Mar 03 00:48:46 kernel: PM: suspend entry (deep)
Mar 02 20:06:51 kernel: wake enabled for irq 161
Mar 02 20:06:51 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Mar 02 20:06:51 kernel: OOM killer disabled.
Mar 02 20:06:51 kernel: Freezing user space processes ... (elapsed 0.005 seconds) done.
Mar 02 20:06:51 kernel: Filesystems sync: 0.053 seconds
Feb 28 01:37:19 kernel: PM: suspend entry (deep)
Feb 28 01:37:13 kernel: usb 1-1.2: USB disconnect, device number 4
Feb 28 00:42:13 kernel: mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)
Feb 28 00:42:13 kernel: mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80200000)
Feb 28 00:42:13 kernel: dwmmc_exynos 12220000.mmc: Busy; trying anyway
Feb 28 00:42:13 kernel: dwmmc_exynos 12220000.mmc: Card stuck in wrong state! card_busy_detect status: 0x0
Feb 28 00:42:13 kernel: mmc_host mmc1: Timeout sending command (cmd 0x200000 arg 0x0 status 0x80200000)
Feb 28 00:42:13 kernel: crng init done
jenom nevíte co je zač za toto? občas mi to zaspamuje dmesg (třeba 50 vzájemně za sebou ) ale asi
May 07 16:33:04 kernel: hid-generic 0003:1C1F:0200.000A: unknown main item tag 0x0
(1c1f:0200 je PID + VID), .000A bude asi endpoint nebo function
A k tomu by mě zajímal, jak má suspend + resume vliv na ("odsazení") výpisu dmesg?
Právě proto jsem použil journalctl -k
a takyy jounnalctl --list-boots hlásí
-1 74c7d21110d84033b382d9ccf3821486 Sun 2023-02-12 21:10:51 CET—Tue 2023-02-28 00:40:51 CET
0 c8d75227cb574064a8f16bc97d418b5a Tue 2023-02-28 00:42:13 CET—Mon 2023-05-08 11:05:01 CET
Jelikož dmesg | head začíná právě datem probuzení
zatímco uptime je 69days
-
No po probuzení si Linux přečte RTC a nastaví hodiny. Koukám, XU4 asi nemá RTC, takže v hodinách bude chaos do té doby, dokud se nesynchronizuje čas ntp nebo jak to děláte běžně.
HID v dmesg je nějaký vstupní zařízení (Human Interface Device), ale který konkrétně, to nevím.
Obecně ty SBC asi nemá cenu uspávat.