On 14.2.2019 12:51, Jindrich Fucik wrote:
Ale asi to nebyla úplná příčina smrti, hláška regulérně dopadla do
/vzr/log/messages a normálně prošla syslogem. Počítač asi zdechnul malou
chvilku po této hlášce.
No, to skutecne nebyla - zminena udalost neni "panic" ale prosty error.
Funkce vrati nulu. Kdyby se alokace povedla, funkce by incializovala
td->td_kstack_obj, td->td_kstack, td->td_kstack_pages a vratila by jednicku.
vm_thread_new se vola jen ze dvou mist - z thread_alloc a
thread_alloc_stack, obe navratovou hodnotu kontroluji a samy reaguji
tim, ze vrati NULL respektive 0.
Jeste o uroven vys se dostavame na tri funkce - kthread_add,
kern_thr_alloc a fork1 - a i ty vsechny navratovou hodnotu kontroluji a
samy vraci ENOMEM, pokud doslo k chybe.
Dal uz se ale strom volani rozvetvuje prilis a "rucni hledani" tak k
cili nevede. Navic je zde moznost, ze pricina padu s uvedenou hlaskou
nesouvisi vubec a kernel spadl ze zcela jinych duvodu.
Takze jestli se chces pohnout dal, potrebujes coredump.
Počítač ani nemá swap, což je také běžné, protože se často provozuje z SD karty
a ta snáší zápisy skutečně špatně.
Ty tam ale nemas SD ale SSD. Ani tomu sice neni pocet zapisu jedno, ale
preci jen je to vyrazne jinde. Ty bys swap mit mohl. jestli pomuze
nevim, ale zkusit se to da. Pomoci by mohl i kdyby tahle pamet
swapovatelna nebyla - se swapem se fyzicka pamet uvolni odswapovanim
neceho jineho.
A swap o velikosti minimalne fyzicke pameti (plus neco malo navic) by
navic po padu umoznil vytvoreni coredumpu, ze ktereho by mohlo byt
poznat lepe na co to vlastne spadlo.
Dnes periodic proběhl správně a na nic si nestěžuje. Tak to budu ještě nějakou
dobu pozorovat.
Tohle muze mit nahodnou miru "zjeveni". Muze zalezet nejen na tom, co
dela proces aktualni, ale i na tom co delal proces predchozi (a jak je
to davno). V zasade to znamena, ze se pohybuejs nekde na hrane moznosti
- a nekdy to spadne za hranu a nekdy ne.
Krome pokusu se zalozenim swapu si muzes zkusit jeste hrat se
sysctl vm.kstack_cache_size
To se selhane alokace bezprostredne tyka - k hlasce, ktera se ti
objevila kod nemuze dojit, pokud je pozadovana velikost pameti dostupna
v kstack_cache (to je prave rezerva pro budouci alokace). Vetsi cache by
mohla tlak na alokator snizit a situaci zlepsit. A nebo taky ne, protoze
bude vic pamet vazane v cache a tim nebude dostupna pro zase jine
pozadavky (muze ti to tedy zacit padat na nedostatek jine pameti).
A kazdopadne, nevime, jestli se to vubec tyka padu ;-)
Dan
Feb 13 03:05:00 stroj kernel: vm_thread_new: kstack allocation failed
Podle me jde o kernelovy stack, ktery potrebuje kazdy proces.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
