panic kmem_malloc .. bei make von einem port

R

rakso

Well-Known Member
hallo zusammen,

beim make `en von enigmail-thunderbird bekomme ich reproduzierbar immer einen crash:


den Tip aus der FAQ habe ich schon umgesetzt: Eigener kernel mit options VM_KMEM_SIZE_MAX=419430400)

( http://www.freebsd.org/doc/de/books/faq/troubleshoot.html#KMEM-MAP-TOO-SMALL )

Die Kiste hat 2GB RAM, 4GB SWAP, ZFS, FBSD 9


viel größere Projekte wie gnome, firefox, thunderbird ließen sich jedoch bauen!!

Hat jemand einen Idee woran das liegen könnte und was ich dagegen tun kann?

Grüße
 
Mehr RAM. Die Größe der Pointer legt nahe das es sich ein FreeBSD/i386 handelt. ZFS braucht halt nunmal mehr Kernel RAM als die 2GB, die FreeBSD/i386 ermöglicht. Afaik ist ein Großteil von ZFSs Speicherbedarf auch nicht swappable. Die "Lösung" wäre als FreeBSD/amd64 mit >= 4GiB RAM.

Alternativ natürlich $search_engine fragen wie man den ARC cache begrenzt und die kmem_map vergrößert per loader.conf. Jedoch ist und bleibt das unsauber.
 
Zuletzt bearbeitet:
3,irgendwas GB an RAM kann doch auch i386, oder?!

mich als Laie wundert es, dass große sourcen compiliert werden können, es aber dann an nem mailer-plugin scheitert.

dann muss ich wohl die Kiste komplett austauschen.
 
Je moderner die Hardware um so mehr von den 4GiB verliert man an die Hardware. Eine Grafikkarte kann schon mal 1GiB Adressraum belegen. AHCI Controller, NICs und sonstige PCI(-e) Devices wollen alle ihre DMA Bereiche. So ist der Adressraum schnell voll. Steck einfach 4GiB RAM rein, wenn du es rumfliegen hast und teste es. Du müsstes dann damit leben nur um die 3GiB davon nutzen können. Ohne reduzierte Caches ist ZFS auf 32Bit Systemen einfach nicht stabil. Und auch mit Tuning ist es unzuverlässig bei Änderungen. Warum muss es auf so einer alten Gurke ZFS sein? UFS2 funktioniert doch und dürfte auch schneller sein auf so alter Hardware. Du willst doch mit deinem RAM noch was anderes machen als ZFS Caches ablegen.
 
mit options KVA_PAGES=512 im kernel gehts (bis jetzt).
55MB RAM Active, 2,2GB RAM frei - verstehe das problem nicht.
an ufs dacht ich nicht, nächstesmal bei der kiste schon, neu installieren will ich jetzt nichtmehr.. läuft ja soweit.
 
Das Problem ist, dass FreeBSD/i386 eine statische Aufteilung des doch sehr begrenzten Adressraums nutzt. 1GB Kernel, 3GB Prozesse. D.h. egal wie viel RAM du da tatsächlich drin hast, kann der Kernel maximal 1GB adressieren und für sich nutzen. Für ZFS schlicht zu wenig. Hinzu kommt das Problem der Speicherfragmentierung. Bei nur ein 1GB führt ZFS praktisch zwangsläufig dazu, dass der Speicherbereich des Kernel stark fragmentiert und irgendwann eine Anoferung eines größeren, zusammenhändenden Speicherbereichs nicht mehr erfüllt werden kann. Das führt dann augenblicklich zur "kmem_map too small" Panic. Das "KVA_PAGES=512" macht es alles etwas weniger kritisch, da er die Speicheraufteilung zu gunsten des Kernel zu 2GB Kernel und 2GB Userland verschiebt. Aber der Preis ist eine Änderung des Prozesslayouts, was gerade bei "niederen" Prozessen wie Emulatoren Nebenwirkungen haben kann.
 
Yamagi schrieb:
Das Problem ist, dass FreeBSD/i386 eine statische Aufteilung des doch sehr begrenzten Adressraums nutzt. 1GB Kernel, 3GB Prozesse. D.h. egal wie viel RAM du da tatsächlich drin hast, kann der Kernel maximal 1GB adressieren und für sich nutzen. Für ZFS schlicht zu wenig. Hinzu kommt das Problem der Speicherfragmentierung. Bei nur ein 1GB führt ZFS praktisch zwangsläufig dazu, dass der Speicherbereich des Kernel stark fragmentiert und irgendwann eine Anoferung eines größeren, zusammenhändenden Speicherbereichs nicht mehr erfüllt werden kann. Das führt dann augenblicklich zur "kmem_map too small" Panic. Das "KVA_PAGES=512" macht es alles etwas weniger kritisch, da er die Speicheraufteilung zu gunsten des Kernel zu 2GB Kernel und 2GB Userland verschiebt. Aber der Preis ist eine Änderung des Prozesslayouts, was gerade bei "niederen" Prozessen wie Emulatoren Nebenwirkungen haben kann.
Zum Vergrößern anklicken....

kurz nachgefragt, denn ich habe auch noch alte i386er Gurken:

-Ist das der Grund, weshalb mir bei vorhandenen 4GB RAM immer nur ca 3GB als nutzbar angezeigt werden?

-Wenn 4GB bei 32Bit maximal ist (es ist, keine Frage!), welchen Sinn macht dann wohl ein SWAP, der über diese Größe hinaus geht? Ich rede hier von der klassischen Empfehlung, SWAP = 2x RAM, gegen die ich ja an-stänkere, wo immer ich Gelegenheit dazu finde.
 
FreeBSD kann einen Swap deutlich größer als 4GiB auf i386 verwalten. Allerdings kann kein Prozess mehr als by default 2GiB ohne weiters nutzen, weil sein Adressraum nicht mehr als 2GiB beträgt. Letzteres ist auch sehr lästig, wenn man eine größere Datei mit mmap() bearbeiten will.
 
pit234a schrieb:
Ist das der Grund, weshalb mir bei vorhandenen 4GB RAM immer nur ca 3GB als nutzbar angezeigt werden?
Zum Vergrößern anklicken....
Nein, das ist das "Memory Hole"-Problem. Normalerweise werden Addon-Geräte (egal ob eingesteckt oder fest verlötet) über Speicheradressen angesprochen. D.h. sie tauchen einfach als ein spezieller Bereich im RAM auf, was dorthin geschrieben wird, landet automatisch auf der Karte. Da ein i386-Bit System aber maximal 4GB ansprechen kann, verdecken die Karten logischerweise einen Teil deiner 4GB RAM. Dieser verdeckte Teil wird dann unansprechbar, kann vom System also nicht genutzt werden. Nur 1GB Verlust wie bei dir ist übrigen harmlos. Ich habe hier alte Serverboards, auf denen 1,5 bis 2GB verloren gehen...
 
ich gebe mich geschlagen, wieder der crash, nach längerer zeit beim compilieren. also neuinstallation auf ufs :(
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben