system locks up in vmmaps
System 6.2-R locks in vmmaps state on relatively small workload. This happens the first time. I don't know if I could reproduce this lockup. The picture at whole looks like on http://lists.freebsd.org/pipermail/freebsd-current/2005-September/055982.html (though that problem was fixed before 6). I'd be great to get any ideas on that. db ps pid ppid pgrp uid state wmesg wchancmd 10877 1025 10877 0 Ss vmmaps 0xc1068478 sshd 10876 10875 10876 0 SVs vmmaps 0xc1068478 cron 10875 1091 1091 0 S ppwait 0xcfc82a78 cron 10874 10872 10874 0 SVs vmmaps 0xc1068478 cron 10873 10871 10873 0 SVs vmmaps 0xc1068478 cron 10872 1091 1091 0 S ppwait 0xcfc83000 cron 10871 1091 1091 0 S ppwait 0xcfc83218 cron 10870 10869 895 0 S vmmaps 0xc1068478 guard 10869 896 895 0 S select 0xc0a13084 guard 10868 914 914 0 S ufs 0xc82e49e8 proftpd 10867 10863 10867 0 SVs vmmaps 0xc1068478 cron 10866 10860 10866 0 SVs vmmaps 0xc1068478 cron 10865 10862 10865 0 SVs vmmaps 0xc1068478 cron 10864 10861 10864 0 SVs vmmaps 0xc1068478 cron 10863 1091 1091 0 S ppwait 0xcfc83648 cron 10862 1091 1091 0 S ppwait 0xcfc83860 cron 10861 1091 1091 0 S ppwait 0xcfbd1860 cron 10860 1091 1091 0 S ppwait 0xcfbd1a78 cron 10859 1025 10859 0 Ss vmmaps 0xc1068478 sshd [..some more..] db bt 10868 Tracing pid 10868 tid 100134 td 0xc85f44b0 sched_switch(c85f44b0,0,1) at sched_switch+0x143 mi_switch(1,0,c85f44b0,ee89c8cc,c06a484c,...) at mi_switch+0x1ba sleepq_switch(c82e49e8) at sleepq_switch+0x87 sleepq_wait(c82e49e8,0,c85f44b0,c82e49e8,4,...) at sleepq_wait+0x5c msleep(c82e49e8,c0a070c8,50,c0928d0d,0,...) at msleep+0x269 acquire(ee89c94c,40,6,c85f44b0,0,...) at acquire+0x7b lockmgr(c82e49e8,2002,c82e4a0c,c85f44b0) at lockmgr+0x3fe ffs_lock(ee89c9a8) at ffs_lock+0x88 VOP_LOCK_APV(c09d5e60,ee89c9a8) at VOP_LOCK_APV+0x43 vn_lock(c82e4990,2002,c85f44b0,c82e4990) at vn_lock+0xf4 vget(c82e4990,2002,c85f44b0) at vget+0xbe vfs_hash_get(c820b7c8,2,2,c85f44b0,ee89cac0,0,0) at vfs_hash_get+0xf5 ffs_vget(c820b7c8,2,2,ee89cac0) at ffs_vget+0x27 ufs_root(c820b7c8,2,ee89cb04,c85f44b0,1,...) at ufs_root+0x19 lookup(ee89cc00) at lookup+0x7f4 namei(ee89cc00) at namei+0x39a kern_stat(c85f44b0,bfbfd770,0,ee89cc74) at kern_stat+0x35 stat(c85f44b0,ee89cd04) at stat+0x1b syscall(3b,bfbf003b,bfbf003b,0,bfbfc710,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28315453, esp = 0xbfbfc63c, ebp = 0xbfbfc668 --- db bt 10864 Tracing pid 10864 tid 100241 td 0xc8a457d0 sched_switch(c8a457d0,0,1) at sched_switch+0x143 mi_switch(1,0,c8a457d0,ee8fcc10,c06a484c,...) at mi_switch+0x1ba sleepq_switch(c1068478) at sleepq_switch+0x87 sleepq_wait(c1068478,0,c8a457d0,c10683c0,42000,...) at sleepq_wait+0x5c msleep(c1068478,c0a21460,244,c093ab48,0,...) at msleep+0x269 vm_map_unlock_and_wait(c10683c0,0) at vm_map_unlock_and_wait+0x63 kmem_alloc_wait(c10683c0,41400,1,c8e9ea78,ee8fccb4,...) at kmem_alloc_wait+0x6b exec_copyin_args(ee8fccb4,80551c6,0,bfbfe6b0,8051140) at exec_copyin_args+0x3a execve(c8a457d0,ee8fcd04) at execve+0x1e syscall(805003b,3b,bfbf003b,bfbfe6f8,bfbfe6b0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x280e168f, esp = 0xbfbfe69c, ebp = 0xbfbfe6e8 --- db bt 10875 Tracing pid 10875 tid 100580 td 0xc8eb1640 sched_switch(c8eb1640,0,1) at sched_switch+0x143 mi_switch(1,0,c8eb1640,eebe4c54,c06a484c,...) at mi_switch+0x1ba sleepq_switch(cfc82a78) at sleepq_switch+0x87 sleepq_wait(cfc82a78,0,c8eb1640,cfc828c8,cfc82860,...) at sleepq_wait+0x5c msleep(cfc82a78,cfc828c8,5c,c09232c2,0) at msleep+0x269 fork1(c8eb1640,8034,0,eebe4cd4) at fork1+0x14d7 vfork(c8eb1640,eebe4d04) at vfork+0x1b syscall(805003b,3b,bfbf003b,80512f8,804e444,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (66, FreeBSD ELF32, vfork), eip = 0x280cde68, esp = 0xbfbfe710, ebp = 0xbfbfecc8 --- db bt 47 Tracing pid 47 tid 100041 td 0xc7f3d640 sched_switch(c7f3d640,0,1) at sched_switch+0x143 mi_switch(1,0,c7f3d640,e8506aa4,c06a484c,...) at mi_switch+0x1ba sleepq_switch(c8a58e28) at sleepq_switch+0x87 sleepq_wait(c8a58e28,0,c7f3d640,c8a58e28,4,...) at sleepq_wait+0x5c msleep(c8a58e28,c0a06f84,50,c0928d0d,0,...) at msleep+0x269 acquire(e8506b24,40,6,c7f3d640,0,...) at acquire+0x7b lockmgr(c8a58e28,2002,c8a58e4c,c7f3d640) at lockmgr+0x3fe ffs_lock(e8506b80) at ffs_lock+0x88 VOP_LOCK_APV(c09d5e60,e8506b80) at VOP_LOCK_APV+0x43 vn_lock(c8a58dd0,2002,c7f3d640,c8a58dd0) at vn_lock+0xf4 vget(c8a58dd0,2002,c7f3d640,c820b574,0,...) at vget+0xbe qsync(c820b530,2c1cf,0,0,0,...) at qsync+0x166 ffs_sync(c820b530,3,c7f3d640,c820b530,2) at ffs_sync+0x3d0 sync_fsync(e8506cc0) at sync_fsync+0x1e6
Re: PXE boot FreeBSD without need of NFS server
Pertti, András, Thank You for the useful links! Kiitos and Köszönöm szépen :-) Gót András wrote: Hi, AFAIK only the kernel and initrd (in the linux case) can be booted from tftp, that's a PXE feature. When the kernel loaded it takes over and from then on the kernel will need a rootfs from somewhere. I don't think that a tftp rootfs is possible. Yes, I know it's not possible to have the rootfs on tftp. That is not my goal. I only wish to host an image file containing a rootfs that will act as a ram disk. Much like the initrd does in the Linux world. The rootfs will only contain the things needed to start the installation process. I think I have the information I was looking for. Thanks again! Mikael ___ 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: loader not working with GPT and LOADER_ZFS_SUPPORT
MFC'd in 192969
On Wed, May 27, 2009 at 3:31 PM, Artis Caune artis.ca...@gmail.com wrote:
2009/5/28 Lorenzo Perone lopez.on.the.li...@yellowspace.net:
Hi, I'm a bit confused:
I can't find this change (rev 185095) in the stable log, yet stable has some
other
recent changes related to the current posts (in turn commited also to
head)...
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/libi386/biosdisk.c?view=log
http://svn.freebsd.org/viewvc/base/stable/7/sys/boot/i386/libi386/biosdisk.c?view=log
maybe I'm misunderstanding how things eventually get ingto -stable,
however, which revision to use now for a peaceful world boot? :)
I'll go for the -head version for my next try..
It's not merged to stable yet. You should apply r185095 diff by hand.
Just edit sys/boot/i386/libi386/biosdisk.c and change:
--- sys/boot/i386/libi386/biosdisk.c (revision 192872)
+++ sys/boot/i386/libi386/biosdisk.c (working copy)
@@ -996,8 +996,10 @@
od-od_boff = gp-gp_start;
out:
- if (error)
+ if (error) {
free(od-od_partitions);
+ od-od_flags = ~BD_GPTOK;
+ }
return (error);
}
@@ -1088,7 +1090,7 @@
switch(rw){
case F_READ:
- DEBUG(read %d from %d to %p, blks, dblk, buf);
+ DEBUG(read %d from %lld to %p, blks, dblk, buf);
if (blks bd_read(od, dblk, blks, buf)) {
DEBUG(read error);
--
Artis Caune
Everything should be made as simple as possible, but not simpler.
--
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
On Wed, May 27, 2009 at 11:04 AM, Artem Belevich fbsdl...@src.cx wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. --Artem Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert h...@restart.be 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. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´), function mp-m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? 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 -- 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: NFS on ZFS
The flags checks are too strict. File a PR. I'll fix it when I get to it. Sorrry. -Kip On Wed, May 27, 2009 at 7:24 PM, Mike Andrews mandr...@bit0.com wrote: On Tue, 26 May 2009, Mike Andrews wrote: Takahashi Yoshihiro wrote: Today's stable has a problem creating a new file via NFS on ZFS. On the NFS server, there is no problem. % cd /ZFS % mktemp hoge hoge % ls -l hoge -rw--- 1 nyan nyan 0 5 26 19:09 hoge But it's a problem on the NFS client. # mount server:/ZFS /ZFS % cd /ZFS % mktemp hoge mktemp: mkstemp failed on hoge: Input/output error % ls -l hoge -- 1 nyan wheel 0 5 26 19:09 hoge The file has a wrong permission. This problem is only on stable, current has no problem. I'm seeing this too. It seems so far to be limited to mkstemp() -- just copying files normally works. For example /usr/bin/install -S fails, without -S works, if the target is an NFS+ZFS volume. Anyone? I've verified that if the NFS server uses UFS2, mkstemp() from an NFS client to the server works fine, but if the NFS server uses ZFS, the NFS server returns EIO after creating a file with 000 permissions. In addition to breaking /usr/bin/install -S, it also breaks rsync over NFS. I don't yet know if it matters whether the on-disk format is ZFS v6 vs v13. -- 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: loader not working with GPT and LOADER_ZFS_SUPPORT
On 28 May 2009, at 9:40, Kip Macy wrote: MFC'd in 192969 Thanks for the explanation and all the hard work! Kind Regards, Ruben ___ 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: I've borked my ZFS system upgrading to -STABLE
On 27 May 2009, at 22:44, Kevin Day wrote:
tries to do a chflags on it, fails because ZFS doesn't support flags
are the pools already upgraded to v13 ? if not please do so with zpool
upgrade -a
Then in single user mode do
zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
flags should work now
Regards,
Ruben
___
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-28 11:26:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-28 11:26:51 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-05-28 11:26:51 - cleaning the object tree TB --- 2009-05-28 11:27:23 - cvsupping the source tree TB --- 2009-05-28 11:27:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-05-28 11:27:32 - building world TB --- 2009-05-28 11:27:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 11:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 11:27:32 - TARGET=amd64 TB --- 2009-05-28 11:27:32 - TARGET_ARCH=amd64 TB --- 2009-05-28 11:27:32 - TZ=UTC TB --- 2009-05-28 11:27:32 - __MAKE_CONF=/dev/null TB --- 2009-05-28 11:27:32 - cd /src TB --- 2009-05-28 11:27:32 - /usr/bin/make -B buildworld World build started on Thu May 28 11:27:33 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 28 13:00:57 UTC 2009 TB --- 2009-05-28 13:00:57 - generating LINT kernel config TB --- 2009-05-28 13:00:57 - cd /src/sys/amd64/conf TB --- 2009-05-28 13:00:57 - /usr/bin/make -B LINT TB --- 2009-05-28 13:00:57 - building LINT kernel TB --- 2009-05-28 13:00:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 13:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 13:00:57 - TARGET=amd64 TB --- 2009-05-28 13:00:57 - TARGET_ARCH=amd64 TB --- 2009-05-28 13:00:57 - TZ=UTC TB --- 2009-05-28 13:00:57 - __MAKE_CONF=/dev/null TB --- 2009-05-28 13:00:57 - cd /src TB --- 2009-05-28 13:00:57 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu May 28 13:00:57 UTC 2009 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer
Re: ZFS MFC heads down
Kip Macy wrote: On Wed, May 27, 2009 at 11:04 AM, Artem Belevich fbsdl...@src.cx wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. --Artem Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 Is it useful ? [r...@avoriaz ~]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) r rpool Starting program: /usr/sbin/zdb rpool (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100343] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100343)] [New Thread 0x801802240 (LWP 100346)] version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100347)] [New Thread 0x801802560 (LWP 100354)] [New Thread 0x8018026f0 (LWP 100355)] [New Thread 0x801802880 (LWP 100356)] [New Thread 0x801802a10 (LWP 100359)] [New Thread 0x801802ba0 (LWP 100360)] [New Thread 0x801802d30 (LWP 100368)] [New Thread 0x801802ec0 (LWP 100369)] [New Thread 0x801803050 (LWP 100370)] [New Thread 0x8018031e0 (LWP 100371)] [New Thread 0x801803370 (LWP 100372)] [New Thread 0x801803500 (LWP 100373)] [New Thread 0x801803690 (LWP 100374)] [New Thread 0x801803820 (LWP 100375)] [New Thread 0x8018039b0 (LWP 100376)] [New Thread 0x801803b40 (LWP 100377)] [New Thread 0x801803cd0 (LWP 100378)] [New Thread 0x801803e60 (LWP 100379)] [New Thread 0x801803ff0 (LWP 100380)] [New Thread 0x801804180 (LWP 100381)] [New Thread 0x801804310 (LWP 100382)] [New Thread 0x8018044a0 (LWP 100383)] [New Thread 0x801804630 (LWP 100384)] [New Thread 0x8018047c0 (LWP 100385)] [New Thread 0x801804950 (LWP 100386)] [New Thread 0x801804ae0 (LWP 100387)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100343)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 #13 0x00408b41 in ?? () #14 0x004036de in ?? () #15 0x000800534000 in ?? () #16 0x in ?? () #17 0x0002 in ?? () #18 0x7fffed70 in ?? () #19 0x7fffed7e in ?? () #20 0x in ?? () #21 0x7fffed84 in ?? () #22 0x7fffed9a in ?? () #23 0x7fffeda5 in ?? () #24 0x7fffedbf in ?? () #25 0x7fffedea in ?? () #26
zdb core (same problem?)
Hi! Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. I have another zdb mypool crash on a 7.2-STABLE. f7# zpool history mypool History for 'mypool': 2009-05-24.21:58:36 zpool create -m /spare1 mypool ad4s3d 2009-05-24.22:11:35 zfs set compression=on mypool 2009-05-25.08:07:04 zpool upgrade -a 2009-05-27.22:31:21 zpool scrub mypool 2009-05-27.22:31:26 zpool scrub mypool For a gdb with backtrace see http://opsec.eu/backup/zdb-backtrace -- p...@opsec.eu+49 171 310137211 years to go ! ___ 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 28/05/2009 16:26 Henri Hennebert said the following: (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 I find the above part interesting. Could this be because of the following discrepancy: 1) cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: extern void __assert(const char *, const char *, int); 2) lib/libc/gen/assert.c: void __assert(func, file, line, failedexpr) const char *func, *file; int line; const char *failedexpr; #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 But back to the problem - without an additional printf we still can not what was the value in m_owner. Only that it was not null. Probably it's better to build with debugging symbols and examine with gdb. -- 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
[releng_7 tinderbox] failure on i386/i386
TB --- 2009-05-28 12:33:50 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-28 12:33:50 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-05-28 12:33:50 - cleaning the object tree TB --- 2009-05-28 12:34:13 - cvsupping the source tree TB --- 2009-05-28 12:34:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-05-28 12:34:23 - building world TB --- 2009-05-28 12:34:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 12:34:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 12:34:23 - TARGET=i386 TB --- 2009-05-28 12:34:23 - TARGET_ARCH=i386 TB --- 2009-05-28 12:34:23 - TZ=UTC TB --- 2009-05-28 12:34:23 - __MAKE_CONF=/dev/null TB --- 2009-05-28 12:34:23 - cd /src TB --- 2009-05-28 12:34:23 - /usr/bin/make -B buildworld World build started on Thu May 28 12:34:25 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 World build completed on Thu May 28 13:40:58 UTC 2009 TB --- 2009-05-28 13:40:58 - generating LINT kernel config TB --- 2009-05-28 13:40:58 - cd /src/sys/i386/conf TB --- 2009-05-28 13:40:58 - /usr/bin/make -B LINT TB --- 2009-05-28 13:40:59 - building LINT kernel TB --- 2009-05-28 13:40:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 13:40:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 13:40:59 - TARGET=i386 TB --- 2009-05-28 13:40:59 - TARGET_ARCH=i386 TB --- 2009-05-28 13:40:59 - TZ=UTC TB --- 2009-05-28 13:40:59 - __MAKE_CONF=/dev/null TB --- 2009-05-28 13:40:59 - cd /src TB --- 2009-05-28 13:40:59 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu May 28 13:40:59 UTC 2009 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Slow detection of Dell SAS 6i/R aka LSILogic SAS/SATA Adapter (mpt0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm not sure if I should have sent this to freebsd-questions@, but here we go. I have a couple of Dell PowerEdge R200 rack servers, both equipped with the Dell SAS 6i/R RAID controller, running i386 7.2-RELEASE but they'll soon be upgraded to i386 7.2-STABLE. The mpt driver spends a minute or so eager to initialize the controller, but fails with the following messages: mpt0: LSILogic SAS/SATA Adapter port 0xec00-0xecff mem 0xdfbec000-0xdfbe,0xdfbf-0xdfbf irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.18.0 mpt0: mpt_wait_req(6) timed out mpt0: port 0 enable timed out mpt0: failed to enable port 0 mpt0: unable to initialize IOC The virtual disk comprised of two SAS disks is recognized as the following: da0 at mpt0 bus 0 target 0 lun 0 da0: Dell VIRTUAL DISK 1028 Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 285568MB (584843264 512 byte sectors: 255H 63S/T 36404C) Is there a way to get rid of the slow and failing initialization? I'd be happy to try out patches or even allow shell access. Complete dmesg output is available on demand. I can arrange for a verbose dmesg output if verbose booting is still an option. I can't remember the last time I attempted a verbose (re)boot. Trond. - -- - -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE Pine 4.64 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFKHphmbYWZalUoElsRAkrPAJ96OGFn8wVayjIDEtZOC6Vf97ohMACcDBVY tX+dVBQ879/lhJsMYczOaOs= =B7sL -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
ZFS booting without partitions (was: ZFS boot on zfs mirror)
Hi, I tried hard... but without success ;( the result is, when choosing the disk with the zfs boot sectors in it (in my case F5, which goes to ad6), the kernel is not found. the console shows: forth not found definitions not found only not found (the above repeated several times) can't load 'kernel' and I get thrown to the loader prompt. lsdev does not show any ZFS devices. Strange thing: if I boot from the other disk, F1, which is my ad4 containing the normal ufs system I used to make up the other one, and escape to the loader prompt, lsdev actually sees the zpool which is on the other disk, and shows: zfs0: tank I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, but there I get the panic: free: guard1 fail message. (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) Sure I'm doing something wrong, but what...? Is it a problem that the pool is made out of the second disk only (ad6)? Here are my details (note: latest stable and biosdisk.c merged with changes shown in r185095. no problems in buildworld/kernel): snip Machine: p4 4GHz 4 GB RAM (i386) Note: the pool has actually a different name (heidi instead of tank, if this can be of any relevance...), just using tank here as it's one of the conventions... mount (just to show my starting situation) /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) gmirror status NameStatus Components mirror/gm0 DEGRADED ad4 (ad6 used to be the second disk...) echo 'LOADER_ZFS_SUPPORT=yes' /etc/make.conf cd /usr/src make buildworld make buildkernel KERNCONF=HEIDI make installkernel KERNCONF=HEIDI mergemaster make installworld shutdown -r now dd if=/dev/zero of=/dev/ad6 bs=512 count=32 zpool create tank ad6 zfs create tank/usr zfs create tank/var zfs create -V 4gb tank/swap zfs set org.freebsd:swap=on tank/swap zpool set bootfs=tank tank rsync -avx / /tank rsync -avx /usr/ /tank/usr rsync -avx /var/ /tank/var cd /usr/src make installkernel KERNCONF=HEIDI DESTDIR=/tank zpool export tank dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 zpool import tank zfs set mountpoint=legacy tank zfs set mountpoint=/usr tank/usr zfs set mountpoint=/var tank/var shutdown -r now ... at the 'mbr prompt' I pressed F5 (the second disk, ad6) .. as written above, loader gets loaded (at this stage I suppose it's the stuff dd't after block 1024?), but kernel not found. /usr/src/sys/i386/conf/HEIDI: (among other things...): options KVA_PAGES=512 (/tank)/boot/loader.conf: vm.kmem_size=1024M vm.kmem_size_max=1024M vfs.zfs.arc_max=128M vfs.zfs.vdev.cache.size=8M vfs.root.mountfrom=zfs:tank (/tank)/etc/fstab: # DeviceMountpoint FStype Options DumpPass# tank/ zfs rw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /snap any help is welcome... don't know where to go from here right now. BTW: I can't stop thanking the team for the incredible pace at which bugs are fixed these days! Regards, Lorenzo On 26.05.2009, at 18:42, George Hartzell wrote: Andriy Gapon writes: on 26/05/2009 19:21 George Hartzell said the following: Dmitry Morozovsky writes: On Tue, 26 May 2009, Mickael MAILLOT wrote: MM Hi, MM MM i prefere use zfsboot boot sector, an example is better than a long talk: MM MM $ zpool create tank mirror ad4 ad6 MM $ zpool export tank MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 s/skeep/skip/ ? ;-) What is the reason for copying zfsboot one bit at a time, as opposed to dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 seek=1024 for the second part? and no 'count=1' for it? :-) [Just guessing] Apparently the first block of zfsboot is some form of MBR and the rest is zfs-specific code that goes to magical sector 1024. Ok, I managed to read the argument to seek as one block, apparently my coffee hasn't hit yet. I'm still confused about the two parts of zfsboot and what's magical about seeking to 1024. g. ___ 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: [releng_7 tinderbox] failure on i386/i386
on 28/05/2009 16:56 FreeBSD Tinderbox said the following: /src/sys/compat/linux/linux_mib.c: In function 'linux_kernver': /src/sys/compat/linux/linux_mib.c:267: warning: 'osrel' may be used uninitialized in this function *** Error code 1 I agree :-) So what would osrel be if pr != NULL but pr-pr_linux == NULL ? -- 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 down
Andriy Gapon wrote: on 28/05/2009 16:26 Henri Hennebert said the following: (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 I find the above part interesting. Could this be because of the following discrepancy: 1) cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: extern void __assert(const char *, const char *, int); 2) lib/libc/gen/assert.c: void __assert(func, file, line, failedexpr) const char *func, *file; int line; const char *failedexpr; #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 But back to the problem - without an additional printf we still can not what was the value in m_owner. Only that it was not null. Probably it's better to build with debugging symbols and examine with gdb. Firt try: [r...@avoriaz libzpool]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100299] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100299)] [New Thread 0x801802240 (LWP 100354)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100369)] [New Thread 0x801802560 (LWP 100370)] [New Thread 0x8018026f0 (LWP 100371)] [New Thread 0x801802880 (LWP 100372)] [New Thread 0x801802a10 (LWP 100376)] [New Thread 0x801802ba0 (LWP 100382)] [New Thread 0x801802d30 (LWP 100383)] [New Thread 0x801802ec0 (LWP 100384)] [New Thread 0x801803050 (LWP 100385)] [New Thread 0x8018031e0 (LWP 100386)] [New Thread 0x801803370 (LWP 100387)] [New Thread 0x801803500 (LWP 100388)] [New Thread 0x801803690 (LWP 100389)] [New Thread 0x801803820 (LWP 100390)] [New Thread 0x8018039b0 (LWP 100391)] [New Thread 0x801803b40 (LWP 100392)] [New Thread 0x801803cd0 (LWP 100393)] [New Thread 0x801803e60 (LWP 100394)] [New Thread 0x801803ff0 (LWP 100395)] [New Thread 0x801804180 (LWP 100396)] [New Thread 0x801804310 (LWP 100397)] [New Thread 0x8018044a0 (LWP 100398)] [New Thread 0x801804630 (LWP 100399)] [New Thread 0x8018047c0 (LWP 100400)] [New Thread 0x801804950 (LWP 100401)] [New Thread 0x801804ae0 (LWP 100402)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100299)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 #6 0x000800fef230 in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #7 0x00080102e2b0 in
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. --- clipped --- By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? I find the answer to this question and think it may be really useful to others: zdb -C [ -U path to zpool.cache ] Henri 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: [releng_7 tinderbox] failure on amd64/amd64
On Thu, May 28, 2009 at 09:15:38AM -0400, FreeBSD Tinderbox wrote: TB --- 2009-05-28 11:26:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-28 11:26:51 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-05-28 11:26:51 - cleaning the object tree TB --- 2009-05-28 11:27:23 - cvsupping the source tree TB --- 2009-05-28 11:27:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile /src/sys/compat/linux/linux_mib.c: In function 'linux_kernver': /src/sys/compat/linux/linux_mib.c:267: warning: 'osrel' may be used uninitialized in this function *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 ughh, fixed by r192981. Im sorry. -- Have fun! chd pgpei8VGudlrQ.pgp Description: PGP signature
Re: ZFS panic in zfs_fuid_create
on 27/05/2009 19:25 Lawrence Farr said the following: I updated my backup boxes to the latest and greatest ZFS code, and started getting the following panic on them all (3 machines): panic: zfs_fuid_create cpuid = 1 Uptime: 1h28m48s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort A quick google found kern/133020 with a patch from PJD that has fixed it for me. Should it be in stable or does it break something else? Hmm I wonder if you really do have UIDs or GIDs greater than 2147483647 defined on your system? -- 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: I've borked my ZFS system upgrading to -STABLE
on 28/05/2009 11:47 Ruben van Staveren said the following:
On 27 May 2009, at 22:44, Kevin Day wrote:
tries to do a chflags on it, fails because ZFS doesn't support flags
are the pools already upgraded to v13 ? if not please do so with zpool
upgrade -a
Then in single user mode do
zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
flags should work now
Big thanks for the recipe!
--
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: I've borked my ZFS system upgrading to -STABLE
On Thu, May 28, 2009 at 11:47 AM, Ruben van Staveren ru...@verweg.com wrote:
On 27 May 2009, at 22:44, Kevin Day wrote:
tries to do a chflags on it, fails because ZFS doesn't support flags
are the pools already upgraded to v13 ? if not please do so with zpool
upgrade -a
Then in single user mode do
zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
flags should work now
Regards,
Ruben
Just curious... doesn't a zfs upgrade -a do the same thing?
Regards,
Niki
___
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 issue?
I updated my stable box (i386) on Tuesday and started seeing errors like the below intermittently. Is anyone else seeing anything like this? I saw similar errors periodically doing portupgrade and portinstall. Besides the intermittent errors the stability is much improved, my i386 box hasn't crashed at all since the update. Previously I could crash the box fairly reproducibly. Thanks, Brad mv: /home/bdutton/email/spam/cur/1243427579.M855387P56232VCB777092I0003F135_0.uno,S=4010:2,S: set owner/group (was: 1000/89): Operation not permitted mv: /home/bdutton/email/spam/cur/1243427579.M855387P56232VCB777092I0003F135_0.uno,S=4010:2,S: set flags (was: ): Invalid argument mv: /home/bdutton/email/spam/cur/1243428013.M780180P56404VCB777092I0003F139_0.uno,S=3330:2,S: set owner/group (was: 1000/89): Operation not permitted mv: /home/bdutton/email/spam/cur/1243428013.M780180P56404VCB777092I0003F139_0.uno,S=3330:2,S: set flags (was: ): Invalid argument ___ 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: PXE boot FreeBSD without need of NFS server
On Thu, May 28, 2009 at 09:10:50AM +0200, Mikael Bak wrote: Pertti, András, Thank You for the useful links! Kiitos and Köszönöm szépen :-) Gót András wrote: Hi, AFAIK only the kernel and initrd (in the linux case) can be booted from tftp, that's a PXE feature. When the kernel loaded it takes over and from then on the kernel will need a rootfs from somewhere. I don't think that a tftp rootfs is possible. Yes, I know it's not possible to have the rootfs on tftp. That is not my goal. I only wish to host an image file containing a rootfs that will act as a ram disk. Much like the initrd does in the Linux world. The rootfs will only contain the things needed to start the installation process. Have a look at ThinBSD. It a mini FreeBSD-5.x system which uses a ramdisk image as root. It can be booted from a TFTP server, without NFS. The web site is here: http://thinbsd.zefyris.com/ I use it everyday to run a X terminal. -- Francois Tigeot ___ 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: RFC: side effects of fixing loader_conf_files handling
On Wed, Jan 21, 2009 at 4:39 PM, Andrew Thompson thom...@freebsd.org wrote: That sounds good, thanks for working on this. Hi All, With this change it seems that if /boot/loader.conf is not present the loader stops altogether at |. Was that the desired effect of these changes? It is not a big deal for me to touch the files during build but wanted to make sure that this was the desired effect. Thanks Scott ___ 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 booting without partitions (was: ZFS boot on zfs mirror)
hi, did you erase gmirror meta ? (on the last sector) with: gmirror clear ad6 2009/5/28 Lorenzo Perone lopez.on.the.li...@yellowspace.net: Hi, I tried hard... but without success ;( the result is, when choosing the disk with the zfs boot sectors in it (in my case F5, which goes to ad6), the kernel is not found. the console shows: forth not found definitions not found only not found (the above repeated several times) can't load 'kernel' and I get thrown to the loader prompt. lsdev does not show any ZFS devices. Strange thing: if I boot from the other disk, F1, which is my ad4 containing the normal ufs system I used to make up the other one, and escape to the loader prompt, lsdev actually sees the zpool which is on the other disk, and shows: zfs0: tank I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, but there I get the panic: free: guard1 fail message. (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) Sure I'm doing something wrong, but what...? Is it a problem that the pool is made out of the second disk only (ad6)? Here are my details (note: latest stable and biosdisk.c merged with changes shown in r185095. no problems in buildworld/kernel): snip Machine: p4 4GHz 4 GB RAM (i386) Note: the pool has actually a different name (heidi instead of tank, if this can be of any relevance...), just using tank here as it's one of the conventions... mount (just to show my starting situation) /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) gmirror status Name Status Components mirror/gm0 DEGRADED ad4 (ad6 used to be the second disk...) echo 'LOADER_ZFS_SUPPORT=yes' /etc/make.conf cd /usr/src make buildworld make buildkernel KERNCONF=HEIDI make installkernel KERNCONF=HEIDI mergemaster make installworld shutdown -r now dd if=/dev/zero of=/dev/ad6 bs=512 count=32 zpool create tank ad6 zfs create tank/usr zfs create tank/var zfs create -V 4gb tank/swap zfs set org.freebsd:swap=on tank/swap zpool set bootfs=tank tank rsync -avx / /tank rsync -avx /usr/ /tank/usr rsync -avx /var/ /tank/var cd /usr/src make installkernel KERNCONF=HEIDI DESTDIR=/tank zpool export tank dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 zpool import tank zfs set mountpoint=legacy tank zfs set mountpoint=/usr tank/usr zfs set mountpoint=/var tank/var shutdown -r now ... at the 'mbr prompt' I pressed F5 (the second disk, ad6) .. as written above, loader gets loaded (at this stage I suppose it's the stuff dd't after block 1024?), but kernel not found. /usr/src/sys/i386/conf/HEIDI: (among other things...): options KVA_PAGES=512 (/tank)/boot/loader.conf: vm.kmem_size=1024M vm.kmem_size_max=1024M vfs.zfs.arc_max=128M vfs.zfs.vdev.cache.size=8M vfs.root.mountfrom=zfs:tank (/tank)/etc/fstab: # Device Mountpoint FStype Options Dump Pass# tank / zfs rw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /snap any help is welcome... don't know where to go from here right now. BTW: I can't stop thanking the team for the incredible pace at which bugs are fixed these days! Regards, Lorenzo On 26.05.2009, at 18:42, George Hartzell wrote: Andriy Gapon writes: on 26/05/2009 19:21 George Hartzell said the following: Dmitry Morozovsky writes: On Tue, 26 May 2009, Mickael MAILLOT wrote: MM Hi, MM MM i prefere use zfsboot boot sector, an example is better than a long talk: MM MM $ zpool create tank mirror ad4 ad6 MM $ zpool export tank MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 s/skeep/skip/ ? ;-) What is the reason for copying zfsboot one bit at a time, as opposed to dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 seek=1024 for the second part? and no 'count=1' for it? :-) [Just guessing] Apparently the first block of zfsboot is some form of MBR and the rest is zfs-specific code that goes to magical sector 1024. Ok, I managed to read the argument to seek as one block, apparently my coffee hasn't hit yet. I'm still confused about the two parts of zfsboot and what's magical about seeking to 1024. g. ___ 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
Re: ZFS booting without partitions (was: ZFS boot on zfs mirror)
On 28.05.2009, at 21:46, Mickael MAILLOT wrote: hi, did you erase gmirror meta ? (on the last sector) with: gmirror clear ad6 ohps I had forgotten that. just did it (in single user mode), but it didn't help :( Shall I repeat any of the other steps after clearing gmirror meta? thanx a lot for your help... Lorenzo 2009/5/28 Lorenzo Perone lopez.on.the.li...@yellowspace.net: Hi, I tried hard... but without success ;( the result is, when choosing the disk with the zfs boot sectors in it (in my case F5, which goes to ad6), the kernel is not found. the console shows: forth not found definitions not found only not found (the above repeated several times) can't load 'kernel' and I get thrown to the loader prompt. lsdev does not show any ZFS devices. Strange thing: if I boot from the other disk, F1, which is my ad4 containing the normal ufs system I used to make up the other one, and escape to the loader prompt, lsdev actually sees the zpool which is on the other disk, and shows: zfs0: tank I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, but there I get the panic: free: guard1 fail message. (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) Sure I'm doing something wrong, but what...? Is it a problem that the pool is made out of the second disk only (ad6)? Here are my details (note: latest stable and biosdisk.c merged with changes shown in r185095. no problems in buildworld/kernel): () ___ 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: I've borked my ZFS system upgrading to -STABLE
On 28 mei 2009, at 19:33, Niki Denev nik...@cytexbg.com wrote: Just curious... doesn't a zfs upgrade -a do the same thing? The zpool upgrade is just for the pools, but the filesystems keep their original settings so we need to do that in a seperate move Regards, Niki Regards, Ruben ___ 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: I've borked my ZFS system upgrading to -STABLE
On Thu, 28 May 2009, Ruben van Staveren wrote: On 28 mei 2009, at 19:33, Niki Denev nik...@cytexbg.com wrote: Just curious... doesn't a zfs upgrade -a do the same thing? The zpool upgrade is just for the pools, but the filesystems keep their original settings so we need to do that in a seperate move There is both a zpool upgrade and a zfs upgrade command. The zfs upgrade does the filesystems, and the zpool upgrade does the pool. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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: A very big Thank You for the inclusion of ZFS
I'm in no way responsible for ZFS, but I wanted to let you know that emails like this are very very awesome to get. Thank you for the kind words, it does make FreeBSD development worthwhile when someone takes the time to send in kind words. -Alfred * Freddie Cash fjwc...@gmail.com [090526 12:35] wrote: I just wanted to send out a very big THANK YOU to all those who have had a hand in bringing ZFS to FreeBSD. You've done a wonderful job. With the release of FreeBSD 7.2, things have improved to the point where I can't crash our storage servers anymore (and I've tried all the things that would crash 7.0 and 7.1). Bravo! What impressed me even more, though, was just how performant a multiple raidz2 pool could be. During a normal backup run (rsync of 105 servers each night), we graph sustained reads of 80 MBytes/sec and writes of 50 MBytes/sec (via snmpd). Nothing too spectacular, but still quite nice. Didn't realise just how much of a bottleneck the remote network connections are, though. Doing a local iozone benchmark, using a command-line someone posted online as known to crash ZFS on FreeBSD 7.0, I was able to get just under 350 MBytes/sec sustained write throughput (as shown by snmpd) with over 15 MBytes/sec per drive (as shown by gstat). Fiddling with the iozone options, I was able to push that to over 400 MBytes/sec sustained write with just shy of 20 MBytes/sec per drive. And CPU utilisation never went above 40% per core. System never crashed, hung, locked up, of even seemed slow while connected via SSH. While those numbers may not seem all that high to some people, for us, those are amazing!! :) (We've never used SCSI, or RAID0, or RAID10, or FibreChannel, or any of the other fancy storage stuff that gives uber-high stats.) This gives us hope for just how many remote sites we'll be able to backup to these storage servers (ie still lots of headroom on the storage side, just need to boost the network side of things). For the curious, the hardware is: Tyan h2000M motherboard 2x dual-core AMD Opteron 2220 CPUs at 2.8 GHz 8 GB ECC DDR2-667 SDRAM 3Ware 9650SE-12ML PCIe RAID controller 3Ware 9550SXU-12ML PCI-X RAID controller (64-bit/133 MHz slot) 24x 500 GB WD SATA2 harddrives (12 per controller, configured as Single Drives) 4-port Intel Pro/1000MT PCIe NIC The software is: 64-bit FreeBSD 7.2-RELEASE no kmem tuning ZFS ARC limited to 1 GB via /boot/loader.conf test filesystem has no compression and no atime set Pool configuration: 3 raidz2 vdevs of 8 drives each (1 vdev uses 4-drives from each RAID controller, the other 2 vdevs use 8 drives from 1 controller) iozone commands: iozone -M -e -+u -T -t 128 -S 4096 -L 64 -r 4k -s 40g -i 0 -i 1 -i 2 -i 8 -+p 70 -C (350 MBytes/sec writes) iozone -M -e -+u -T -t 128 -r 128k -s 4g -i 0 -i 1 -i 2 -i 8 -+p 70 -C (400 MBytes/sec write) -- 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 -- - Alfred Perlstein ___ 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
hi
http://abc777pills.pisem.su ___ 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
