Re: 13.0-CURRENT r356767 wanted ZFS
On Fri, 17 Jan 2020 at 17:24, Ben Woods wrote: > > On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote: > >> >> 13.0-CURRENT r356767 would not take NO for an answer, and kept up a >> loop >> >> until I gave up trying to use UFS. No big deal, seems to work fine... >> >> >> >> Clay >> > > It does seem like this could be related to my commit (see below). Although > I runtime tested installs with both ZFS and UFS options, so I’m surprised. > https://svnweb.freebsd.org/changeset/base/356758 > > I’ll try to have a look at it tonight. > > Regards, > Ben > Hi Clay, Thanks for reporting this issue. I was able to replicate it using bsdinstall on the latest snapshot ISO FreeBSD-13.0-CURRENT-amd64-20200116-r356767-disc1.iso. It turns out the commit that introduced the regression was r356740. I have submitted a fix for review here: https://reviews.freebsd.org/D23232 Regards, Ben -- From: Benjamin Woods woods...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?
As far as I can tell most/all developers have used sampling-based profiling for years (e.g. hwpmc on FreeBSD) and have not been using gprof-based profiling. Prompted by followup to a pkgbase tweak I committed relating to profiling libraries[1] I propose following Brooks' suggestion: * turn off the PROFILE option by default now, in advance of the FreeBSD 13 branch (WITH_PROFILE will remain available) * update the WITH_PROFILE description in src.conf(5) to mention that it's deprecated * remove support for WITH_PROFILE after FreeBSD 13 branches Any comments on this plan? Does anyone use the -pg compiler flag and the _p.a profiling library archives? [1] https://lists.freebsd.org/pipermail/svn-src-all/2020-January/192566.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't cross-compile HEAD
сб, 11 янв. 2020 г. в 08:06, Pavel Timofeev :
>
> пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev wrote:
> > >
> > > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > > >
> > > > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev
> > > > wrote:
> > > > >
> > > > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > > > >
> > > > > > Hello
> > > > > >
> > > > > > I'm trying to cross-compile HEAD r356551 for mips on my
> > > > > > FreeBSD-12.1 amd64.
> > > > > > I'm using mips-gcc6-6.5.0 and this
> > > > > > https://github.com/freebsd/freebsd-wifi-build nice project to build
> > > > > > image for my tl-wdr3600
> > > > > >
> > > > > > The error I'm getting is:
> > > > > > ...
> > > > > > ===> usr.sbin/fmtree (all)
> > > > > > ===> usr.bin/vi (all)
> > > > > > ===> usr.sbin/freebsd-update (all)
> > > > > > ===> usr.sbin/gpioctl (all)
> > > > > > ===> usr.sbin/inetd (all)
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In
> > > > > > function
> > > > > > 'getconfigent':
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> > > > > > warning: variable 'v4bind' set but not used
> > > > > > [-Wunused-but-set-variable]
> > > > > > int v4bind;
> > > > > > ^~
> > > > > > At top level:
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> > > > > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > > > > > static const char copyright[] =
> > > > > >^
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In
> > > > > > function 'setup':
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> > > > > > error: 'netid' may be used uninitialized in this function
> > > > > > [-Werror=maybe-uninitialized]
> > > > > > rpcb_set(sep->se_rpc_prog, i, netid, &nbuf);
> > > > > > ^~~
> > > > > > cc1: all warnings being treated as errors
> > > > > > --- inetd.o ---
> > > > > > *** [inetd.o] Error code 1
> > > > > >
> > > > > >
> > > > > > Could anybody please help fix that?
> > > > >
> > > > >
> > > > >
> > > > > Terribly sorry, I forgot to mention a very important detail.
> > > > > My src.conf has the only option now.
> > > > > It's WITHOUT_INET6="YES"
> > > >
> > > > Thanks for that addition- you saved me a little bit of effort
> > > > examining why it's unused. =-)
> > > >
> > > > The inetd build should be clear after r356602, but you'll need to
> > > > build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
> > > > some fundamental issues with mips-gcc{6,9} trying to emit
> > > > __floatunsidf references, but that's a hidden symbol in our libgcc.
> > > >
> > > > I expect to, by the end of the day, either have a fix pending or mark
> > > > it as a BROKEN_OPTION on mips+gcc while we hash out the details , as
> > > > gcc{6,9} is the only option we support for building mips at the
> > > > moment.
> > > >
> > > > Thanks,
> > > >
> > > > Kyle Evans
> > >
> > > Thanks a lot, Kyle!
> > > Build process passes further!
> > > Now I'm on r356606 and have these in src.conf
> > > WITHOUT_GOOGLETEST=yes
> > > WITHOUT_INET6="YES"
> > >
> > > Getting different error:
> > >
> >
> > I'm re-running the build WITHOUT_GOOGLETEST here outside of a
> > freebsd-wifi-build context, but CC'ing Adrian in case he's already
> > familiar since he's been battling libarchive stuff recently. Leaving
> > the context below intact in case he's not received this.
> >
> > > ===> usr.sbin/sendmail (all)
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:33:19:
> > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > > static const char copyright[] =
> > >^
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c: In function
> > > 'getname':
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:520:6:
> > > warning: variable 'ppp_state' might be clobbered by 'longjmp' or
> > > 'vfork' [-Wclobbered]
> > > int ppp_state = 0;
> > > ^
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:521:6:
> > > warning: variable 'ppp_connection' might be clobbered by 'longjmp' or
> > > 'vfork' [-Wclobbered]
> > > int ppp_connection = 0;
> > > ^~
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c: In function
> > > 'main':
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:183:6:
> > > warning: variable 'first_sleep' might be clobbered by 'longjmp' or
> > > 'vfork' [-Wclobbered]
> > > int first_sleep = 1, first_time = 1;
> > > ^~~
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:183:23:
> > > warning: variable 'first_time' might be clobbered by 'longjmp' or
> > > 'vfork' [-Wclobbered]
> > > int first_sleep = 1, first_time = 1;
> > >^~
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/init.c:36:
Re: Can't cross-compile HEAD
On 1/17/20, Pavel Timofeev wrote: > Rebuilding r356831 now > The error is : > > ===> libexec/rtld-elf (all) > > [15/1930] > /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf/rtld.c: In > function 'free_tls': > /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf/rtld.c:4925:24: > warning: variable 'tls_init_align' set but not used > [-Wunused-but-set-variable] > size_t dtvsize, i, tls_init_align; > ^~ > /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf/rtld.c: In > function 'do_dlsym': > /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf/rtld.c:3516:28: > warning: variable 'defobj' might be clobbered by 'longjmp' or 'vfork' > [-Wclobbered] > const Obj_Entry *obj, *defobj; > ^~ > /usr/home/pavel.timofeev/mips/head/lib/libc/gen/opendir.c: In function > 'is_unionstack': > /usr/home/pavel.timofeev/mips/head/lib/libc/gen/opendir.c:282:40: > error: macro "_fcntl" requires 3 arguments, but only 2 given > unionstack = _fcntl(fd, F_ISUNIONSTACK); > ^ > /usr/home/pavel.timofeev/mips/head/lib/libc/gen/opendir.c:282:13: > error: assignment makes integer from pointer without a cast > [-Werror=int-conversion] > unionstack = _fcntl(fd, F_ISUNIONSTACK); > ^ > cc1: all warnings being treated as errors > --- opendir.o --- > *** [opendir.o] Error code 1 > > make[4]: stopped in /usr/home/pavel.timofeev/mips/head/libexec/rtld-elf > 1 error > This one is mine. You are one revision short of the build fix in r356832 -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?
On Fri, Jan 17, 2020 at 10:40:09AM -0500, Ed Maste wrote: > > Any comments on this plan? Does anyone use the -pg compiler flag and > the _p.a profiling library archives? > Yes, I do. I have WITHOUT_PROFILE='yes' set in /etc/make.conf for a normal buildworld. I then comment it out and specifically build libc_p.a and libm_p.a. These are the only profiled libraries I use. Why? Because adding -pg to the gfortran command line is sufficient to getting profiling information for long running numerically intensive codes. 'gfortran -pg', of course, loosk for libc_p.a and libm_p.a. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?
On Fri, 17 Jan 2020 at 12:19, Steve Kargl wrote: > > Why? Because adding -pg to the gfortran command line is sufficient > to getting profiling information for long running numerically > intensive codes. 'gfortran -pg', of course, loosk for libc_p.a > and libm_p.a. Have you tried sampling-based profiling (i.e., hwpmc)? I'm curious if it provides equal utility for you, or if there's some shortcoming. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?
Ed Maste wrote: > Any comments on this plan? Does anyone use the -pg compiler flag and > the _p.a profiling library archives? We have teams that do - on a semi regular basis. If there's an alternate method to allow them to find hot-spots etc in userland code we can direct them accordingly I expect. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0-CURRENT r356767 wanted ZFS
Thanks, Ben. I'm fine with ZFS for this week. I got involved with a little project of my own on this weeks snapshot, and will see what next week brings. Clay On Fri, Jan 17, 2020 at 1:33 PM Ben Woods wrote: > On Fri, 17 Jan 2020 at 17:24, Ben Woods wrote: > >> > On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote: >> >>> >> 13.0-CURRENT r356767 would not take NO for an answer, and kept up a >>> loop >>> >> until I gave up trying to use UFS. No big deal, seems to work fine... >>> >> >>> >> Clay >>> >> >> It does seem like this could be related to my commit (see below). >> Although I runtime tested installs with both ZFS and UFS options, so I’m >> surprised. >> https://svnweb.freebsd.org/changeset/base/356758 >> >> I’ll try to have a look at it tonight. >> >> Regards, >> Ben >> > > Hi Clay, > > Thanks for reporting this issue. I was able to replicate it using > bsdinstall on the latest snapshot ISO > FreeBSD-13.0-CURRENT-amd64-20200116-r356767-disc1.iso. > > It turns out the commit that introduced the regression was r356740. > > I have submitted a fix for review here: > https://reviews.freebsd.org/D23232 > > Regards, > Ben > > -- > From: Benjamin Woods > woods...@gmail.com > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?
On Fri, Jan 17, 2020 at 01:12:32PM -0500, Ed Maste wrote: > On Fri, 17 Jan 2020 at 12:19, Steve Kargl > wrote: > > > > Why? Because adding -pg to the gfortran command line is sufficient > > to getting profiling information for long running numerically > > intensive codes. 'gfortran -pg', of course, loosk for libc_p.a > > and libm_p.a. > > Have you tried sampling-based profiling (i.e., hwpmc)? I'm curious if > it provides equal utility for you, or if there's some shortcoming. Never needed to try hwpmc. % gfortran9 -o z -pg fortran_file.f90 just works if libc_p.a and libm_p.a are present. There is a link-time failure if the libraries are missing. Here's an example of using -pg that found a bottleneck in my code (which I haven't profiled recently). Each sample counts as 0.000123062 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 46.80275.68 275.68 1178817696 0.00 0.00 __lum_MOD_cludet_dble 11.55343.7368.05 19458348 0.00 0.00 __sjnm_MOD_csjn_dble 7.09385.4741.73 19458348 0.00 0.00 __sphere_MOD_sphere_shell_formfcn 5.97420.6335.16 97291740 0.00 0.00 __sjnm_MOD_sjn_dble 3.84443.2422.61 23712564606 0.00 0.00 cabs (w_cabs.c:17 @ 4968f0) The cludet_dble() routine is a bottleneck, which makes heavy use of cabs(). It so happens that cludet_dble doesn't need to use cabs, and instead can look at the magnitude square. Replacing cabs(z) with creal(z)**2 + cimag(z)**2 gives Each sample counts as 0.000123062 seconds. % cumulative self self total 53.93232.70 232.70 1178817696 0.00 0.00 __lum_MOD_cludet_dble 15.84301.0268.32 19458348 0.00 0.00 __sjnm_MOD_csjn_dble 10.63346.9145.88 19458348 0.00 0.00 __sphere_MOD_sphere_shell_formfcn 7.84380.7133.81 97291740 0.00 0.00 __sjnm_MOD_sjn_dble Nominally, a 43 CPU seconds decrease. That 43 seconds accumulates quickly, when the code is executed a few thousand times for Monte Carlo simulations. Is there a trivially stupid way of using hwpmc that requires no changes to fortran_file.f90? PS: For those snickering about the word Fortran. Go read the Fortran 2018 standard and educate yourselves. You want document 007 from https://j3-fortran.org/doc/standing. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0-CURRENT r356767 wanted ZFS
On Sat, 18 Jan 2020 at 05:06, Clay Daniels wrote: > Thanks, Ben. I'm fine with ZFS for this week. I got involved with a little > project of my own on this weeks snapshot, and will see what next week > brings. > > Clay > This has been fixed in r356855, and the next CURRENT snapshot should include this fix. https://svnweb.freebsd.org/changeset/base/356855 Regards, Ben -- From: Benjamin Woods woods...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
