Re: ZFS MFC heads down
Please, fix 4 times repetition of all its content in stable/7/cddl/compat/opensolaris/include/libshare.h. The same: stable/7/sys/cddl/compat/opensolaris/sys/pathname.h stable/7/sys/cddl/compat/opensolaris/sys/kidmap.h stable/7/sys/cddl/compat/opensolaris/sys/file.h fixed by r192523 ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Wed, May 20, 2009 at 10:21:23AM -0400, John Baldwin wrote: Try this. It reverts the single-CCB part of the previous commit while keeping the other fixes. I missed that the CCB might still be in flight when we schedule another rescan. Applied to mpt_raid.c,v 1.15.2.1 2008/07/28 17:05:09 jhb (it differ only for line position but adiacent lines are the same). Also redone a diff -u4 to verify, recompiled, installed, and... YOO-HOO. Now it rebuild _without_ crashing. May 20 17:39:08 horse kernel: \ mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 64461754 of 71087625 blocks remaining Let me test against a 7.2-STABLE (and even to some -CURRENT)... [some times ahead] Bad news: I removed the second disk during rebuilding and it still crash. I take a screen shapshot with camera because of too many messages for write down by hand :) Image, src tarball and info here (about 2.2MB): ftp://ftp.torrini.org/pub/FreeBSD/mpt_crash_on_rebuild/ -- Riccardo. ___ 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: ZFS MFC heads up
I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. I think this is not a zfs issue, but it does trigger the problem: on a zfs mounted system via nfs, from linux, an ls .zfs used to panic the server, now it just doesn't work :-). (http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html) so is this being worked on? btw, i will be trying the new version over the weekend. danny ___ 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
kernel compile fails in machdep.c
Latest stable sources, machdep.c is $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.29.2.7 2009/05/19 22:07:54 jhb Exp $ cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/i386/i386/intr_machdep.c cc1: warnings being treated as errors /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_register_source': /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 4 of 'intr_event_create' makes pointer from integer without a cast /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 7 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 8 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_execute_handlers': /usr/src/sys/i386/i386/intr_machdep.c:261: warning: implicit declaration of function 'intr_event_handle' /usr/src/sys/i386/i386/intr_machdep.c:261: warning: nested extern declaration of 'intr_event_handle' *** Error code 1 -- per ___ 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: ZFS MFC heads up
On 20.05.2009, at 22:41, Kip Macy wrote: On Wed, May 20, 2009 at 3:11 PM, Mike Tancsa m...@sentex.net wrote: At 05:59 PM 5/20/2009, Kip Macy wrote: If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. Primarily what was in Pawel's commit to HEAD (see below). The following changes have also been brought in: - the recurring deadlock was fixed by deferring vinactive to a dedicated thread - zfs boot for all types now works - kmem now goes up to 512GB so arc is now limited by physmem - the arc now experiences backpressure from the vm (which can be too much - but allows ZFS to work without any tunables on amd64) great awesome incredible gorgeous superb fantastic excellent supercool THANX! :-) * dancing around with loud music csupping all over the place... * Lorenzo ___ 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: ZFS MFC heads up
Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. Mounting local file systems:. internal error: out of memory internal error: out of memory internal error: out of memory internal error: out of memory I get this in dmesg after make installkernel shutdown -r now, zfs pool is not mounted. /usr is on zfs so can't installworld. 2GB memory and 4x 1TB raid-z on amd64, / is 2x 2GB gmirror. ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
2009/5/21 Riccardo Torrini riccardo.torr...@esaote.com: On Wed, May 20, 2009 at 10:21:23AM -0400, John Baldwin wrote: Try this. It reverts the single-CCB part of the previous commit while keeping the other fixes. I missed that the CCB might still be in flight when we schedule another rescan. Applied to mpt_raid.c,v 1.15.2.1 2008/07/28 17:05:09 jhb (it differ only for line position but adiacent lines are the same). Also redone a diff -u4 to verify, recompiled, installed, and... YOO-HOO. Now it rebuild _without_ crashing. May 20 17:39:08 horse kernel: \ mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 64461754 of 71087625 blocks remaining Let me test against a 7.2-STABLE (and even to some -CURRENT)... [some times ahead] Bad news: I removed the second disk during rebuilding and it still crash. I take a screen shapshot with camera because of too many messages for write down by hand :) Image, src tarball and info here (about 2.2MB): ftp://ftp.torrini.org/pub/FreeBSD/mpt_crash_on_rebuild/ Please try the patch here: http://www.freebsd.org/~attilio/notify.diff I think it is perfectly fine this approach because the devctl_notify() also will silently fail if no memory is available. Note that this is a CAM bug more that the driver arises. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: ZFS MFC heads down
2009/5/21 Kip Macy km...@freebsd.org: The MFC went in r192498. Please let me know if you have any problems. - zfs boot for all types now works Is it possible to boot from ZFS without ufs boot partition? zfsboot was added but is not build, gptzfsboot is not in tree. -- Artis Caune Everything should be made as simple as possible, but not simpler. ___ 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: ZFS MFC heads up
I get this in dmesg after make installkernel shutdown -r now, zfs pool is not mounted. /usr is on zfs so can't installworld. I can't help, but thanks for the bug report as it prompted me to upgarde both kernel and world at the same time. Which works fine after reboot. If I were you I would reboot the old kerenl and just installworld/meregmaster so you ahhve the whole system in sync. -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: ZFS MFC heads up
Pertti Kosunen pertti.kosu...@pp.nic.fi wrote: Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. Mounting local file systems:. internal error: out of memory internal error: out of memory internal error: out of memory internal error: out of memory I get this in dmesg after make installkernel shutdown -r now, zfs pool is not mounted. /usr is on zfs so can't installworld. IIRC, that's what happens if ZFS kernel and userland aren't in sync. You'll either have to install the new kernel and userland together (not supported, but I do it all the time), or install the userland from a non-ZFS file system. Fabian signature.asc Description: PGP signature
Re: ZFS MFC heads up
Ran into the same thing on -CURRENT when we went version 13. Some manual intervention fixed it. http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000508.html /glz --On Thursday, May 21, 2009 12:42 PM +0300 Pertti Kosunen pertti.kosu...@pp.nic.fi wrote: Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. Mounting local file systems:. internal error: out of memory internal error: out of memory internal error: out of memory internal error: out of memory I get this in dmesg after make installkernel shutdown -r now, zfs pool is not mounted. /usr is on zfs so can't installworld. 2GB memory and 4x 1TB raid-z on amd64, / is 2x 2GB gmirror. ___ 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 ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile, Aurorum 2, S-977 75 Luleå, Sweden Phone: +46(0)920-75559 Mobile: +46(0)70-587 87 82 Fax: +46(0)70-615 87 82 http://www.ismobile.com ... ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Thu, May 21, 2009 at 11:47:54AM +0200, Attilio Rao wrote: Bad news: I removed the second disk during rebuilding and it still crash. I take a screen shapshot with camera because of too many messages for write down by hand :) Image, src tarball and info here (about 2.2MB): ftp://ftp.torrini.org/pub/FreeBSD/mpt_crash_on_rebuild/ Please try the patch here: http://www.freebsd.org/~attilio/notify.diff I think it is perfectly fine this approach because the devctl_notify() also will silently fail if no memory is available. Note that this is a CAM bug more that the driver arises. Perfect. With jhb@ _and_ attilio@ patches MPT rebuilt array w/out problem (tryed adding and removing second disk 3 times during build, no more crashes :-) Going to cvsup to last 7.2-STABLE, be patient (rebuilding). At a later time I'll report results even on last -CURRENT. Thanks for your time. PS: I successfully configured and used serial console for debug now, next time no more photos ;) -- Riccardo. ___ 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: ZFS MFC heads down
Navdeep Parhar wrote: On Wed, May 20, 2009 at 5:00 PM, Kip Macy km...@freebsd.org wrote: Not really a problem but a question: Is the v13 on-disk format exactly the same as that used by Solaris/Opensolaris? It is supposed to be. The sources are the same. However, I have not tested interoperability. Does this make it possible to have a ZFS-only dual boot system running FreeBSD-stable and Solaris, with a shared home directory between the two environments? It should be. Has anyone tried anything like this? Google anyone? :-) My google-fu is weak today, and considering that this went into -stable a few minutes back, I didn't look that hard for v13/fbsd-stable/opensolaris adventures. :-) I do it with 7.1 and opensolaris 2008.05 without problem. I keep the pool in V6 of course. Henri I'm feeling brave. I think I'll try it myself. Thanks for getting this into -stable! Navdeep -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 ___ 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: ZFS MFC heads down
Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I upgrade to stable r192523: FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 21 13:18:53 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 some strange things: just after boot: [r...@morzine ~]# zfs upgrade This system is currently running ZFS filesystem version 3. The following filesystems are out of date, and can be upgraded. After being upgraded, these filesystems (and any 'zfs send' streams generated from subsequent snapshots) will no longer be accessible by older software versions. VER FILESYSTEM --- 1 pool1 1 pool1/qemu 1 pool1/squid 1 pool2 1 pool2/WorkBench 1 pool2/backup 1 pool2/download 1 pool2/qemu 1 pool2/sys 1 rpool 1 rpool/home 1 rpool/root 1 rpool/tmp 1 rpool/usr 1 rpool/var 1 rpool/var/spool [r...@morzine ~]# zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where 'N' is the version number. And now, after a few minutes: [r...@morzine ~]# zpool upgrade This system is currently running ZFS pool version 13. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- 6 pool1 6 pool2 6 rpool Use 'zpool upgrade -v' for a list of available versions and their associated features. [r...@morzine ~]# zpool upgrade -v This system is currently running ZFS pool version 13. The following versions are supported: VER DESCRIPTION --- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/N Where 'N' is the version number. Strange isn't it o-) By the way all seems ok! Thanks to all for this update to zfs V13 Henri Thanks, 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 ___ 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: ZFS MFC heads down
Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I upgrade to stable r192523: FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 21 13:18:53 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 some strange things: just after boot: [r...@morzine ~]# zfs upgrade This system is currently running ZFS filesystem version 3. The following filesystems are out of date, and can be upgraded. After being upgraded, these filesystems (and any 'zfs send' streams generated from subsequent snapshots) will no longer be accessible by older software versions. VER FILESYSTEM --- 1 pool1 1 pool1/qemu 1 pool1/squid 1 pool2 1 pool2/WorkBench 1 pool2/backup 1 pool2/download 1 pool2/qemu 1 pool2/sys 1 rpool 1 rpool/home 1 rpool/root 1 rpool/tmp 1 rpool/usr 1 rpool/var 1 rpool/var/spool [r...@morzine ~]# zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where 'N' is the version number. And now, after a few minutes: [r...@morzine ~]# zpool upgrade This system is currently running ZFS pool version 13. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- 6 pool1 6 pool2 6 rpool Use 'zpool upgrade -v' for a list of available versions and their associated features. [r...@morzine ~]# zpool upgrade -v This system is currently running ZFS pool version 13. The following versions are supported: VER DESCRIPTION --- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/N Where 'N' is the version number. Strange isn't it o-) By the way all seems ok! This happen after the first boot in stable (comming from 7.2-RELEASE). I reboot and can't reproduce it!. Henri Thanks to all for this update to zfs V13 Henri Thanks, 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 ___ 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 ___ 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: ZFS MFC heads up
Goran Lowkrantz wrote: Ran into the same thing on -CURRENT when we went version 13. Some manual intervention fixed it. http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000508.html mount -t zfs ... cd /usr/src make NO_FSCHG= installworld This did the job with new kernel. Recommend easier way without reboot.. ___ 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: kernel compile fails in machdep.c
On Thursday 21 May 2009 4:15:54 am Per olof Ljungmark wrote: Latest stable sources, machdep.c is $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.29.2.7 2009/05/19 22:07:54 jhb Exp $ cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/i386/i386/intr_machdep.c cc1: warnings being treated as errors /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_register_source': /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 4 of 'intr_event_create' makes pointer from integer without a cast /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 7 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 8 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_execute_handlers': /usr/src/sys/i386/i386/intr_machdep.c:261: warning: implicit declaration of function 'intr_event_handle' /usr/src/sys/i386/i386/intr_machdep.c:261: warning: nested extern declaration of 'intr_event_handle' *** Error code 1 I think you must have some files not in sync. It compiled before commit and the tinderbox has not reported any errors after the commit. -- John Baldwin ___ 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: kernel compile fails in machdep.c
John Baldwin wrote: On Thursday 21 May 2009 4:15:54 am Per olof Ljungmark wrote: Latest stable sources, machdep.c is $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.29.2.7 2009/05/19 22:07:54 jhb Exp $ cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/i386/i386/intr_machdep.c cc1: warnings being treated as errors /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_register_source': /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 4 of 'intr_event_create' makes pointer from integer without a cast /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 7 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c:136: warning: passing argument 8 of 'intr_event_create' from incompatible pointer type /usr/src/sys/i386/i386/intr_machdep.c: In function 'intr_execute_handlers': /usr/src/sys/i386/i386/intr_machdep.c:261: warning: implicit declaration of function 'intr_event_handle' /usr/src/sys/i386/i386/intr_machdep.c:261: warning: nested extern declaration of 'intr_event_handle' *** Error code 1 I think you must have some files not in sync. It compiled before commit and the tinderbox has not reported any errors after the commit. Yes, I just saw this. The original sources were fetched from cvsup.de.freebsd.org (twice, same result), then I switched to cvsup.freebsd.org and got the right version. I would like to notify the admins of .de but unsure of how to. Thanks, -- per ___ 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: failed to set mtrr: invalid argument
on 20/05/2009 18:56 Robert Noland said the following: On Wed, 2009-05-20 at 17:26 +0200, Paul B. Mahol wrote: On 5/20/09, Robert Noland rnol...@freebsd.org wrote: Yes, if xserver is built with HAL support, I see it linked with libthr. If HAL is disabled, it doesn't appear to be. I'm trying to remember exactly what the reported issue was, but I think it was X crashing on exit. Looking at xorg-server source I did not see anything that points it must link to libthr, perhaps HAL support makes libthr linking mandatory. The issue crops up with libdrm-intel. libdrm is linked with pthread. I know I talked about this with kib@ a while back and we determined that the existing behavior was correct, but I think at that time we were looking at xserver linked with libthr. Yes, it was me who was having crash-on-exit problem with intel+drm. The crash happened in pthread_mutex_destroy. The crash went away when I re-linked X with libthr added. HAL pulls in libthr dependency via libhal.la, otherwise it should be specified explicitely. -- Andriy Gapon ___ 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: ZFS MFC heads up
FYI, I just did an upgrade of my RELENG_7 machine with the new ZFS merged in, and it seems to have gone mostly trouble-free. I noticed one weirdness that could be confusion on my part - I'm no longer seeing snapshots when I do 'zfs list'. There's a UI change in the zfs command, and to see snapshots, you have to explicitly ask for them: zfs list -t snapshot scared me there for a moment.. Thanks for all the great work on ZFS in FreeBSD to everyone involved. I look forward to really beating on this now in RELENG_7. Any pointers to running multiple jails with ZFS? I was looking for something like a union-mount capability for ZFS. I don't necessarily need a jail to run divergent /bin, /usr/local, etc. just the isolation. Making a clone doesn't exactly do the same thing.. louie ___ 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: ZFS MFC heads up
on 21/05/2009 17:12 Louis Mamakos said the following: FYI, I just did an upgrade of my RELENG_7 machine with the new ZFS merged in, and it seems to have gone mostly trouble-free. I noticed one weirdness that could be confusion on my part - I'm no longer seeing snapshots when I do 'zfs list'. There's a UI change in the zfs command, and to see snapshots, you have to explicitly ask for them: zfs list -t snapshot scared me there for a moment.. Do 'zpool get all poolname', it might give you a hint as to why :-) -- Andriy Gapon ___ 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: ZFS MFC heads up
On Thu, May 21, 2009 at 7:12 AM, Louis Mamakos lo...@transsys.com wrote: FYI, I just did an upgrade of my RELENG_7 machine with the new ZFS merged in, and it seems to have gone mostly trouble-free. I noticed one weirdness that could be confusion on my part - I'm no longer seeing snapshots when I do 'zfs list'. There's a UI change in the zfs command, and to see snapshots, you have to explicitly ask for them: It's a known change made to the zfs tool somewhere around v11 or so. It's documented in all the Solaris notes about ZFS. You have to explicitily list the type of dataset(s) you want to list with zfs list. By default, it only shows filesystems. You even have to use -t if you want to list volumes. Reading up on the Solaris docs for ZFS is quite enlightening. :) -- Freddie Cash fjwc...@gmail.com ___ 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: ZFS MFC heads up
On May 21, 2009, at 11:22 AM, Freddie Cash wrote: On Thu, May 21, 2009 at 7:12 AM, Louis Mamakos lo...@transsys.com wrote: FYI, I just did an upgrade of my RELENG_7 machine with the new ZFS merged in, and it seems to have gone mostly trouble-free. I noticed one weirdness that could be confusion on my part - I'm no longer seeing snapshots when I do 'zfs list'. There's a UI change in the zfs command, and to see snapshots, you have to explicitly ask for them: It's a known change made to the zfs tool somewhere around v11 or so. It's documented in all the Solaris notes about ZFS. You have to explicitily list the type of dataset(s) you want to list with zfs list. By default, it only shows filesystems. You even have to use -t if you want to list volumes. Reading up on the Solaris docs for ZFS is quite enlightening. :) We might want to update the zfs(1) man page in the examples for the 'list' subcommand. I think I actually like the new behavior, it was just a little unnerving at first to have the snapshots be missing after the MFC. louie ___ 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
32 Luns with 7.2
Hi everybody, with 32 LUNs in 7.2 (mpt_cam.h, line 3608 cpi-max_lun = 32) booting takes about 15 minues (7.0 the above change was about 3 minutes) after 16 times the messages below run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mpt0: request 0xfffe8029f960:359 timed out for ccb 0xff0004a9 (req- ccb 0xff0004a9) mpt0: attempting to abort req 0xfffe8029f960:359 function 0 mpt0: completing timedout/aborted req 0xfffe8029f960:359 mpt0: mpt_recover_commands: IOC Status 0x4a. Resetting controller. mpt0: mpt_cam_event: 0xfe mpt0: mpt_cam_event: 0xfe mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 any improvement on the 32 LUNs issue ? thanks, Dieter ___ 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
Schau dir meine Fotos in Facebook an - von dir ist bestimmt auch eins dabei
Hallo Freebsd-stable, Ich habe dich vor einiger Zeit eingeladen Facebook beizutreten. Sobald du dich registrierst, können wir online in Verbindung treten, Fotos miteinander teilen, Gruppen und Veranstaltungen organisieren und noch viel mehr. Grüße, Wolfgang Um dich für Facebook zu registrieren, folge dem untenstehenden Link: http://www.facebook.com/p.php?i=1185452979k=ZVF24XU2U6VAUGEEQD32SVr freebsd-stable@freebsd.org wurde von Wolfgang Ihloff zu Facebook eingeladen. Wenn du diese Art von E-Mails von Facebook in Zukunft nicht mehr erhalten möchtest, klicke bitte auf den Link unten, um sie abzubestellen. http://www.facebook.com/o.php?k=0d6aafu=515063722mid=7f7decG1eb33faaG0G8 Die Facebook-Büros befinden sich hier: 1601 S. California Ave., Palo Alto, CA 94304. ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Thu, May 21, 2009 at 11:47:54AM +0200, Attilio Rao wrote: Please try the patch here: http://www.freebsd.org/~attilio/notify.diff As promised I checked againts 7.2-STABLE of today (cvsup ended at 15:17 CEST, GTM+2, Italy time with DST) and ... it works ! (added and removed a disk 4 times, even during a sync-in-progress) # uname -v FreeBSD 7.2-STABLE #3: Thu May 21 18:26:04 CEST 2009 ... -[ 1st remove ]- mpt0: External Bus Reset Detected (mpt0:vol0:1): Physical Disk Status Changed (mpt0:vol0:0): Volume Status Changed (mpt0:vol0:1): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): No longer configured -[ 1st add ]- mpt0: External Bus Reset Detected mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Domain Validation Required mpt0:vol0(mpt0:0:0): Volume Status Changed mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 71087625 of 71087625 blocks remaining (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:1): Online (mpt0:vol0:1): Status ( Out-Of-Sync ) (mpt0:vol0:1): SMART Data Received (mpt0:vol0:1): ASC 0x5d, ASCQ 0x0) mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 71076421 of 71087625 blocks remaining mpt0:vol0(mpt0:0:0): Volume Status Changed -[ 2nd remove ]- mpt0: External Bus Reset Detected mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical Disk Status Changed (mpt0:vol0:1): Physical Disk Status Changed (mpt0:vol0:1): No longer configured mpt0:vol0(mpt0:0:0): Physical Disk Status Changed -[ 2nd add ]- mpt0: External Bus Reset Detected mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Domain Validation Required mpt0:vol0(mpt0:0:0): Volume Status Changed mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 71087625 of 71087625 blocks remaining (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:1): Online (mpt0:vol0:1): Status ( Out-Of-Sync ) (mpt0:vol0:1): SMART Data Received (mpt0:vol0:1): ASC 0x5d, ASCQ 0x0) mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): Low Priority Re-Sync mpt0:vol0(mpt0:0:0): 70896522 of 71087625 blocks remaining Thanks again. -- Riccardo. ___ 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
if_ath.c error during buildkernel in latest 7.2-STABLE
Hi, I just cvsupped the lastest 7.2-STABLE and after cd /usr/src make clean make -j8 buildworld make buildkernel KERNCONF=ZFSSERVER I encounter cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 Is there anything I missed? Oh yes, ath was in KERNCONF because that was copied from GENERIC. Actually I don't need ath and after removing that device from config file everything compiled without problems. But what about those that do need ath? Regards, Holger ___ 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
ZFS hanging at kernel boot now, but didn't before... (Re: ZFS MFC heads up)
Hmm, I've had a bit of a miserable afternoon trying to fight my RELENG_7 server, which now doesn't boot. :(. So, it's a ZRAID2 pool with a ufs/gmirror root partition split over 5 disks (gmirror on 500Mb partition on each of five disks, and zraid2 over the rest of each drive). What I did was to update the userland, and then reboot. I didn't upgrade the kernel (but I've subsequently done that and have the same problem). What happens is that the kernel hangs booting just after displaying a LABEL message or ZFS pool/spool message. I _can_ get it to boot if I boot single user with acpi switched off. When I do that I can manually start zfs, and mount all the partitions. However, one of the disks is missing more on that next. The machine is running a gigabyte motherboard (domestic gamer P35 board, similar to this http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2533, although it might be a DS4 variant). I've got 5 of the 6 sata ports wired to a 5 unit SATA hot swap bay (5 drives vertially mounted into 3 5-1/4 bays kind of thing). Now, because of the gmirror I can boot the system on any disk, or combination of plugged in disks. I should be able to succeed with the kernel probe up to the attempt to mount the root filesystem irrespective of any zfs pool, etc. And, indeed, this has been working fine for about two years. But, now it hangs in the same place no matter what disk I boot on (I've tried every bay). But, without ACPI enabled it does appear to boot ok... what's going on here? Is it possible that the machine has developed a hardware fault? Ok, finally, if I boot with ACPI disabled then one of the disks is missing. If I unplug it I get a disconnect message from the ata device, and a reconnect and reinit attempt when I plug it back in, but no device appears on the bus. Usually I can do a 'atacontrol detach sata4; sleep 1; atacontrol attach sata4' and the device reappears. This happens on the other buses, but not on the last one. It's not the disk, because if I swap it into another bay, it comes up and appears on the bus. On the other hand it doesn't appear to be that controller or slow in the drive bay because if I unplug all the over disks the system will boot that disk and get as far as the hang hmm. Is this a consequence of disabling the ACPI? Does anyone have a clue what might be going on? Joe ___ 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
[releng_7 tinderbox] failure on amd64/amd64
TB --- 2009-05-21 17:47:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-21 17:47:04 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-05-21 17:47:04 - cleaning the object tree TB --- 2009-05-21 17:47:39 - cvsupping the source tree TB --- 2009-05-21 17:47:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-05-21 17:47:59 - building world TB --- 2009-05-21 17:47:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 17:47:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 17:47:59 - TARGET=amd64 TB --- 2009-05-21 17:47:59 - TARGET_ARCH=amd64 TB --- 2009-05-21 17:47:59 - TZ=UTC TB --- 2009-05-21 17:47:59 - __MAKE_CONF=/dev/null TB --- 2009-05-21 17:47:59 - cd /src TB --- 2009-05-21 17:47:59 - /usr/bin/make -B buildworld World build started on Thu May 21 17:48:00 UTC 2009 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu May 21 19:21:32 UTC 2009 TB --- 2009-05-21 19:21:32 - generating LINT kernel config TB --- 2009-05-21 19:21:32 - cd /src/sys/amd64/conf TB --- 2009-05-21 19:21:32 - /usr/bin/make -B LINT TB --- 2009-05-21 19:21:32 - building LINT kernel TB --- 2009-05-21 19:21:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 19:21:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 19:21:32 - TARGET=amd64 TB --- 2009-05-21 19:21:32 - TARGET_ARCH=amd64 TB --- 2009-05-21 19:21:32 - TZ=UTC TB --- 2009-05-21 19:21:32 - __MAKE_CONF=/dev/null TB --- 2009-05-21 19:21:32 - cd /src TB --- 2009-05-21 19:21:32 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu May 21 19:21:32 UTC 2009 stage 1: configuring the kernel [...] WARNING: kernel contains GPL contaminated emu10k1 headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated maestro3 headers WARNING: kernel contains GPL contaminated ext2fs filesystem WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-21 19:21:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-21 19:21:32 - ERROR: failed to build lint kernel TB --- 2009-05-21 19:21:32 - 4544.73 user 512.59 system 5668.26 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full ___ 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: ZFS MFC heads down
On Wednesday 20 May 2009 06:43:13 pm Kip Macy wrote: The MFC went in r192498. Please let me know if you have any problems. So far so good here (amd64, Core2 Duo, ICH9 SATA) but I'm too chicken to upgrade the on-disk format yet. -- Kirk Strauser ___ 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: ZFS MFC heads down
All looking good here - 3rd DNS server is now running new ZFS with an upgraded pool, and I jsut did a server in the office which is running a database and filesderver, also upgrading the pool. These are all amd64 systems, and the vm backpressure system seems to work nicely - in that the kernel memory usage has settled at the same kind of levels I was locking it to previously (which is nice to see!). -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: ZFS MFC heads up
On Thursday 21 May 2009 09:12:14 am Louis Mamakos wrote: Any pointers to running multiple jails with ZFS? I was looking for something like a union-mount capability for ZFS. I don't necessarily need a jail to run divergent /bin, /usr/local, etc. just the isolation. Making a clone doesn't exactly do the same thing.. FWIW, I love sysutils/ezjail. It uses nullfs to mount many jails on top of the same read-only base system, and provides a way (ezjail-admin update -i) to upgrade that base system with installworld. -- Kirk Strauser ___ 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: ZFS MFC heads up
On Wed, 20 May 2009, Kip Macy wrote: KM I will be MFC'ing the newer ZFS support some time this afternoon. Both KM world and kernel will need to be re-built. Existing pools will KM continue to work without upgrade. KM KM KM If you choose to upgrade a pool to take advantage of new features you KM will no longer be able to use it with sources prior to today. 'zfs KM send/recv' is not expected to inter-operate between different pool KM versions. I updated my poor old moose to the fresh RELENG_7, and panic is still in place: r...@moose:/ar/.bad# ls -la 200807/ total 9089 drwxr-xr-x 3 rscript wheel4 Nov 5 2008 ./ drwxr-xr-x 3 root wheel3 Apr 12 21:33 ../ drwxr-xr-x 2 rscript wheel 36 Apr 2 22:12 daily/ -rw-r--r-- 1 rscript wheel 9207828 Aug 1 2008 total.200807 r...@moose:/ar/.bad# ls -la 200807/daily/ panic: avl_find() succeeded inside avl_add() cpuid = 1 Uptime: 1m27s Physical memory: 2039 MB Dumping 247 MB: 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete on the dump: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05352e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05355f5 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0843b60 in avl_add (tree=Variable tree is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 #4 0xc08b0edf in zap_lockdir (os=0xc55dfa60, obj=6108, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=0xfc755ba0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:335 #5 0xc08b13af in zap_cursor_retrieve (zc=0xfc755b9c, za=0xfc755a84) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:993 #6 0xc08d6340 in zfs_freebsd_readdir (ap=0xfc755c00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2156 #7 0xc06de842 in VOP_READDIR_APV (vop=0xc093c560, a=0xfc755c00) at vnode_if.c:1407 #8 0xc05bf88a in kern_getdirentries (td=0xc55c0900, fd=5, buf=0x48215000 Address 0x48215000 out of bounds, count=4096, basep=0xfc755c74) at vnode_if.h:747 #9 0xc05bfab1 in getdirentries (td=0xc55c0900, uap=0xfc755cfc) at /usr/src/sys/kern/vfs_syscalls.c:3785 #10 0xc06d3588 in syscall (frame=0xfc755d38) at /usr/src/sys/i386/i386/trap.c:1090 #11 0xc06b8f40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #12 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Any other info we need to examine this further? Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: ZFS MFC heads up
Looks like a (corrupted) space management bug. I'll take a closer look this weekend to see if it can be recovered from. -Kip On Thu, May 21, 2009 at 12:50 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Wed, 20 May 2009, Kip Macy wrote: KM I will be MFC'ing the newer ZFS support some time this afternoon. Both KM world and kernel will need to be re-built. Existing pools will KM continue to work without upgrade. KM KM KM If you choose to upgrade a pool to take advantage of new features you KM will no longer be able to use it with sources prior to today. 'zfs KM send/recv' is not expected to inter-operate between different pool KM versions. I updated my poor old moose to the fresh RELENG_7, and panic is still in place: r...@moose:/ar/.bad# ls -la 200807/ total 9089 drwxr-xr-x 3 rscript wheel 4 Nov 5 2008 ./ drwxr-xr-x 3 root wheel 3 Apr 12 21:33 ../ drwxr-xr-x 2 rscript wheel 36 Apr 2 22:12 daily/ -rw-r--r-- 1 rscript wheel 9207828 Aug 1 2008 total.200807 r...@moose:/ar/.bad# ls -la 200807/daily/ panic: avl_find() succeeded inside avl_add() cpuid = 1 Uptime: 1m27s Physical memory: 2039 MB Dumping 247 MB: 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete on the dump: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05352e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05355f5 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0843b60 in avl_add (tree=Variable tree is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 #4 0xc08b0edf in zap_lockdir (os=0xc55dfa60, obj=6108, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=0xfc755ba0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:335 #5 0xc08b13af in zap_cursor_retrieve (zc=0xfc755b9c, za=0xfc755a84) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:993 #6 0xc08d6340 in zfs_freebsd_readdir (ap=0xfc755c00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2156 #7 0xc06de842 in VOP_READDIR_APV (vop=0xc093c560, a=0xfc755c00) at vnode_if.c:1407 #8 0xc05bf88a in kern_getdirentries (td=0xc55c0900, fd=5, buf=0x48215000 Address 0x48215000 out of bounds, count=4096, basep=0xfc755c74) at vnode_if.h:747 #9 0xc05bfab1 in getdirentries (td=0xc55c0900, uap=0xfc755cfc) at /usr/src/sys/kern/vfs_syscalls.c:3785 #10 0xc06d3588 in syscall (frame=0xfc755d38) at /usr/src/sys/i386/i386/trap.c:1090 #11 0xc06b8f40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #12 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Any other info we need to examine this further? Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** -- 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 http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
At 03:35 PM 5/21/2009, Kirk Strauser wrote: On Wednesday 20 May 2009 06:43:13 pm Kip Macy wrote: The MFC went in r192498. Please let me know if you have any problems. So far so good here (amd64, Core2 Duo, ICH9 SATA) but I'm too chicken to upgrade the on-disk format yet. I did an update on one of my less critical boxes today. I upgraded the version as well to lucky 13 :) So far so good! I am rsyncing a few hundred GB to it now. One thing I noticed, and not sure if this is normal because of the compression, the capacity shows 31%, df shows 13% 0[offsite]# zpool status pool: tank1 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad12ONLINE 0 0 0 ad14ONLINE 0 0 0 errors: No known data errors 0[offsite]# zpool get all tank1 NAME PROPERTY VALUE SOURCE tank1 size 5.44T - tank1 used 1.69T - tank1 available 3.75T - tank1 capacity 31% - tank1 altroot- default tank1 health ONLINE - tank1 guid 7336939736750289319 - tank1 version13 default tank1 bootfs - default tank1 delegation on default tank1 autoreplaceoff default tank1 cachefile - default tank1 failmode waitdefault tank1 listsnapshots off default 0[offsite]# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad6s1a 2026030406192145775622%/ devfs 1 1 0 100%/dev /dev/ad6s1d 2026030 1121863836 0%/tmp /dev/ad6s1e 40622796 4937888 3243508613%/usr /dev/ad6s1f 20844174 1258572 17918070 7%/var tank1 3399088000 457597952 294149004813%/tank1 ta...@20090510 3391231232 449741184 294149004813%/tank1/.zfs/snapshot/20090510 ta...@20090517 3391393408 449903360 294149004813%/tank1/.zfs/snapshot/20090517 0[offsite]# 0[offsite]# zfs get all NAMEPROPERTY VALUE SOURCE tank1 type filesystem - tank1 creation Fri May 8 13:44 2009 - tank1 used 1.27T - tank1 available 2.74T - tank1 referenced437G - tank1 compressratio 1.63x - tank1 mounted yes- tank1 quota none default tank1 reservation none default tank1 recordsize128K default tank1 mountpoint/tank1 default tank1 sharenfs offdefault tank1 checksum on default tank1 compression on local tank1 atime offlocal tank1 devices on default tank1 exec on default tank1 setuidon default tank1 readonly offdefault tank1 jailedoffdefault tank1 snapdir visiblelocal tank1 aclmode groupmask default tank1 aclinheritrestricted default tank1 canmount on default tank1 shareiscsioffdefault tank1 xattr offtemporary tank1 copies1 default tank1 version 1 - tank1 utf8only off- tank1 normalization none - tank1 casesensitivity sensitive - tank1 vscan offdefault tank1 nbmandoffdefault tank1 sharesmb offdefault tank1 refquota none default tank1 refreservationnone default tank1 primarycache alldefault tank1 secondarycachealldefault ta...@20090510 type snapshot -
Re: ZFS MFC heads down
I did an update on one of my less critical boxes today. I upgraded the version as well to lucky 13 :) So far so good! I am rsyncing a few hundred GB to it now. One thing I noticed, and not sure if this is normal because of the compression, the capacity shows 31%, df shows 13% Your snapshots are using two thirds of your used capacity. 'df' only knows about the mounted file system. Cheers, Kip 0[offsite]# zpool status pool: tank1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 errors: No known data errors 0[offsite]# zpool get all tank1 NAME PROPERTY VALUE SOURCE tank1 size 5.44T - tank1 used 1.69T - tank1 available 3.75T - tank1 capacity 31% - tank1 altroot - default tank1 health ONLINE - tank1 guid 7336939736750289319 - tank1 version 13 default tank1 bootfs - default tank1 delegation on default tank1 autoreplace off default tank1 cachefile - default tank1 failmode wait default tank1 listsnapshots off default 0[offsite]# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad6s1a 2026030 406192 1457756 22% / devfs 1 1 0 100% /dev /dev/ad6s1d 2026030 112 1863836 0% /tmp /dev/ad6s1e 40622796 4937888 32435086 13% /usr /dev/ad6s1f 20844174 1258572 17918070 7% /var tank1 3399088000 457597952 2941490048 13% /tank1 ta...@20090510 3391231232 449741184 2941490048 13% /tank1/.zfs/snapshot/20090510 ta...@20090517 3391393408 449903360 2941490048 13% /tank1/.zfs/snapshot/20090517 0[offsite]# 0[offsite]# zfs get all NAME PROPERTY VALUE SOURCE tank1 type filesystem - tank1 creation Fri May 8 13:44 2009 - tank1 used 1.27T - tank1 available 2.74T - tank1 referenced 437G - tank1 compressratio 1.63x - tank1 mounted yes - tank1 quota none default tank1 reservation none default tank1 recordsize 128K default tank1 mountpoint /tank1 default tank1 sharenfs off default tank1 checksum on default tank1 compression on local tank1 atime off local tank1 devices on default tank1 exec on default tank1 setuid on default tank1 readonly off default tank1 jailed off default tank1 snapdir visible local tank1 aclmode groupmask default tank1 aclinherit restricted default tank1 canmount on default tank1 shareiscsi off default tank1 xattr off temporary tank1 copies 1 default tank1 version 1 - tank1 utf8only off - tank1 normalization none - tank1 casesensitivity sensitive - tank1 vscan off default tank1 nbmand off default tank1 sharesmb off default tank1 refquota none default tank1 refreservation none default tank1 primarycache all default tank1 secondarycache all default ta...@20090510 type snapshot - ta...@20090510 creation Sun May 10 12:37 2009 - ta...@20090510 used
powerd (-adp/-hadp) strangeness on 7.2/amd64
Every time I create/mount or unmount/detach a MFS filesystem, powerd would *immediately* react with something like the following: ### mdmfs -s 200m md /mfs load 200%, current freq 600 MHz ( 9), wanted freq 1092 MHz changing clock speed from 600 MHz to 1200 MHz load 4%, current freq 1200 MHz ( 5), wanted freq 955 MHz changing clock speed from 1200 MHz to 1000 MHz ### umount /mfs mdconfig -d -u 0 load 200%, current freq 1000 MHz ( 6), wanted freq 1910 MHz changing clock speed from 1000 MHz to 1982 MHz or even load 4%, current freq 1600 MHz ( 3), wanted freq 1519 MHz ### mdmfs here load 100%, current freq 1600 MHz ( 3), wanted freq 4532 MHz Is that expected behaviour? :-) ___ 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: ZFS MFC heads down
On 5/21/09 4:15 PM, Kip Macy wrote: Your snapshots are using two thirds of your used capacity. 'df' only knows about the mounted file system. Cheers, Kip On that subject, if anyone isn't aware this version of zfs has nicer space accounting. you should check out the output of zfs list -o space SUPER AWESOME HUH!? unfortunately the fancy new space accounting only works on datasets created on a pool supporting it, so all of us who upgraded our pools will not see any output. for example NAMEAVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD rpool/ROOT/snv_107 8.86G 3.80G - - - - however you can just create a new dataset with zfs create to take advantage of the new space accounting. then you'll get real output like NAMEAVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD phoenix/rsync/cifs 70.2G 272G 212G 59.3G 0 0 I can easily see here that I have 212G of snapshots for this dataset. I just thought I would throw that out there for anyone who didn't know about it yet. ___ 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: ZFS MFC heads up
On Thursday 21 May 2009 04:32:56 am Lorenzo Perone wrote: * dancing around with loud music csupping all over the place... * I'll know I've been hacking too long when my music starts csupping all over the place.. :) Ditto though, huge thanks to Kip! JN ___ 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
