RE: mini-HEADSUP bce owners: please test
> That should be the packet length fix at line 5973 of if_bce.c. I did That's the patch whcih was sent to the PR, yes ? I've tried that and it doesn't fix it at all for me unfortunately. > not test the teaming fix myself but another user provided a similar > packet length fix which he claimed did fix the issue so I'm hopeful > that this should work for you too. I'll tgive this new lot of code a test tomorrow (am in London all day today unfortunately) and let you knwo the results. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: mini-HEADSUP bce owners: please test
Well, I found time to test this today after all - and it does actually fix the issue - my bce devices now work properly with lagg and lacp. thankyou! -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
manageBE and ZFS boot-environments WAS [Re: ZFS NAS configuration question]
Dan Naumov wrote: > Anyone else think that this combined with freebsd-update integration > and a simplistic menu GUI for choosing the preferred boot environment > would make an _awesome_ addition to the base system? :) I guess freebsd-update is not a problem, should be "freebsd-update -b ". But I can't test this, because I can't update STABLE with freebsd-update. ;-) I wrote a small step-by-step example to show how stuff works: http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/example.txt greetings, philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: mini-HEADSUP bce owners: please test
> Well, I found time to test this today after all - and it does > actually fix the issue - my bce devices now work properly > with lagg and lacp. Thanks for the confirmation. Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kmem map too small panic after updating to STABLE-7 r192996
Hello, I decided to give the new zfs code a try and upgraded my stable-7 system and discovered a panic that I can reproduce at will. This is an i386 system with 1.5GB of RAM and a single zfs pool: appbuild# zpool status pool: backup state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAMESTATE READ WRITE CKSUM backup ONLINE 0 0 0 mirrorONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors I had previously used the following zfs tuning: vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" After getting this panic, I removed these tunables. The panic happens in either case. Reproducing the panic is easy: I keep a copy of the FreeBSD svn tree in a compressed zfs file system (compression ratio runs around 1.35x). An "svn update" (or the requisite "svn cleanup" following a system crash) in my checkout area will _always_ result in a "kmem map too small" panic. Here's a stack trace from my most recent panic: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc052c963 in boot (howto=260) at /root/stable-7/sys/kern/kern_shutdown.c:418 #2 0xc052cb9d in panic (fmt=Variable "fmt" is not available. ) at /root/stable-7/sys/kern/kern_shutdown.c:574 #3 0xc069fa2a in kmem_malloc (map=0xc105408c, size=131072, flags=2) at /root/stable-7/sys/vm/vm_kern.c:305 #4 0xc0696587 in page_alloc (zone=0x0, bytes=131072, pflag=0xe6dbcb47 "\002", wait=2) at /root/stable-7/sys/vm/uma_core.c:952 #5 0xc0699000 in uma_large_malloc (size=131072, wait=2) at /root/stable-7/sys/vm/uma_core.c:2706 #6 0xc051af38 in malloc (size=131072, mtp=0xc094f060, flags=2) at /root/stable-7/sys/kern/kern_malloc.c:393 #7 0xc085db00 in zfs_kmem_alloc (size=131072, kmflags=2) at /root/stable-7/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 #8 0xc08d1c79 in zio_buf_alloc (size=131072) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 #9 0xc08bcc40 in vdev_queue_io_to_issue (vq=0xc492b334, pending_limit=Variable "pending_limit" is not available. ) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 #10 0xc08bce42 in vdev_queue_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 #11 0xc08d4162 in zio_vdev_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1847 #12 0xc08d2532 in zio_execute (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #13 0xc0862aa0 in taskq_thread (arg=0xc44a10cc) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 #14 0xc0506816 in fork_exit (callout=0xc0862960 , arg=0xc44a10cc, frame=0xe6dbcd38) at /root/stable-7/sys/kern/kern_fork.c:811 #15 0xc06d4670 in fork_trampoline () at /root/stable-7/sys/i386/i386/exception.s:264 (kgdb) print panicstr $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 total allocated" The arc size is now auto-tuned as: kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 and while monitoring kstat.zfs.misc.arcstats.size I noticed it fluctuated between around 140 and 150 million. Interestingly enough, immediately before the last panic, It (arcstats.size) had just been reduced from 150038268 to 128790020. I'm going to continue to poke around in my core dumps and see if I can figure out what's going on. Any hints as to what to look for or monitor while the system is running would be appreciated. Thanks, Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
floppy unusable in VMWare guest?
I'm trying to use a virtual floppy from FreeBSD 7 (both 7-STABLE and 7_2_RELEASE) in a VMWare test installation. Both running fdformat on a fresh floppy image and trying to mount a preformatted one, I get errors like: g_vfs_done():fd0[READ(offset=0, length=8192)]error = 6 Of course, after booting the same VM with a DOS live CD, the floppy is perfectly functional. I found a reference in a vmware forum post (some three years old), does anybody know if this is supposed to work? http://communities.vmware.com/thread/51022 Thanks, Angelo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
Tim Chase wrote: Hello, I decided to give the new zfs code a try and upgraded my stable-7 system and discovered a panic that I can reproduce at will. I just had the same problem, and it turned out I was not diligent when I first set my zfs pool up :) To use vm.kmem_size="512M" you need to put options KVA_PAGES=512 in your kernel. I remember trying the loader.conf settings on a GENERIC kernel, found it worked and forgot to add KVA_PAGES. It seems that recently the memory allocated by a ZFS kernel on startup has become larger than the default KVA_PAGES in GENERIC. Hope this helps, Angelo Turetta ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
On Jun 4, 2009, at 10:48 AM, Tim Chase wrote: vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 total allocated" It looks like you are suffering from fragmentation of your kmem address space. I've done some investigation of this on -current: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=909067+0+archive/2009/freebsd-current/20090503.freebsd-current The patch linked from that mail allows me to run with an untuned ARC size with kmem of 512 MB. It does this, however, by more aggressively limiting how the ARC grows so it doesn't need to trigger its aggressive memory reclamation algorithm. I haven't tested this patch against -stable or with Kip's more recent changes so I don't know if it will apply cleanly for you. I've had some luck avoiding the fragmentation by changing ZFS to use a separate memory pool with a 128KB slab allocator, but this isn't really ready for general usage. Unfortunately I've been quite busy at work lately and haven't had time to work on it in a few weeks. I think with the current code base your only options are to increase your kmem maximum or limit your ARC even further. I hope that helps. - Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
As I mentioned in the initial e-mail, auto-tuning is only safe to rely on on amd64. -Kip On Thu, Jun 4, 2009 at 7:48 AM, Tim Chase wrote: > Hello, > > I decided to give the new zfs code a try and upgraded my stable-7 system > and discovered a panic that I can reproduce at will. > > This is an i386 system with 1.5GB of RAM and a single zfs pool: > > appbuild# zpool status > pool: backup > state: ONLINE > status: The pool is formatted using an older on-disk format. The > pool can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, > the > pool will no longer be accessible on older software versions. > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > backup ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > > errors: No known data errors > > I had previously used the following zfs tuning: > > vm.kmem_size="512M" > vm.kmem_size_max="512M" > vfs.zfs.arc_max="100M" > > After getting this panic, I removed these tunables. The panic happens > in either case. > > Reproducing the panic is easy: I keep a copy of the FreeBSD svn tree > in a compressed zfs file system (compression ratio runs around 1.35x). > An "svn update" (or the requisite "svn cleanup" following a system crash) > in my checkout area will _always_ result in a "kmem map too small" panic. > Here's a stack trace from my most recent panic: > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc052c963 in boot (howto=260) at > /root/stable-7/sys/kern/kern_shutdown.c:418 > #2 0xc052cb9d in panic (fmt=Variable "fmt" is not available. > ) at /root/stable-7/sys/kern/kern_shutdown.c:574 > #3 0xc069fa2a in kmem_malloc (map=0xc105408c, size=131072, flags=2) at > /root/stable-7/sys/vm/vm_kern.c:305 > #4 0xc0696587 in page_alloc (zone=0x0, bytes=131072, pflag=0xe6dbcb47 > "\002", wait=2) > at /root/stable-7/sys/vm/uma_core.c:952 > #5 0xc0699000 in uma_large_malloc (size=131072, wait=2) at > /root/stable-7/sys/vm/uma_core.c:2706 > #6 0xc051af38 in malloc (size=131072, mtp=0xc094f060, flags=2) at > /root/stable-7/sys/kern/kern_malloc.c:393 > #7 0xc085db00 in zfs_kmem_alloc (size=131072, kmflags=2) > at > /root/stable-7/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 > #8 0xc08d1c79 in zio_buf_alloc (size=131072) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 > #9 0xc08bcc40 in vdev_queue_io_to_issue (vq=0xc492b334, > pending_limit=Variable "pending_limit" is not available. > ) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 > #10 0xc08bce42 in vdev_queue_io_done (zio=0xd420a000) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 > #11 0xc08d4162 in zio_vdev_io_done (zio=0xd420a000) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1847 > #12 0xc08d2532 in zio_execute (zio=0xd420a000) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 > #13 0xc0862aa0 in taskq_thread (arg=0xc44a10cc) > at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 > #14 0xc0506816 in fork_exit (callout=0xc0862960 , > arg=0xc44a10cc, frame=0xe6dbcd38) > at /root/stable-7/sys/kern/kern_fork.c:811 > #15 0xc06d4670 in fork_trampoline () at > /root/stable-7/sys/i386/i386/exception.s:264 > (kgdb) print panicstr > $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 total > allocated" > > > The arc size is now auto-tuned as: > > kstat.zfs.misc.arcstats.c_min: 26214400 > kstat.zfs.misc.arcstats.c_max: 209715200 > > and while monitoring kstat.zfs.misc.arcstats.size I noticed it fluctuated > between around 140 and 150 million. Interestingly enough, immediately > before the last panic, It (arcstats.size) had just been reduced from > 150038268 to 128790020. > > I'm going to continue to poke around in my core dumps and see if I can > figure out what's going on. Any hints as to what to look for or monitor > while the system is running would be appreciated. > > Thanks, > Tim > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list
Re: mini-HEADSUP bce owners: please test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Pete, Pete French wrote: > Well, I found time to test this today after all - and it does actually > fix the issue - my bce devices now work properly with lagg and lacp. So can we claim that the problem has been solved? Could you please give us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev /sys/dev/mii/brgphy*'? Thanks a lot! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkooOpAACgkQi+vbBBjt66AfmACgiBt6eFHw8FKb5ePxrHemUgQh PUoAoJGN/rDDoROe6s7mW3PRWNHtOOzr =ukF3 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mini-HEADSUP bce owners: please test
> So can we claim that the problem has been solved? Could you please give > us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev > /sys/dev/mii/brgphy*'? Yes, it looks very much that way. I've no idea what changed to fix it, but it is certainly working now on my test machine. I will try a rollout to my other machines over the next few days. Here is the ident output: [webad...@florentine ~]$ ident /sys/dev/bce/* /sys/dev/mii/miidevs /sys/dev/mii/brgphy* /sys/dev/bce/if_bce.c: $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.9 2009/06/01 10:49:08 delphij Exp $ /sys/dev/bce/if_bcefw.h: $FreeBSD: src/sys/dev/bce/if_bcefw.h,v 1.4.2.2 2009/03/31 01:01:01 delphij Exp $ /sys/dev/bce/if_bcereg.h: $FreeBSD: src/sys/dev/bce/if_bcereg.h,v 1.16.2.3 2009/05/20 21:13:49 delphij Exp $ /sys/dev/mii/miidevs: $FreeBSD: src/sys/dev/mii/miidevs,v 1.46.2.11 2009/06/02 23:30:02 davidch Exp $ $NetBSD: miidevs,v 1.6 1999/05/14 11:37:30 drochner Exp $ /sys/dev/mii/brgphy.c: $FreeBSD: src/sys/dev/mii/brgphy.c,v 1.70.2.6 2009/06/02 23:30:02 davidch Exp $ /sys/dev/mii/brgphyreg.h: $FreeBSD: src/sys/dev/mii/brgphyreg.h,v 1.10.2.1 2008/06/27 03:24:54 jhb Exp $ cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
On Thu, Jun 4, 2009 at 2:13 PM, Kip Macy wrote: > As I mentioned in the initial e-mail, auto-tuning is only safe to rely > on on amd64. > Tying ZFS in to UMA to allow zone limits to reduce memory pressure on write as well as reduce the ARC's ability to grow without bound is on my to do list. However, I haven't gotten to it yet. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
On Thu, 4 Jun 2009, Kip Macy wrote: As I mentioned in the initial e-mail, auto-tuning is only safe to rely on on amd64. OK, that wasn't clear to me with the latest zfs code. I'll try it with a proper 512M setting as I was using before (along with setting KVA_PAGES). - Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kmem map too small panic after updating to STABLE-7 r192996
On Thu, 4 Jun 2009, Angelo Turetta wrote: Tim Chase wrote: Hello, I decided to give the new zfs code a try and upgraded my stable-7 system and discovered a panic that I can reproduce at will. I just had the same problem, and it turned out I was not diligent when I first set my zfs pool up :) To use vm.kmem_size="512M" you need to put options KVA_PAGES=512 ... Thanks for the reminder. I had forgotten about this one, too. With my kmem size @ 512M now and with KVA_PAGES at 512, my svn test case works just fine. I guess I should have paid closer attention to the actual panic message. - Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Inconsistent checkout results for RELENG_7 at exact date
Hello! I'm trying to check out the FreeBSD source tree with the tag=RELENG_7 in the same state that it had at the exact date/time, e.g. 2009-05-04 18:00 UTC. So I'm using the following supfile: *default host=cvsup.ua.freebsd.org *default base=/root/sup/base *default delete use-rel-suffix compress *default release=cvs *default prefix=/usr/ftp/RELENG_7 tag=RELENG_7 date=2009.05.04.18.00.00 src-all I am starting with empty /usr/ftp/RELENG_7/src. However I am consistently (with both csup and cvsup) getting files that weren't in RELENG_7 at the specified time, e.g. src/cddl/usr.bin/zinject/Makefile (it was MFCed only 2009-05-20!). What am I doing wrong? -- Sincerely, Dmitry nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
