atom feed43 messages in org.freebsd.freebsd-stablepanic: kmem_malloc(16384): kmem_map t...
FromSent OnAttachments
Mikhail TeterinFeb 27, 2007 3:58 pm 
Alex KozlovFeb 27, 2007 5:05 pm 
Mikhail TeterinFeb 27, 2007 7:47 pm 
Alex KozlovFeb 27, 2007 8:54 pm 
Mikhail TeterinFeb 27, 2007 9:03 pm 
Kris KennawayFeb 27, 2007 9:09 pm 
Mikhail TeterinFeb 27, 2007 9:24 pm 
Kris KennawayFeb 27, 2007 9:28 pm 
Kris KennawayFeb 27, 2007 9:51 pm 
Michael ProtoFeb 27, 2007 10:20 pm 
Michael ProtoFeb 27, 2007 10:20 pm 
Yar TikhiyMar 4, 2007 8:27 am 
Alex KozlovMar 4, 2007 8:46 am 
Kris KennawayMar 5, 2007 3:59 am 
Yar TikhiyMar 5, 2007 1:24 pm 
Mikhail TeterinMar 5, 2007 6:40 pm 
Yar TikhiyMar 5, 2007 7:17 pm 
Kostik BelousovMar 5, 2007 8:00 pm 
Yar TikhiyMar 5, 2007 8:13 pm 
Scott LongMar 5, 2007 9:13 pm 
Artem KuchinMar 5, 2007 9:43 pm 
Jack VogelMar 5, 2007 10:21 pm 
Steven HartlandMar 5, 2007 10:26 pm 
Jeremy ChadwickMar 6, 2007 12:07 am 
Charles SprickmanMar 6, 2007 3:14 am 
Artem KuchinMar 6, 2007 8:47 am 
Tom JudgeMar 6, 2007 10:09 am 
Artem KuchinMar 6, 2007 10:53 am 
Tom JudgeMar 6, 2007 11:08 am 
Artem KuchinMar 6, 2007 11:24 am 
Yar TikhiyMar 6, 2007 1:16 pm 
Artem KuchinMar 6, 2007 1:25 pm 
Jack VogelMar 6, 2007 6:04 pm 
Vivek KheraMar 6, 2007 8:16 pm 
Jack VogelMar 6, 2007 9:09 pm 
Torfinn IngolfsenMar 7, 2007 12:16 am 
Danny BranissMar 7, 2007 7:36 am 
Jeremy ChadwickMar 7, 2007 9:24 am 
Jan MikkelsenMar 7, 2007 12:51 pm 
ian j hartMar 7, 2007 9:40 pm 
Jeremy ChadwickMar 7, 2007 10:05 pm 
ian j hartMar 7, 2007 10:50 pm 
ParvMar 12, 2007 10:25 pm 
Subject:panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
From:Alex Kozlov (sp@rm-rf.kiev.ua)
Date:Mar 4, 2007 8:46:49 am
List:org.freebsd.freebsd-stable

On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:

On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:

On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = > Yes, I switched to swap-backed md already. But the malloc-based variety is = > currently the _default_ (see /etc/defaults/rc.conf)... = Bad default.

Filing a PR.

Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed.

#sudo swapoff /dev/ad4s2b #swapinfo Device 1K-blocks Used Avail Capacity

#mdconfig -d -u 666 && \ mdconfig -a -t swap -s10000M -u 666 && \ bsdlabel -w /dev/md666 auto && \ newfs -U -f 512 -b 4096 -i 512 -m 0 /dev/md666a && \ mkdir /tmp/mdtest && \ mount /dev/md666a /tmp/mdtest $dd if=/dev/zero of=/tmp/mdtest

#df /tmp/mdtest Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md666a 3561822 3561622 200 100% /tmp/mdtest #dmesg Mar 4 10:20:35 ravenloft kernel: pid 97529 (firefox-bin), uid 1001, was killed: out of swap space Mar 4 10:20:39 ravenloft kernel: pid 79658 (Xorg), uid 0, was killed: out of swap space Mar 4 10:20:40 ravenloft kernel: pid 519 (thunderbird-bin), uid 1001, was killed: out of swap space

Ouch, but this is still better than panic.

By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M "for maximum performance and system stability at low memory conditions". When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good.

= > Creation of a 2Gb malloc-based md should've failed on a machine with = > 768Mb of RAM, shouldn't it have? = Only if you set '-o reserve'. Memory for malloc-based md was allocated = dynamically.

But malloc can only allocate from RAM, right? So the amount of RAM is the hard limit, which a malloc-based md can not exceed even in theory. This means, md-creation should've failed...

In fact, the limit should, of course, be even lower -- and mdmfs should be smart enough to substract the sizes of other kernel memory chunks from the maximum.

Since even that would still not be a guarantee against running out, the system should be able to recover gracefully instead of panicing. Do you agree?

FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem.