Re: ZFS panic with r255937

2013-10-03 Thread Andriy Gapon
on 02/10/2013 20:59 Keith White said the following:
 On Wed, 2 Oct 2013, Andriy Gapon wrote:
 
 on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
 Sorry, debugging this is *way* beyond me.  Any hints, patches to try?

 Please share the stack trace.

 -- 
 Andriy Gapon
 
 There's now a pr for this panic: kern/182570
 
 Here's the stack trace:
 
 root@freebsd10:/usr/src # kgdb /boot/kernel/kernel /var/crash/vmcore.last
 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...
 
 Unread portion of the kernel message buffer:
 panic: solaris assert: dn-dn_maxblkid == 0 
 (BP_IS_HOLE(dn-dn_phys-dn_blkptr[0]) || dnode_block_freed(dn, 0)), file:
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c,
 line: 598
 cpuid = 1
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00992b3280
 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00992b3330
 vpanic() at vpanic+0x126/frame 0xfe00992b3370
 panic() at panic+0x43/frame 0xfe00992b33d0
 assfail() at assfail+0x22/frame 0xfe00992b33e0
 dnode_reallocate() at dnode_reallocate+0x225/frame 0xfe00992b3430
 dmu_object_reclaim() at dmu_object_reclaim+0x123/frame 0xfe00992b3480
 dmu_recv_stream() at dmu_recv_stream+0xd79/frame 0xfe00992b36b0
 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00992b3920
 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00992b39c0
 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00992b3a20
 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00992b3a90
 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00992b3ae0
 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00992b3bf0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00992b3bf0


Thank you very much.
To me this looks very similar to a problem discovered and fixed in illumos some
time ago.  Please check if the following change improves the situation for you.

https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659

Raw:
https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659.patch

 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019dc9ca, rsp =
 0x7fff5ad8, rbp = 0x7fff5b60 ---
 KDB: enter: panic
 Uptime: 37m10s
 Dumping 874 out of 2023 MB:
 
 ...
 
 (kgdb) where
 #0  doadump (textdump=1) at pcpu.h:218
 #1  0x808b7217 in kern_reboot (howto=260) at
 /usr/src/sys/kern/kern_shutdown.c:447
 #2  0x808b7725 in vpanic (fmt=value optimized out, ap=value 
 optimized
 out) at /usr/src/sys/kern/kern_shutdown.c:754
 #3  0x808b7773 in panic (fmt=value optimized out) at
 /usr/src/sys/kern/kern_shutdown.c:683
 #4  0x81e5 in assfail (a=value optimized out, f=value optimized
 out, l=value optimized out) at
 /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81
 
 #5  0x81d09735 in dnode_reallocate (dn=0xf8006dde3000,
 ot=DMU_OT_PLAIN_FILE_CONTENTS, blocksize=1024, bonustype=DMU_OT_SA,
 bonuslen=168, tx=0xf8006d7a2600)
 at
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:596
 
 #6  0x81cff463 in dmu_object_reclaim (os=value optimized out,
 object=value optimized out, ot=DMU_OT_PLAIN_FILE_CONTENTS, blocksize=1024,
 bonustype=DMU_OT_SA, bonuslen=168)
 at
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c:155
 
 #7  0x81cfd849 in dmu_recv_stream (drc=0xfe00992b3728, fp=value
 optimized out, voffp=0xfe00992b3718, cleanup_fd=8, action_handlep=value
 optimized out)
 at
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1231
 
 #8  0x81d8b1fc in zfs_ioc_recv (zc=0xfe00372e1000) at
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4102
 
 #9  0x81d864ea in zfsdev_ioctl (dev=value optimized out, zcmd=value
 optimized out, arg=value optimized out, flag=value optimized out, 
 td=value
 optimized out)
 at
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5960
 
 #10 0x807af840 in devfs_ioctl_f (fp=0xf800052e1460, 
 com=3222821403,
 data=0xf8006ff1faa0, cred=value optimized out, td=0xf8003f7ba920) at
 /usr/src/sys/fs/devfs/devfs_vnops.c:757
 #11 0x8090e94a in kern_ioctl (td=0xf8003f7ba920, fd=value 
 optimized
 out, com=0) at file.h:319
 #12 0x8090e62f in sys_ioctl (td=0xf8003f7ba920,
 uap=0xfe00992b3b80) at /usr/src/sys/kern/sys_generic.c:698
 #13 0x80caee35 in amd64_syscall (td=0xf8003f7ba920, traced=0) at
 subr_syscall.c:134
 

Re: ZFS panic with r255937

2013-10-03 Thread Keith White

On Thu, 3 Oct 2013, Andriy Gapon wrote:


on 02/10/2013 20:59 Keith White said the following:

On Wed, 2 Oct 2013, Andriy Gapon wrote:


on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:

Sorry, debugging this is *way* beyond me.  Any hints, patches to try?


Please share the stack trace.

--
Andriy Gapon


There's now a pr for this panic: kern/182570

Here's the stack trace:

root@freebsd10:/usr/src # kgdb /boot/kernel/kernel /var/crash/vmcore.last
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...

Unread portion of the kernel message buffer:
panic: solaris assert: dn-dn_maxblkid == 0 
(BP_IS_HOLE(dn-dn_phys-dn_blkptr[0]) || dnode_block_freed(dn, 0)), file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c,
line: 598
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00992b3280
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00992b3330
vpanic() at vpanic+0x126/frame 0xfe00992b3370
panic() at panic+0x43/frame 0xfe00992b33d0
assfail() at assfail+0x22/frame 0xfe00992b33e0
dnode_reallocate() at dnode_reallocate+0x225/frame 0xfe00992b3430
dmu_object_reclaim() at dmu_object_reclaim+0x123/frame 0xfe00992b3480
dmu_recv_stream() at dmu_recv_stream+0xd79/frame 0xfe00992b36b0
zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00992b3920
zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00992b39c0
devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00992b3a20
kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00992b3a90
sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00992b3ae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe00992b3bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00992b3bf0



Thank you very much.
To me this looks very similar to a problem discovered and fixed in illumos some
time ago.  Please check if the following change improves the situation for you.

https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659

Raw:
https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659.patch
...


Yes, it does.  send/recv completes with no panic.  That patch fixes kern/182570 
for me.

Thanks!

...keith

Once the patch is applied svn diff gives me:

Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c(revision 
255986)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c(working copy)
@@ -677,6 +677,16 @@
if (err != 0)
return (err);
err = dmu_free_long_range_impl(os, dn, offset, length);
+
+   /*
+* It is important to zero out the maxblkid when freeing the entire
+* file, so that (a) subsequent calls to dmu_free_long_range_impl()
+* will take the fast path, and (b) dnode_reallocate() can verify
+* that the entire file has been freed.
+*/
+   if (offset == 0  length == DMU_OBJECT_END)
+   dn-dn_maxblkid = 0;
+
dnode_rele(dn, FTAG);
return (err);
 }
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (revision 
255986)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (working copy)
@@ -616,7 +616,7 @@
 */
if (dn-dn_datablkshift == 0) {
if (off != 0 || len  dn-dn_datablksz)
-   dmu_tx_count_write(txh, off, len);
+   dmu_tx_count_write(txh, 0, dn-dn_datablksz);
} else {
/* first block will be modified if it is not aligned */
if (!IS_P2ALIGNED(off, 1  dn-dn_datablkshift))

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


ports and NO_STAGE: portmaster leaves port-system in corrupt state

2013-10-03 Thread O. Hartmann
When NO_STAGE=yes is missing in the port's Makefile, as it is for a
couple of ports like  lang/perl5.16, then portmaster compiles, installs
and - corrupt the port-system, because it tries to lstat files it can
not find and ends up at the end of an unfinished installation. This
leaves the entry in the installed-port database corrupted. The port got
installed, but the database hasn't an entry anymore.

I found that the port system is in a very bad shape when one is using
CURRENT (10.0), where several things happened the same time like
converters/libiconv ahs gone as required port, libstdc++ has gone in
favour of libc++ and now ports that do not have this NO_STAGE= tag in
the toplevel Makefile. About the last piece - I miss a
warning/hint/information for those who has not the time following every
second informations on the mailing lists!

I regret that I forgot about three other ports I stumbled in where the
missing NO_STAGE=yes obviously solved the problem after I put it into
the Makefile - but that was simply a hunch - without knowing exactly
what I do. Again, I miss some informations about that and googling
didn't brought up deeper insight into that.

If someone would be so kind an d delegate me to a proper official
website where this NO_STAGE for the ports is explained a bit and
further if someone tells me what to do when I stumble into the next
port out of the 1200 I have to recompile, I would really appreciate
that.

Regards,

O.H.


signature.asc
Description: PGP signature


Re: ports and NO_STAGE: portmaster leaves port-system in corrupt state

2013-10-03 Thread Baptiste Daroussin
On Thu, Oct 03, 2013 at 02:17:34PM +0200, O. Hartmann wrote:
 When NO_STAGE=yes is missing in the port's Makefile, as it is for a
 couple of ports like  lang/perl5.16, then portmaster compiles, installs
 and - corrupt the port-system, because it tries to lstat files it can
 not find and ends up at the end of an unfinished installation. This
 leaves the entry in the installed-port database corrupted. The port got
 installed, but the database hasn't an entry anymore.

NO_STAGE is not missing, and the system is not corrupted. Try to make sure you
have the latest ports-mgmt/pkg installed (1.1.4_6)

regards,
Bapt


pgptQMlpBJK78.pgp
Description: PGP signature


Re: XEN additions cause failure to compile kernel

2013-10-03 Thread John
On Tue, Oct 01, 2013 at 02:41:14PM -0700, Sean Bruno wrote:

 Ok, so this email thread is on freebsd-current and I think you're trying
 to buld a XENHVM kernel for stable/9 ?  What happens if you use the
 provided XENHVM kernconf?

oops, sorry. I'll re-post in -stable if it's more appropiate there. As
you're here though, in answer to your query:

I re-did this on a different vanilla machine, and tried to build XENHVM. 
The GENERIC it sources is unmodified, as is the XENHVM. svn says this:

root@dev-0:/sys/amd64/compile/XENHVM # svn info /usr/src
Path: /usr/src
Working Copy Root Path: /usr/src
URL: https://svn0.eu.freebsd.org/base/releng/9.2
Relative URL: ^/releng/9.2
Repository Root: https://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 255996
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 255896
Last Changed Date: 2013-09-26 19:10:19 +0100 (Thu, 26 Sep 2013)

root@dev-0:/sys/amd64/compile/XENHVM # 

make errors like this:

clang -c -O2 -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  
-Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -nostdinc  -I. -I../../.. 
-I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h  -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -Werror  ../../../xen/evtchn/evtchn_dev.c
../../../xen/evtchn/evtchn_dev.c:321:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_version:   D_VERSION,
^~
.d_version = 
../../../xen/evtchn/evtchn_dev.c:322:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_open:  evtchn_open,
^~~
.d_open = 
../../../xen/evtchn/evtchn_dev.c:323:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_close: evtchn_close,
^~~~
.d_close = 
../../../xen/evtchn/evtchn_dev.c:324:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_read:  evtchn_read,
^~~
.d_read = 
../../../xen/evtchn/evtchn_dev.c:325:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_write: evtchn_write,
^~~~
.d_write = 
../../../xen/evtchn/evtchn_dev.c:326:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_ioctl: evtchn_ioctl,
^~~~
.d_ioctl = 
../../../xen/evtchn/evtchn_dev.c:327:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_poll:  evtchn_poll,
^~~
.d_poll = 
../../../xen/evtchn/evtchn_dev.c:328:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_name:  evtchn,
^~~
.d_name = 
../../../xen/evtchn/evtchn_dev.c:329:2: error: use of GNU old-style field 
designator extension
  [-Werror,-Wgnu-designator]
d_flags: 0,
^~~~
.d_flags = 
9 errors generated.
*** [evtchn_dev.o] Error code 1

Stop in /usr/src/sys/amd64/compile/XENHVM.
root@dev-0:/sys/amd64/compile/XENHVM # 

thanks for looking at this.
-- 
John


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: ports and NO_STAGE: portmaster leaves port-system in corrupt state

2013-10-03 Thread Baptiste Daroussin
On Thu, Oct 03, 2013 at 10:11:42AM -0300, Nilton Jose Rizzo wrote:
 Em Thu, 3 Oct 2013 14:38:57 +0200, Baptiste Daroussin escreveu
  On Thu, Oct 03, 2013 at 02:17:34PM +0200, O. Hartmann wrote:
   When NO_STAGE=yes is missing in the port's Makefile, as it is for a
   couple of ports like  lang/perl5.16, then portmaster compiles, installs
   and - corrupt the port-system, because it tries to lstat files it can
   not find and ends up at the end of an unfinished installation. This
   leaves the entry in the installed-port database corrupted. The port got
   installed, but the database hasn't an entry anymore.
  
  NO_STAGE is not missing, and the system is not corrupted. Try to 
  make sure you have the latest ports-mgmt/pkg installed (1.1.4_6)
 
   It's solve my problems with portupgrade ( see my last message about
 portupgrade/portmaster)
 

Those bugs concerned portupgrade/portmaster which should always update
ports-mgmt/pkg first.

Building packages in a clean room with a tool like ports-mgmt/poudriere, will
have make sure to use the proper version of pkg.

Last thanks to stage and that is one of the main purpose of stage, NOTHING was
corrupted!

regards,
Bapt


pgp25gKqYDwRs.pgp
Description: PGP signature


Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

2013-10-03 Thread Julian H. Stacey
Rui Paulo wrote:
 
 On 2 Oct 2013, at 16:57, Julian H. Stacey j...@berklix.com wrote:
 
  Hi current@,
  It seems I need if_urtwn driver for a really miniature WLAN USB stick,
   if_urtwn is only in current ?
  man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ?
 
 
 This driver was never merged to FreeBSD 9.

OK, Thanks for confirmation.


 Can you use FreeBSD 10 instead?

Yes, easier than building from 9.X I guess ( helps test alpha :-).
I'll fetch from local mirror, per
http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html


 The port reference in the man page is wrong. The firmware is now shipped as 
 part of the base system.

Oh nice, easier :-)

 
 --
 Rui Paulo

Thanks Rui !

PS In case anyone else mailed me off list, please resend,
As I had a disk overflow I checked beyond
http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045040.html
 nothing further, which is fine,

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
 Reply below not above, like a play script.  Indent old text with  .
 Send plain text.  No quoted-printable, HTML, base64, multipart/alternative.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


problem with portupgrade/pkg/ backup

2013-10-03 Thread Nilton Jose Rizzo
Hi all,

see the error message below ( command portupgrade -rR xorg )

---  Backing up the old version
pkg: No installed package matching .txz found

** Backup failed.
---  Skipping 'x11/xinput' (xinput-1.6.0) because a requisite package
'libXrandr-1.4.1' (x11/libXrandr) failed (specify -k to force)
---  Skipping 'x11/xterm' (xterm-296) because a requisite package
'libXpm-3.5.10' (x11/libXpm) failed (specify -k to force)
---  Skipping 'x11-servers/xorg-server' (xorg-server-1.7.7_8,1) because a
requisite package 'libXpm-3.5.10' (x11/libXpm) failed (specify -k to force)
---  Skipping 'x11-drivers/xf86-video-intel' (xf86-video-intel-2.7.1_4)
because a requisite package 'libXv-1.0.9,1' (x11/libXv) failed (specify -k to
force)
---  Skipping 'x11-drivers/xf86-video-vesa' (xf86-video-vesa-2.3.2) because a
requisite package 'libXpm-3.5.10' (x11/libXpm) failed (specify -k to force)
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! graphics/cairo (cairo-1.10.2_5,2) (backup error)
! x11-toolkits/libXmu (libXmu-1.1.1,1)  (backup error)
! x11/libXv (libXv-1.0.9,1) (backup error)
! x11/libXpm (libXpm-3.5.10)(backup error)
* x11-toolkits/libXaw (libXaw-1.0.11,2)
! x11/libXrandr (libXrandr-1.4.1)   (backup error)
* x11/xinput (xinput-1.6.0)
* x11/xterm (xterm-296)
* x11-servers/xorg-server (xorg-server-1.7.7_8,1)
* x11-drivers/xf86-video-intel (xf86-video-intel-2.7.1_4)
* x11-drivers/xf86-video-vesa (xf86-video-vesa-2.3.2)

Some port that I try update via portupgrade show this ...
if I give the command 
   make clean reinstall clean 

all ports marked as backup error can be updated

Any idea to solve this?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Prompt Live-CD/DVD with support for ZFS v.5000

2013-10-03 Thread Vladislav V. Prodan
Subj.

You want to add such a liveCD for automatic loading on PXE.
MfsBSD built with ZFS v.28 :(

Thanks.

-- 
Vladislav V. Prodan
System  Network Administrator
http://support.od.ua
+380 67 4584408, +380 99 4060508
VVP88-RIPE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: problem with portupgrade/pkg/ backup

2013-10-03 Thread Bryan Drewery
On 10/3/2013 5:32 PM, Nilton Jose Rizzo wrote:
 Hi all,
 
 see the error message below ( command portupgrade -rR xorg )
 
 ---  Backing up the old version
 pkg: No installed package matching .txz found

http://lists.freebsd.org/pipermail/freebsd-ports/2013-September/086175.html

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature