Reproducable panic under heavy disk I/O on 5.4-latestandthegreatest

Kris Kennaway kris at obsecurity.org
Wed Sep 7 16:33:24 PDT 2005


On Wed, Sep 07, 2005 at 09:46:43PM +0300, Vasil Dimov wrote:
> The command that causes the panic is:
> 
> # duplicity / rsync://backuphost:873/kutelo1
> 
> It generally traverses the whole FS. When 500-600M are uploaded to
> backuphost, the machine (the one that runs duplicity command) panics.
> 
> Below I have attached "uname -a" and "ident /boot/kernel/kernel"
> commands output, the kernel config file, dmesg output and backtraces
> with WITNESS_COUNT set to 200 (default) and 20000.
> 
> Note that I get different panic 'reasons' with WITNESS_COUNT=200 vs.
> WITNESS_COUNT=20000.
> 
> Should I submit a PR (without a fix :/)?

> Unread portion of the kernel message buffer:
> panic: kmem_malloc(4096): kmem_map too small: 40886272 total allocated

This indicates you're running your kernel out of memory.  Try tuning
VM_KMEM_SIZE_MAX, e.g.

options         VM_KMEM_SIZE_MAX=524288000      #500MB

> lock order reversal
>  1st 0xc15aa798 inp (tcpinp) @ netinet/tcp_usrreq.c:371
>  2nd 0xc071ae00 ipf filter rwlock (ipf filter rwlock) @ contrib/ipfilter/netinet/fil.c:1107

This indicates that ipf is broken on SMP, as is well-known.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050907/768cc5f6/attachment.bin


More information about the freebsd-hackers mailing list