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 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
___
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 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 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 wrote:
> On 09/07/13 21:46, O. Hartmann wrote:
> > On Sat, 07 Sep 2013 14:27:48 +0200
> > Guido Falsi 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 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 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 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 wrote: > Wiadomość napisana przez Alfred Perlstein 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 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=revision&revision=253821 Might want to try back out that change and see if everything works after that? Regards Steve - Original Message - From: "Jeremie Le Hen" To: 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=revision&revision=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 wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > 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 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 wrote: > On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: >> Glen Barber 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" 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=revision&revision=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=revision&revision=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 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 proce
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 wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > 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" 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=revision&revision=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=revision&revision=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 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 wrote: > On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: >> On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno 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"
Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
Am 08.09.2013 08:14, schrieb O. Hartmann: > 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. There are ports that use bsd.prog.mk instead of the Makefile supplied with the source files. Just grep for bsd.port.mk in the port's "files" sub directory, if you find that /etc/src.conf settings affect a port. I think these ports are in violation of POLA and had a longer mail exchange with a port maintainer, who told me that use of bsd.prog.mk was the preferred method to build binaries on FreeBSD, for base and for ports. So no file under /usr/ports/Mk is to blame, but some ports do implicitly reference /etc/src.conf via their use of bsd.prog.mk. Regards, STefan NB: I just performed the grep suggested above and found that the following ports mention bsd.prog.mk in files/*: archivers/parchive archivers/pixz archivers/zipmix audio/id3v2 audio/mp3gain benchmarks/raidtest comms/mlan comms/mlan3 comms/obexapp converters/chmview converters/iconv devel/bcc devel/calibrator devel/frink devel/libpasori devel/linux_kdump devel/opencvs devel/qmake devel/qmake4 devel/ruby-byaccr dns/dnsreflector editors/fb editors/hexpert editors/tamago editors/tweak emulators/cpmtools finance/libstocks ftp/bsdftpd-ssl ftp/ftpsesame games/cre games/xroach graphics/exiftran graphics/s10sh japanese/edyvalue japanese/kon2-16dot japanese/man japanese/suicavalue mail/althea mail/archivesmtp mail/biffer mail/dma math/moo misc/cpuid misc/team net-mgmt/choparp net-mgmt/icmpquery net-mgmt/ipv6mon net/ifdepd net/openntpd net/packetdrill net/pcnfsd net/pppd23 net/pxe-pdhcp net/sharity-light net/skyfish palm/mdbconv print/epsonepl print/mup security/ipv6toolkit security/isakmpd security/openssh-askpass security/sst shells/nologinmsg shells/v7sh sysutils/bsdmoted sysutils/freqsdwn sysutils/jfbterm sysutils/sb16config sysutils/sbniconfig sysutils/setquota textproc/hhm textproc/wordnet www/http_get www/http_load www/http_post www/mathopd www/mohawk x11-wm/vtwm x11/gpctool x11/wmxss ___ 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"
