Pawel Jakub Dawidek (pjd_at_freebsd.org) on 08/10/2007 at 14:15 wrote: > Can you guys retry with this patch: > > http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch > > It's a hack, yes, but allows to mitigate the problem quite well. I'm > looking for a solution that can be used for 7.0 before we find a better > fix. > > BTW. To use ZFS you _must_ increase vm.kmem_size/vm.kmem_size_max. > If you have the problem discussed here and you're using standard values, > please retry with vm.kmem_size/vm.kmem_size_max set to at least 600MB in > /boot/loader.conf. Hi, On a Lenovo X61s from yesterday (FreeBSD 7.0-CURRENT #1: Sun Oct 7 21:55:14 CEST 2007) with hw.model: Intel(R) Core(TM)2 Duo CPU L7500 _at_ 1.60GHz hw.physmem: 2091008000 hw.machine_arch: i386 hw.realmem: 2104164352 and a single zpool containing ad4s2 slice (all FS except /). I tuned vm.kmem_size and ran ad vitam: - vt0: rsync /usr/src /tmp/. && rm -rf /tmp/src - vt1: dd if=/dev/zero of=/tmp/file bs=1k count=1000000 The kernel panics until vm.kmem_size/vm.kmem_size_max is set to 671088640 where I could have both loops running for 3 hours. But then the system was hanging: rsync and dd seem stopped in their execution. This was confirmed on another term (load of 0). Any attempt to R/W from the poll (touch/ls) hangs the terminal. I could still log in to a term, but reboot/shutdown failed. I applied your patch and re-run the tests. After eight hours, the kernel is still up and usable. Thanks Pawel. > I'm not sure if it's not too late to ask re_at_ about increasing the > default kmem size at least on amd64. ~300MB we have there is silly > small. Default vm.kmem_size value is 335544320 on my laptop: a portsnap fetch + extract from scratch panics with kmem_map too small. -- bugReceived on Mon Oct 08 2007 - 18:28:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC