Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous State-Changed-From-To: open-patched State-Changed-By: rakuco State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 State-Changed-Why: I don't think the previous version worked. From your description, it looks like you've switched to building with libc++ whereas libstdc++ was being used before. The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6 (but we've backported) will finally make Qt build with libc++. We've just sent an exp-run request for Qt 4.8.5, and will hopefully fix all these errors once it is committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 I build the world/kernel since early this year with CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 in /etc/src.conf. I do not use those flags in /etc/make.conf! /etc/src.conf is supposed to target ONLY the /usr/src world, not the ports - this is as I interpret the man page for /etc/src.conf and it would be logical. But this rule/thinking seems to be broken by some includes from /usr/ports/Mk ingredients. I can assure that I didn't switch anything to build the ports but rebuilding world and then restarting building. Something must have changed since then in the logic of how libc++ slipped in instead of of libstdc++. What I did was a make delete-old-files, which deleted several GNU gcc stuff on all CURRENT boxes. I did not see that any lib got killed after I tried make delete-old-libs. And I did not check whether libstdc++ is still being built. There are many other occasions where now c++ errors occur and I guess those ports need to be reported in one by one via PR? signature.asc Description: PGP signature
Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
08.09.2013 10:14, O. Hartmann пишет: I can assure that I didn't switch anything to build the ports but rebuilding world and then restarting building. Something must have changed since then in the logic of how libc++ slipped in instead of of libstdc++. What I did was a make delete-old-files, which deleted several GNU gcc stuff on all CURRENT boxes. I did not see that any lib got killed after I tried make delete-old-libs. And I did not check whether libstdc++ is still being built. Yes, recently gcc was switched off by default at CURRENT, so libc++ is used both for the system and ports. There are many other occasions where now c++ errors occur and I guess those ports need to be reported in one by one via PR? Guess so. Preferrable with a patch. ;-) -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/07/13 21:46, O. Hartmann wrote:
On Sat, 07 Sep 2013 14:27:48 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 14:10, olli hauer wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
Most of these do work anyway. I'm sure about various of these. I have
them working on my PCs. This does not mean they don't need to be
tweaked anyway, but they have lower priority.
net-mgmt/ettercap is known broken and I have it in my pipe. I'm
giving this all the time I can, but I can''t spend too much time on
this right now. I'm going to check these and fix the broken ones asap.
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
glib20 I already fixed in the big commit. uses native or gnu where
appropriate. I'll also have a look at the ghostscript ports asap, but
at least ghostscript9 I have seen it working on my PCs.
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH, then
the 13 ports can be changed quickly to use the right iconv.
Most of those will use the right iconv anyway if only one is found.
Extending iconv.mk should be discussed with portmgr, adding a
variable shouldn't be a problem though.
This happens in editors/abiword:
libtool: link: ( cd .libs rm -f libimp.la ln -s
../libimp.la libimp.la ) gmake[7]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Entering directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
../../doltlibtool
--tag=CXX --mode=link c++ -O2 -pipe -O3 -march=native
-fno-strict-aliasing -lgsf-1 -lgobject-2.0 -lglib-2.0 -lintl
-L/usr/local/lib -lxml2 -lgthread-2.0 -pthread -lgobject-2.0
-L/usr/local/lib -lglib-2.0 -lintl -L../../src -labiword-2.8 -lz
-avoid-version -module -no-undefined -L/usr/local/lib -o
opendocument.la -rpath /usr/local/lib/abiword-2.8/plugins
common/libcommon.la exp/libexp.la imp/libimp.la -ljpeg
grep: /usr/local/lib/libiconv.la: No such file or directory
sed: /usr/local/lib/libiconv.la: No such file or directory libtool:
link: `/usr/local/lib/libiconv.la' is not a valid libtool archive
gmake[6]: *** [opendocument.la] Error 1 gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins' gmake[3]: ***
[all-recursive] Error 1 gmake[3]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' gmake[2]: *** [all]
Error 2 gmake[2]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' === Compilation failed
unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the failure to the maintainer. *** Error code 1
This one looks like you still have some old libtoool archive which
references libiconv laying around.
Can you try again this command line(I rewrite here for convenience):
find /usr/local/lib -name '*.la' -exec grep -qi iconv {} \; -print |
xargs -n 1 pkg which -oq | sort -u
and force rebuild of any port which still shows up?
If none shows up (which would be strange, but I can't exclude anything)
Hope is not lost and there are still some things we can try.
--
Guido Falsi madpi...@freebsd.org
___
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: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sat, Sep 07, 2013 at 02:35:45PM +0200, Jeremie Le Hen wrote: Hi, I have the following panic every time I do a zfs receive on a given dataset. For the background, I synchronize a zfs dataset every couple of minutes using zfs send/receive. I think I recently got a panic (I'm running mav@'s geom direct dispatch patch) which probably happen at a bad time and left the snapshot/data in an inconsistent state. Now, whenever my cron job runs, it triggers the panic. The process that triggers the panic is: zfs receive -F data/jail/caravan Probably relevant, on boot, I have the following message: Solaris: WARNING: can't open objset for data/jail/caravan/%recv I have a core around if needed to debug. I will not try to repair the snapshot/dataset during this weekend, to get a chance to test a patch. Afterward I will have to start this job again. panic: solaris assert: dn-dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e62401a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e6240250 vpanic() at vpanic+0x126/frame 0xfe00e6240290 panic() at panic+0x43/frame 0xfe00e62402f0 assfail() at assfail+0x22/frame 0xfe00e6240300 dmu_tx_hold_free() at dmu_tx_hold_free+0x167/frame 0xfe00e62403e0 dmu_free_long_range() at dmu_free_long_range+0x1f5/frame 0xfe00e6240450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfe00e6240480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfe00e62406b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00e6240920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00e62409c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00e6240a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00e6240a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00e6240ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e6240bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e6240bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019ddf1a, rsp = 0x7fff5c08, rbp = 0x7fff5c90 --- I rolled back my kernel arbitrarily in the past (2013/08/01). The panic doesn't happen any more. I will try to narrow this down by dichotomy but that will be more efficient if someone has a rough idea wherefrom the problem appeared. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: random(4) update causes mips compile fail | mips boot fail
Glen Barber g...@freebsd.org writes: The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. It just so happens that this device is implemented entirely in software, not in hardware, but it's no different from trying to read from an empty optical drive. The only thing that has changed, in practical terms, is that previously if they tried to read from an empty drive (to continue the analogy) we'd nod and smile and feed them zeroes, whereas now we wait for someone to insert a disc. So Mark didn't really break anything here (apart from the build breakage which has already been fixed), he just made an existing bug visible. And he's already reverted the *one* line of code that did this, so mips is now almost as broken as it was before (only almost, because the first commit also fixed some serious harvesting / entropy estimation bugs). Anyway, on platforms that support tunables, this should help: Index: sys/dev/random/randomdev_soft.c === --- sys/dev/random/randomdev_soft.c (revision 255371) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -102,6 +102,8 @@ #endif +TUNABLE_INT(kern.random.sys.seeded, random_context.seeded); + /* List for the dynamic sysctls */ static struct sysctl_ctx_list random_clist; On platforms that don't, we need to figure out a better solution; possibly Pawel's early harvesting patch, which, while not perfect, at least introduces a minimum of entropy into Yarrow before boot. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: New iSCSI stack.
Wiadomość napisana przez Alfred Perlstein bri...@mu.org w dniu 6 wrz 2013, o godz. 20:18: On 9/5/13 3:27 AM, Edward Tomasz Napierała wrote: Hello. At http://people.freebsd.org/~trasz/cfiscsi-20130904.diff you'll find a patch which adds the new iSCSI initiator and target, against 10-CURRENT. To use the new initiator, start with man iscsictl. For the target - man ctld. All feedback is welcome. If nothing unexpected comes up, I'll commit it in a few days from now. Note that it's still not optimized; at this point I'm focusing more on reliability and interoperability. This work is being sponsored by FreeBSD Foundation. ___ 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 Edward, this is really exciting! Is there an easy way to use the userland iscsi configuration files? Which iSCSI userland configuration files, the ctl.conf(5)? If you need an ability to parse it and modify from a shell scripts, see confctl utility (sysutils/confctl, https://github.com/trasz/confctl/). We would love to quickly backport and ship this with FreeNAS as an option for our users, having the config files be the same OR having a very good converter would really make that much easier for us. Porting to 9 should be quite easy - there are Capsicum API differences; you might also want to compare CTL between 10 and 9 to see if there are any changes which need to be merged. Taking a look at the code searching for possible security issues would be also very welcome :-) As for the config files - writing a converter should be quite easy. Which configuration files you need to support, ctl.conf(5) and istgt configuration? ___ 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: New iSCSI stack.
On Sun, Sep 08, 2013 at 12:29:53PM +0200, Edward Tomasz Napiera?a wrote: We would love to quickly backport and ship this with FreeNAS as an option for our users, having the config files be the same OR having a very good converter would really make that much easier for us. Porting to 9 should be quite easy - there are Capsicum API differences; you might also want to compare CTL between 10 and 9 to see if there are any changes which need to be merged. Taking a look at the code searching for possible security issues would be also very welcome :-) As for the config files - writing a converter should be quite easy. Which configuration files you need to support, ctl.conf(5) and istgt configuration? Can you write utility for _generate_ ctl.conf from runtime configuration? Curenly configuring directly by `ctladm create` is more predictable from script, but incompatible by syntax and not persistent. ___ 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: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sun, 08 Sep 2013 10:44:01 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 21:46, O. Hartmann wrote:
On Sat, 07 Sep 2013 14:27:48 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/07/13 14:10, olli hauer wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
Most of these do work anyway. I'm sure about various of these. I
have them working on my PCs. This does not mean they don't need to
be tweaked anyway, but they have lower priority.
net-mgmt/ettercap is known broken and I have it in my pipe. I'm
giving this all the time I can, but I can''t spend too much time on
this right now. I'm going to check these and fix the broken ones
asap.
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
glib20 I already fixed in the big commit. uses native or gnu where
appropriate. I'll also have a look at the ghostscript ports asap,
but at least ghostscript9 I have seen it working on my PCs.
Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
If Uses/iconv.mk can be extended with something like ICON_PATH,
then the 13 ports can be changed quickly to use the right iconv.
Most of those will use the right iconv anyway if only one is found.
Extending iconv.mk should be discussed with portmgr, adding a
variable shouldn't be a problem though.
This happens in editors/abiword:
libtool: link: ( cd .libs rm -f libimp.la ln -s
../libimp.la libimp.la ) gmake[7]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
gmake[6]: Entering directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
../../doltlibtool
--tag=CXX --mode=link c++ -O2 -pipe -O3 -march=native
-fno-strict-aliasing -lgsf-1 -lgobject-2.0 -lglib-2.0 -lintl
-L/usr/local/lib -lxml2 -lgthread-2.0 -pthread -lgobject-2.0
-L/usr/local/lib -lglib-2.0 -lintl -L../../src -labiword-2.8 -lz
-avoid-version -module -no-undefined -L/usr/local/lib -o
opendocument.la -rpath /usr/local/lib/abiword-2.8/plugins
common/libcommon.la exp/libexp.la imp/libimp.la -ljpeg
grep: /usr/local/lib/libiconv.la: No such file or directory
sed: /usr/local/lib/libiconv.la: No such file or directory libtool:
link: `/usr/local/lib/libiconv.la' is not a valid libtool archive
gmake[6]: *** [opendocument.la] Error 1 gmake[6]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6/plugins' gmake[3]:
*** [all-recursive] Error 1 gmake[3]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' gmake[2]: *** [all]
Error 2 gmake[2]: Leaving directory
`/usr/ports/editors/abiword/work/abiword-2.8.6' === Compilation
failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild
before reporting the failure to the maintainer. *** Error code 1
This one looks like you still have some old libtoool archive which
references libiconv laying around.
Can you try again this command line(I rewrite here for convenience):
find /usr/local/lib -name '*.la' -exec grep -qi iconv {} \; -print |
xargs -n 1 pkg which -oq | sort -u
and force rebuild of any port which still shows up?
If none shows up (which would be strange, but I can't exclude
anything) Hope is not lost and there are still some things we can try.
On one box, the command sequence (thanks for being redundant, I didn't
find the previous email with the sequence within) reveals:
converters/psiconv
editors/abiword
math/gnumeric
Deleteing psiconv and gnumeric makes the sequence not showing both
ports again, but then, installing gnumeric again, which reels in
psiconv, the output of the command sequence is a s shown. Something is
strange here ... Another prerequisite port with oldish iconv reliances?
signature.asc
Description: PGP signature
Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous State-Changed-From-To: open-patched State-Changed-By: rakuco State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 State-Changed-Why: I don't think the previous version worked. From your description, it looks like you've switched to building with libc++ whereas libstdc++ was being used before. The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6 (but we've backported) will finally make Qt build with libc++. We've just sent an exp-run request for Qt 4.8.5, and will hopefully fix all these errors once it is committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 I build the world/kernel since early this year with CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 in /etc/src.conf. I do not use those flags in /etc/make.conf! /etc/src.conf is supposed to target ONLY the /usr/src world, not the ports - this is as I interpret the man page for /etc/src.conf and it would be logical. But this rule/thinking seems to be broken by some includes from /usr/ports/Mk ingredients. Since r255321, -stdlib=libc++ is effectively the default, at least when you haven't set gcc as the default compiler. So it also applies to ports, which unavoidably will lead to a bit of fallout. My personal experience is that most C++-based ports compile fine with libc++ instead of libstdc++, except for a few that rely on internal libstdc++ details. However, -std=c++11 is *not* yet the default, and C++11 has different rules here and there, so some ports might fail to compile due to this. For some ports, too much hacking may be required to make them work with C++11. So in case of trouble, try removing -std=, or setting it to different values (c++0x, c++98, gnu++98, etc), to get the port to compile. Note the base system should have no problems with -std=c++11, so please continue to use the option in src.conf, and report any problems if you encounter them, so we can fix them. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:36, Glen Barber g...@freebsd.org wrote: Either way, I think this commit needs to be reverted until properly fixed and tested. The hyperbole is getting a little thick. How about sysctl kern.random.sys.seeded=1 ?? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:31, Glen Barber g...@freebsd.org wrote: On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: ok. So I can work around this for these MIPS AP images by echoing something into /dev/random ? The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Calling echo '' /dev/random the KNOB is insulting. Using a write to /dev/random as a reseed was there from day one (check random(4)), and while it is not the clearest thing on the planet that a reseed unblocks the device, that has always been there by intent. That is how etc/rc.d/initrandom is supposed to work. In checking the man page I've released that connection needs to be clarified. I've (re)set the seeded bit, so behaviour is as it was. I'll look for a way to set this bit from the kernel config file. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New iSCSI stack.
On Sun, Sep 8, 2013 at 6:29 AM, Edward Tomasz Napierała tr...@freebsd.orgwrote: Wiadomość napisana przez Alfred Perlstein bri...@mu.org w dniu 6 wrz 2013, o godz. 20:18: On 9/5/13 3:27 AM, Edward Tomasz Napierała wrote: Hello. At http://people.freebsd.org/~trasz/cfiscsi-20130904.diffyou'll find a patch which adds the new iSCSI initiator and target, against 10-CURRENT. To use the new initiator, start with man iscsictl. For the target - man ctld. All feedback is welcome. If nothing unexpected comes up, I'll commit it in a few days from now. Note that it's still not optimized; at this point I'm focusing more on reliability and interoperability. This work is being sponsored by FreeBSD Foundation. ___ 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 Edward, this is really exciting! Is there an easy way to use the userland iscsi configuration files? Which iSCSI userland configuration files, the ctl.conf(5)? If you need an ability to parse it and modify from a shell scripts, see confctl utility (sysutils/confctl, https://github.com/trasz/confctl/). We would love to quickly backport and ship this with FreeNAS as an option for our users, having the config files be the same OR having a very good converter would really make that much easier for us. Porting to 9 should be quite easy - there are Capsicum API differences; you might also want to compare CTL between 10 and 9 to see if there are any changes which need to be merged. Taking a look at the code searching for possible security issues would be also very welcome :-) As for the config files - writing a converter should be quite easy. Which configuration files you need to support, ctl.conf(5) and istgt configuration? I was i belive quite close to having it working on the last patch, however could never seem to get the ctl kernel module to function, And feel im a bit further away with this latest patch retracing my steps, from previous... quite easy to backport maybe for you, or other but yes, I also would like to integrate the work to stable/9 in the lab for some benchmarks ___ 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 ___ 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: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
Alexander Motin m...@freebsd.org wrote: I would like to invite more people to review and test my patches for improving CAM and GEOM scalability, that for last six months you could see developing in project/camlock SVN branch. Full diff of that branch against present head (r255131) can be found here: http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch So far I haven't noticed any issues with this patch (or later on with camlock_20130906.patch) using glabel, ggatec, geli and ZFS on amd64. cdda2wav continued to work as expected as well. Fabian signature.asc Description: PGP signature
Re: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Regards Steve - Original Message - From: Jeremie Le Hen j...@freebsd.org To: freebsd-current@FreeBSD.org Sent: Sunday, September 08, 2013 9:54 AM Subject: Re: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0 On Sat, Sep 07, 2013 at 02:35:45PM +0200, Jeremie Le Hen wrote: Hi, I have the following panic every time I do a zfs receive on a given dataset. For the background, I synchronize a zfs dataset every couple of minutes using zfs send/receive. I think I recently got a panic (I'm running mav@'s geom direct dispatch patch) which probably happen at a bad time and left the snapshot/data in an inconsistent state. Now, whenever my cron job runs, it triggers the panic. The process that triggers the panic is: zfs receive -F data/jail/caravan Probably relevant, on boot, I have the following message: Solaris: WARNING: can't open objset for data/jail/caravan/%recv I have a core around if needed to debug. I will not try to repair the snapshot/dataset during this weekend, to get a chance to test a patch. Afterward I will have to start this job again. panic: solaris assert: dn-dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e62401a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e6240250 vpanic() at vpanic+0x126/frame 0xfe00e6240290 panic() at panic+0x43/frame 0xfe00e62402f0 assfail() at assfail+0x22/frame 0xfe00e6240300 dmu_tx_hold_free() at dmu_tx_hold_free+0x167/frame 0xfe00e62403e0 dmu_free_long_range() at dmu_free_long_range+0x1f5/frame 0xfe00e6240450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfe00e6240480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfe00e62406b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00e6240920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00e62409c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00e6240a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00e6240a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00e6240ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e6240bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e6240bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019ddf1a, rsp = 0x7fff5c08, rbp = 0x7fff5c90 --- I rolled back my kernel arbitrarily in the past (2013/08/01). The panic doesn't happen any more. I will try to narrow this down by dichotomy but that will be more efficient if someone has a rough idea wherefrom the problem appeared. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric d...@freebsd.org wrote: On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous State-Changed-From-To: open-patched State-Changed-By: rakuco State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 State-Changed-Why: I don't think the previous version worked. From your description, it looks like you've switched to building with libc++ whereas libstdc++ was being used before. The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6 (but we've backported) will finally make Qt build with libc++. We've just sent an exp-run request for Qt 4.8.5, and will hopefully fix all these errors once it is committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 I build the world/kernel since early this year with CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 in /etc/src.conf. I do not use those flags in /etc/make.conf! /etc/src.conf is supposed to target ONLY the /usr/src world, not the ports - this is as I interpret the man page for /etc/src.conf and it would be logical. But this rule/thinking seems to be broken by some includes from /usr/ports/Mk ingredients. Since r255321, -stdlib=libc++ is effectively the default, at least when you haven't set gcc as the default compiler. So it also applies to ports, which unavoidably will lead to a bit of fallout. My personal experience is that most C++-based ports compile fine with libc++ instead of libstdc++, except for a few that rely on internal libstdc++ details. However, -std=c++11 is *not* yet the default, and C++11 has different rules here and there, so some ports might fail to compile due to this. For some ports, too much hacking may be required to make them work with C++11. So in case of trouble, try removing -std=, or setting it to different values (c++0x, c++98, gnu++98, etc), to get the port to compile. Note the base system should have no problems with -std=c++11, so please continue to use the option in src.conf, and report any problems if you encounter them, so we can fix them. :-) -Dimitry Hello Dimitry. I ONLY use -std=c++11 in /etc/src.conf. The base system had never problems so far since I use it. In /etc/make.conf, I avoid it. But, and this is obviously a logical incosistency, the ports system includes also /etc/src.conf, and I consider /etc/src.conf as base system only as the man page suggests. But the discussion has already been on the list. Somewhere in the basd.*.mk files, /etc/src.conf is included. And I guess therefore it comes to problems. Oliver signature.asc Description: PGP signature
Re: random(4) update causes mips compile fail | mips boot fail
On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: Glen Barber g...@freebsd.org writes: The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. To be clear, when I sent my last emails, tinderbox was complaining about build failures (which it did not catch up to the recent head/ revisions), so at the time I thought head/ was still broken for arm and mips architectures. Sorry for the misunderstanding on my part. delphij corrected me on this. Glen pgpx0TW6Ib31m.pgp Description: PGP signature
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 18:31, Glen Barber g...@freebsd.org wrote: On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: Glen Barber g...@freebsd.org writes: The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. To be clear, when I sent my last emails, tinderbox was complaining about build failures (which it did not catch up to the recent head/ revisions), so at the time I thought head/ was still broken for arm and mips architectures. Sorry for the misunderstanding on my part. delphij corrected me on this. No worries, thanks! Keep up the good work! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
- Original Message - From: Jeremie Le Hen j...@freebsd.org On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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 building boot2 amd64-i386
Hi, I currently try to build the boot2 part of the bootloader on my amd64 for i386. I tried the crochet building script for the i386 and this script run into the problem. How to repeat: # cd head/sys/boot/i386/boot2 # make TARGET_ARCH=i386 Warning: Object directory not changed from original /usr/home/martin/Rasperry/head/sys/boot/i386/boot2 cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/home/martin/Rasperry/head/sys/boot/i386/boot2/../../common -I/usr/home/martin/Rasperry/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -march=i386 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -m32 -c boot1.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000123 secs (4161790 bytes/sec) make: don't know how to make /usr/home/martin/Rasperry/head/sys/boot/i386/boot2/../btx/lib/crt0.o. Stop Don't get confused that the head source is in a directory named raspberry - I just want to build a reference i386 system to see if a problem with the kerberos also occurs on i386 systems. Is there a way to build the boot2 part the right way? In this case I would like to update the crochet script. Thank you, Martin Laabs ___ 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: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Fri, 06 Sep 2013 09:34:52 +0200
Guido Falsi madpi...@freebsd.org wrote:
On 09/06/13 05:16, AN wrote:
Hi:
I am posting to both lists because this problem affects users of
current and ports, and I didn't know which would be more
appropriate so please forgive me.
# uname -a
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #80 r255129: Sun
Sep 1 16:01:36 CDT 2013
root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64
I am trying to update my ports following the entry in updating, but
it does not seem to be working correctly. I followed the directions
exactly, and after 30 mins this is what has happened:
# cat ports_to_update | xargs portupgrade -vf
--- Session started at: Thu, 05 Sep 2013 21:12:10 -0500
[Reading data from pkg(8) ... - 890 packages found - done]
Shared object libiconv.so.3 not found, required by httpd
make: /usr/ports/Mk/bsd.apache.mk line 278: warning: Couldn't read
shell's output for /usr/local/sbin/httpd -V | /usr/bin/sed -ne
's/^Server version: Apache\/\([0-9]\)\.\([0-9]*\).*/\1\2/p'
Shared object libiconv.so.3 not found, required by httpd
This is bsd.apache.mk trying to get the apache version. but the
apache's httpd binary cannot run because it can't find
libiconv.so.3.
apxs:Error: Sorry, no shared object support for Apache.
apxs:Error: available under your platform. Make sure.
apxs:Error: the Apache module mod_so is compiled into.
apxs:Error: your server binary `/usr/local/sbin/httpd'..
make: /usr/ports/Mk/bsd.apache.mk line 284: warning:
/usr/local/sbin/apxs -q MPM_NAME returned non-zero status
** Port marked as IGNORE: www/mod_dnssd:
is marked as broken: : Error from bsd.apache.mk. apache is
installed (or APACHE_PORT is defined) and port requires apache22 at
least
Here is what I have done:
# pkg query %ro libiconv ports_to_update
[root@FBSD10 ~]# cat ports_to_update
...lots of output
# pkg delete -f libiconv
pkg: You are trying to delete package(s) which has dependencies
that are still required:
... delete these packages anyway in forced mode
Deinstallation has been requested for the following 1 packages:
libiconv-1.14_1
The deinstallation will free 2 MB
Proceed with deinstalling packages [y/N]: y
[1/1] Deleting libiconv-1.14_1...
deleting anyway
done
Now the update process is stuck here:
** Port marked as IGNORE: www/mod_dnssd:
is marked as broken: : Error from bsd.apache.mk. apache is
installed (or APACHE_PORT is defined) and port requires apache22 at
least
there are 2 ruby processes running for a long time, but nothing is
happening to the update.
43998 root520 64912K 33368K piperd 5 2:21 5.96%
ruby19{ruby19}
43998 root520 64912K 33368K select 1 0:00 5.96%
ruby19{ruby19}
So, it seems my system is broken now. Did I do something wrong?
How can the upgrade work if so many ports depend on iconv? What
should I do now? Should I reinstall libiconv?
Good news is the update process did not really update anything,
judging from the output you sent. If you just reinstall libiconv
everything should go back to how it was, at least you get a working
system.
I admit I did not foresee this condition arising when I wrote the
instructions, here is a modified procedure you can follow and report
back about, so I can modify the UPDATING entry:
# pkg query %ro libiconv ports_to_update
# cp /usr/local/lib/libiconv.so.3 /usr/local/lib/compat/pkg/
# ldconfig -R
(1) # pkg delete -f libiconv
# cat ports_to_update | xargs portupgrade -f
(1) not sure if ldconfig -R is really needed, but It will not do any
harm
I added the step to preserve libiconv.so.3
in /usr/local/lib/compat/pkg which is in the default library search
path. In this way libiconv and it's include file shouldn't be found
by configure scripts and the like and they should link to the system
one, while existing binaries should keep working linking to the
preserved one in lib/compat.
Any help is appreciated.
I hope this helps you, just ask for any clarifications and further
help as needed on this matter.
Just for the record:
after three days of cleaning up this mess today two boxes got ready,
servers, without any GUI or fancy X11 stuff. They work.
Two other development boxes reject compiling kdelibs and stuff. After
the final update today on CURRENT r255398, ports like kdevelop,
firefox, libreoffice(!) and others crash along with virtualbox-ose-kmod
(coredump). Most of that stuff, including libreoffice, firefox was
ready last night, including kdelibs and the stuff for kdevelop. It
worked today - until now, r255398.
I do not know what happened here, but I'm through with it. Two
obviously independend processes, one from the ports side, another from
the OS side, intertwined and messy as hell rendered the systems
completely unusable.
As I reported on several occasions, after r255259 it wasn't
Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric d...@freebsd.org wrote: On Sep 8, 2013, at 08:14, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: Synopsis: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous State-Changed-From-To: open-patched State-Changed-By: rakuco State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 State-Changed-Why: I don't think the previous version worked. From your description, it looks like you've switched to building with libc++ whereas libstdc++ was being used before. The upcoming Qt 4.8.5 plus a few patches which only made it to 4.8.6 (but we've backported) will finally make Qt build with libc++. We've just sent an exp-run request for Qt 4.8.5, and will hopefully fix all these errors once it is committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 I build the world/kernel since early this year with CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 in /etc/src.conf. I do not use those flags in /etc/make.conf! /etc/src.conf is supposed to target ONLY the /usr/src world, not the ports - this is as I interpret the man page for /etc/src.conf and it would be logical. But this rule/thinking seems to be broken by some includes from /usr/ports/Mk ingredients. Since r255321, -stdlib=libc++ is effectively the default, at least when you haven't set gcc as the default compiler. So it also applies to ports, which unavoidably will lead to a bit of fallout. My personal experience is that most C++-based ports compile fine with libc++ instead of libstdc++, except for a few that rely on internal libstdc++ details. However, -std=c++11 is *not* yet the default, and C++11 has different rules here and there, so some ports might fail to compile due to this. For some ports, too much hacking may be required to make them work with C++11. So in case of trouble, try removing -std=, or setting it to different values (c++0x, c++98, gnu++98, etc), to get the port to compile. Note the base system should have no problems with -std=c++11, so please continue to use the option in src.conf, and report any problems if you encounter them, so we can fix them. :-) -Dimitry Hello Dimitry, btw, see PR ports/181932. This is definitely NOT libc++ related. It came up since nearly all qt4-related clients (also kdelibs) fail and drop core on r255398 - they worked prior to the last update today. I tried recompiling qt4- and kdelibs4 to get my kdevelop environment as well as libreoffice back (the drop core, as well as firefox, out of the blue). I also tried compiling those ports without any settings of CXXFLAGS in /etc/src.conf, but it doens't help. I can not understand why two critical changes from different branches of the maintainig get the same time into the public (iconv/ports and libstdc++ vanishing). Maybe I'm wrong here, but after three days, two nights non-stop updating I'm through with this toy. signature.asc Description: PGP signature
Re: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
- Original Message - From: Jeremie Le Hen j...@freebsd.org On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? Errm, was there meant to be some content in your reply Jeremie, as it seems to be missing? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 10:05:55PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? Errm, was there meant to be some content in your reply Jeremie, as it seems to be missing? Indeed, probably a bad key combo in vi :). I'm reverting r253821 and r254753 (the second one was supposingly fixing the first one) and recompiling my kernel. I will let you know. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Call for FreeBSD 2013Q3 (July-September) Status Reports
Dear FreeBSD Community, Please note that the next submission date for the July to September Quarterly Status Reports is October 7th, 2013, less than a month away. They do not have to be very long -- basically they may be about anything that lets people know what is going on around the FreeBSD Project. Submission of reports is not restricted to committers: Anyone who is doing anything interesting and FreeBSD-related can (and therefore encouraged to) write one! The preferred and easiest submission method is to use the XML generator [1] with the result emailed as an attachment to us, that is, mont...@freebsd.org [2]. There is also an XML template [3] which can be filled out manually and attached if preferred. To enable compilation and publication of the Q3 report as soon as possible for the October 7th deadline, please be prompt with any report submissions you may have. We are looking forward to all of your 2013Q3 reports! Cheers, Gabor [1] http://www.freebsd.org/cgi/monthly.cgi [2] mailto:mont...@freebsd.org [3] http://www.freebsd.org/news/status/report-sample.xml ___ 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: Interesting panic from the Yahoo builder (10-current)
On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno sean_br...@yahoo.com wrote: Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin Can you please print the value of cnp-cn_nameiop (or, even better, the whole struct) before the panic? Thanks, Hrm ... tried to reproduce after recompiling the kernel (turning off KDB_UNATTENDED) and its not happening now. I'll keep an eye out for it. Sean signature.asc Description: This is a digitally signed message part
Re: Interesting panic from the Yahoo builder (10-current)
On Sun, Sep 8, 2013 at 4:27 PM, Sean Bruno sean_br...@yahoo.com wrote: On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno sean_br...@yahoo.com wrote: Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin Can you please print the value of cnp-cn_nameiop (or, even better, the whole struct) before the panic? Thanks, Hrm ... tried to reproduce after recompiling the kernel (turning off KDB_UNATTENDED) and its not happening now. I'll keep an eye out for it. Sean From a first look (even without the informations) it looks very strange that the assertion fails, NDINIT() is called just before namei() in order to initialize struct nameidata, and that's what almost every other filesystem do, so I'm surprised noone hit this problem before. A (relatively random) guess is that you might run on (some sort of) broken hardware. Thanks, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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
