kernel parameterkent:
iommu=soft swiotlb=131072
most nem esik el.
igazabol nem akarok belemenni, hogy miert, ez a PC architectura kulonosen undorito bugyraihoz tartozik.
Azert lehetne a linux kernelben az swiotlb meretezese dinamukus, a memoria mennyisegetol fuggo.
- egeresz blogja
- A hozzászóláshoz be kell jelentkezni
- 1232 megtekintés
Hozzászólások
mi akasztotta ki konkretan?
van valami egyszeru test-case, amivel masik gepet is ki lehet akasztani?
- A hozzászóláshoz be kell jelentkezni
intel nehalem alapu nfs szerver 32Gi -nel tobb memoriaval
nx_nic ethernet driver
12 darab gigabites diskless kliens a kovetkezo jelegu programmal:
merge 20Gfile1 20Gfile2 | grep valamiminta > outputfile
2-3 ora mulva esett el, sok-sok ilyen a logban:
swapper: page allocation failure. order:2, mode:0x20
Pid: 0, comm: swapper Not tainted 2.6.26-2-amd64 #1
Call Trace:
<IRQ> [<ffffffff80276c15>] __alloc_pages_internal+0x3a6/0x3bf
[<ffffffff802957ec>] kmem_getpages+0x96/0x15f
[<ffffffff80295e7c>] fallback_alloc+0x16b/0x1e1
[<ffffffff80295a59>] kmem_cache_alloc_node+0x105/0x138
[<ffffffff803b6799>] __alloc_skb+0x64/0x12d
[<ffffffff803b7707>] __netdev_alloc_skb+0x29/0x43
[<ffffffffa0247b7f>] :nx_nic:nx_alloc_rx_skb+0x27/0xe9
[<ffffffffa024bcf1>] :nx_nic:nx_nic_poll_sts+0x5a3/0x254b
- A hozzászóláshoz be kell jelentkezni
"igazabol nem akarok belemenni, hogy miert, ez a PC architectura kulonosen undorito bugyraihoz tartozik."
Kár, hogy nem mész bele. Pedig mi itt úgy, de úgy szeretünk borzongani. :)
- A hozzászóláshoz be kell jelentkezni
nahat, szia :-)
csak gyenge tippeim vannak a dolog mukodeserol, hogy egyaltalan van ilyen/kell ilyen a 'modern PC architecturaba' azt csak e hiba kapcsan jutott a tudatomra.
delutan talan megirom.
- A hozzászóláshoz be kell jelentkezni
http://en.wikipedia.org/wiki/IOMMU
http://lxr.linux.no/#linux+v2.6.38/Documentation/x86/x86_64/boot-option…
http://www.kernel.org/doc/gorman/html/understand/understand012.html#hto…
Tipp: a NIC / IOMMU által hardveresen DMA-zható tartományban nem volt elég szabad RAM a brutális igénybevétel kiszolgálásához. Ezért figyelmen kívül hagyattad a hardveres IOMMU-t (iommu=soft). Előre lefoglaltad az empirikusan szükséges helyet alacsony RAM-ban (swiotlb=131072; ezen egy kicsit meg vagyok lepődve, mert ha ez valóban a 128K-s lapok darabszáma, akkor ez 16G). A kártya erről a "pattintós" területről DMA-zik közvetlenül. Így a küldeni való adatot a magas RAM-ból korábban külön oda kell másolni. Plusz fogadás esetén fordítva.
Az nx_alloc_rx_skb()-ből azt gondolom, hogy fogadni próbált a kártya, de a DMA-zható tartományban nem volt hova. Ha jól sejtem / tippelem, a "mode:0x20" a GFP_HIGH-nak felel meg, tehát fontos lett volna, hogy sikerüljön az allokáció.
Mi volt a dmesg előtte és utána? Köszi!
Kieg: ha jól emlékszem, régen a Sound Blaster 16 ISA kártyának kellett az alsó 64K-ban helyet foglalni.
- A hozzászóláshoz be kell jelentkezni
"iommu=soft swiotlb=131072"
az a kartya (nx_nic) leirasaban volt benne, mint 32 Gi feletti szervereknel workaround. Pontosabban a 4 eves leirasaban, mert azota a ceget felvasarola a qlogic, es a qlogic mar nem irt ilyen reszletesen a doksiban...
ez intel, ebben csak soft iommu van. opteronnal van (egyes draga szerverekben) ennek hw tamogatasa. valamekkora swiotbl mindig van, a dmesg szerint default ennek toredeke.
Ugyesebb vagy, mint en (vagy kitartobb) en nem talaltam meg, hogy mi a mertekegyseg.
- A hozzászóláshoz be kell jelentkezni
azt hiszem, arrol van szo, hogy a fizikai memoria hasznalatahoz szukseg van laptablara, ami a CPU-nak szol (a kernel tolti ki, es a CPU ertelmezi)
hagyomanyosan az IO ebben a lapozasos buliban nem vesz reszt, az IO a fizikai memoriaba valahova pakol. Ezek a pakolasi helyek a memoriaban lukak, az architektura tervezo a cimter tetejere teszi. MIvel a PC regi, sokszor fejlesztett architektura, igy van benne luk, a 8088, 80286, 386, cimtartomanyainak vegen egyszerre, valamint a 64 bites tartomanyban is elhelyeztek egyet. Mashol van a PCI es mashogy a PCI-e tartomanya. Ezeket mindenfele takarekossagi okokbol ossz-vissza lehetett mappelni, melyik gepben hol. Ezt nem a cpu csinalja, hanem az alaplap.
Aztan jott ez a virtualizacios jatek, es de jo lenne, ha ez a mappeles nem csak nehany ide-oda lenne, hanem tetszolegesen a virtualis terbe: tehat az IO is teljes laptablat kapna. Tehat kellene egy laptabla, amit nem a CPU ertelmez, hanem az IO (szuper otlet: ketszer nyilvantartani ugyanolyan celu adatot).
a laptablenak el kell fernie valahol. A kernel allokal neki helyet, a kernel tolti ki, de nem a kernel ertelmezi. Az a gyanum, hogy default beallitasoknal az IO-ra vonatkozo laptabla csak az also 32Gi teruletet fedi le, tehat nem tud IO-zni a felso tartomanyba. A kernel mas reszei (buffer, vfs es egyeb lapmanagement) viszont egybe lattak a 72Gi teruletet. igy egyszeruen elfogyott az also 32Gi, kellett volna egy lap, de laptabla-kicsinyseg miatt nem lehetett kiadni, hiba volt meg boven a 70Gi kornyeken.
Azt hiszem, hogy az swiotbl erteke laptabla-meret, vagy legalabbis laptabla meret is.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni