Tak jsem konecne dolaboroval a uz to opet funguje. Opravdu jsem musel kernel buildnout s upravenou hodnotou NKPT (puvodne NKPT=42, nyni jsem na NKPT=88 - nejnizsi hodnota co s velikosti meho MFSROOT nabootuje).
Moooc dekuji za spravne nasmerovani a snad to nekdy nekomu taky pomuze :) -- Mira Chlastak ----- Original Message ----- Od: "Dan Lukes" <d...@obluda.cz> Komu: "FreeBSD mailing list" <users-l@freebsd.cz> Odeslané: Sobota, 26. Leden 2019 12:57:55 Předmět: Re: FreeBSD 12 + mfs root - panic no memory to grow kernel On 25.1.2019 17:52, Mira Chlastak wrote: > Diky za popis. Rozdeleni pameti pro KERNEL a "others" beru v potaz. Jen > nevim, cim presne se to urcuje (kmem_size??) Driv se to (alespon u i386 kernelu) urcovalo primo pri prekladu. Priznam se, ze jak je to dneska, a navic na amd64 kernelu, nevim. Neni uplne vylouceny, ze tohle na amd64 potreba neni - preci jen, i386 (bez PAE) melo 4GB adresovatelne pameti. Take kazdy proces se do tohohle musel vejit, vcetne adresniho prostoru pro kernel - tam to byla trochu honicka to rozdelit aby se vesel kernel a pritom zustal nejaky rozmny prostor i pro uzivatelskou pamet. Na amd64 ma linearni adresu 48bitovou (v nejnovejsich procesory s petiurovnovym pagingem dokonce 57bitovou). Po uplne letmem pohledu do zdrojaku se mi zda, ze na amd64 se pro kernel vyhradil 2TB prostor linearni pameti (VM_MIN_KERNEL_ADDRESS - VM_MAX_KERNEL_ADDRESS) zcela napevno, pod heslem "to nemuze dojit". vm.kvm_size je read-only sysctl, ktere vraci prave (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS) tedy cca 2TB To samozrejme neznamena, ze do celeho tohohle linearniho prostoru je namapovana nejaka fyzicka pamet (tolik ji vetsinou v pocitaci ani neni) - ve skutecnosti je pro kernel pouzitelna jen pamet od VM_MIN_KERNEL_ADDRESS do kernel_vm_end vm.kvm_free je read-only sysctl, ktere vraci kolik jeste zbyva volne (VM_MAX_KERNEL_ADDRESS - kernel_vm_end) pmap_growkernel posouva hodnotu kernel_vm_end, jinymi slovy, zvetsuje kernelovy linearni pametovy prostor, do ktereho realne je namapovana nejaka fyzicka pamet (a tudiz ho lkze pouzivat). Takze posun kernel_vm_end neni jen prepsani te hodnoty, ono je treba "naalokovat" (vm_page_alloc) fyzickou pamet a namapovat ji do linearniho adresniho prostoru. pmap_growkernel zpanikari pozorovanym zpusobem prave tehdy, kdyz selze ten vm_page_alloc No, rozbor mozna peknej, ale nemyslim, ze te prilis posune k reseni. Nevidim zadny zjevny duvod, proc by alokace stranky (stranek) mela selhat - ledaze pamet pro preloaded MFS se alokuje jeste pred tim, nez je VM system naincializovanej a system tam ma k dispozici jen stranky prealokovane pri bootstrapu. To by vysvetlovalo, proc to pada u preloaded MFS, zatimco u plen inicializovanyho systemu uz totez MFS namountujes bez problemu. A tim jsme u hratek s NKPT. Nevim jestli mas kernel prelozenej s tim, a pokud ano, tak jake cislo. N ejdriv bych to mozna zkusil bez toho. Pokud to nepouze, tak s tim, ale nedrzet se s hodnou prilis "pri zdi". V "NOTES" pro AMD64 je uvedeno NKPT=31, coz se zda byt blbost - autotuningovy kod, ktery se pouzije, kdyz hodnotu nenadefinujes k tomu co "nejak odhadne" pricte 32 jako "rezervu pro jistotu". Takze pokud tam mas 31 z NOTES, nejsi ani na velikosti te rezervy. Aktualni velikost nkpt prozrazuje read-only sysctl machdep.nkpt Na stroji s 4GB to autotuning nastavi, hadam, tak na 40. Takze kdyz bude padat kernel prelozeny bez NPKT, zkusil byt to s nim, ale hodnotu tak nejmin 90. > Konkretne dane nastane pri nasledujicich velikostech mfs rootu (velikost > mfsrootu v B): > 58 799 104 -> funguje, nabootuje ok > 59 847 680 -> nefunguje, nenabootuje, nevyhodi kernel panic, ale po nacteni > mfsrootu se proces bootovani sekne (posledni je vypis "tocitka" indikujici > nacitani mfsrootu) > 62 902 784 -> nefunguje, nenabootuje a vyhodi zmineny kernel panic V prvnim pripade se "vsechno vejde". V druhem se samotny MFS se vejde, ale zbude tam uz jen malo volne pameti; "v ouzkejch" spatne zafunguje nejakej nedobre napsanej naslednej kod, kterej na nedostatek pameti nezareaguje dobre (nebo ho vubec nepozna a hrabne az za konec) a na tom to zvadne. No a posledni varianta je, ze uz se nevejde samotnej MFS ... Jen hadam. > Kernel samotny ma nejaky 13MB. Tzn. se vsim vsudy jsem pod 100MB. Tak to je nkpt aspon 82. To jsme s tim odhadem 90 nebyl zas tak vedle a ja bych, nejmene v pocatecnich fazich pokusu, radeji hodnotu mirne prestrelil. Pak muzes zkusit couvat, kdyz ti tech par mega pameti bude lito. > Drive jsem obcas na i386 bojoval s tim, ze jsem musel poladit NKPT, pokud byl > mfsroot kolem 100MB (nebo vetsi). Ja mam dojem, ze tech 32 bloku (64MB) rezervy uz se hodne dlouho nezvetsilo, ale naroky modulu a buhviceho jeste pomalinku rostou. Takze velikost MFS, kterou tam nactes bez poladeni hodnoty bude pomalu klesat. Mozna, ze 85MB uz je proste moc. A vysvetlovalo by to proc na 9-R jo a na 12-R ne. Ale cele tohle je jen hypoteza - muze to byt zpusobene necim uplne jinym a pak samozrejme tuning nkpt nepomuze. Pro tenhle pripad muzu jen zopakovat moji oblibenou zasadu "verzim X.0 se vyhybejte" pripadne "nenasazujte release hned jak vyjde" - ty's udelal oboji ... ;-) Dan > On 24.1.2019 14:47, Mira Chlastak wrote: >> se peru s RELENG_12 a MFS_ROOT. Do ted dana masina jela na RELENG_9 a vse >> slapalo > >> FreeBSD 12.0-RELEASE-p2 r343088 MOJE12-GENERIC amd64 >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM >> 6.0.1) >> panic: pmap_growkernel: no memory to grow kernel -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
