Optimization bug with floating-point?
All,
There seems to an optimization bug with clang on
% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386
IOW, if you do numerica work on i386, you may want to check your
results.
The program demonstrating the issue is at the end of this email.
gcc8 --version
gcc8 (FreeBSD Ports Collection) 8.3.0
gcc8 -fno-builtin -o z a.c -lm && ./z
gcc8 -O -fno-builtin -o z a.c -lm && ./z
gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
Max ULP: 2.297073
Count: 0 (# of ULP that exceed 21)
cc --version
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250)
(based on LLVM 7.0.1)
Target: i386-unknown-freebsd13.0
cc -fno-builtin -o z a.c -lm && ./z
Max ULP: 2.297073
Count: 0
cc -O -fno-builtin -o z a.c -lm && ./z
cc -O2 -fno-builtin -o z a.c -lm && ./z
cc -O3 -fno-builtin -o z a.c -lm && ./z
ur ui: 21.588761 7.006300
x y: 9.5623927 1.4993777
csinhf: 5.07348328e+02 7.09178613e+03
dp_csinh: 5.07348986e+02 7.09178955e+03
sinhf: 7.10991113e+03
cosf: 7.13578984e-02
Max ULP: 23.061242
Count: 39 (# of ULP that exceeds 21)
Things are much worse than this toy program shows.
My test program used in development of libm is giving
Restrict x < 10
./testf -u -X 10
Max ULP Re: 136628.340239
Max ULP Im: 1891176.003955
Restrict c < 50
./testf -u -X 10
Max ULP Re: 3615923.332529
Max ULP Im: 13677733.591783
/*
* Compute 1 million valus of csinhf() and then compute the ULP for
* for the real and imaginary parts.
*/
#include
#include
#include
#include
#include
#include
/* Return 0 <= x < 1. */
double
ranged(void)
{
union {
double x;
struct {
uint32_t lo;
uint32_t hi;
} u;
} v;
v.u.hi = (uint32_t)random();
v.u.hi = ((v.u.hi << 11) >> 11) | 0x3ff0;
v.u.lo = (uint32_t)random();
return (v.x - 1);
}
float
rangef(void)
{
float s;
s = (float)ranged();
return (s);
}
/* Double precision csinh() without using C's double complex.s */
void
dp_csinh(double x, double y, double *re, double *im)
{
double c, s;
sincos(y, &s, &c);
*re = sinh(x) * c;
*im = cosh(x) * s;
}
/* ULP estimate. */
double
ulpfd(float app, double acc)
{
int n;
double f;
f = frexp(acc, &n);
f = fabs(acc - app);
f = ldexp(f, FLT_MANT_DIG - n);
return (f);
}
int
main(void)
{
double re, im, u, ur, ui;
float complex f;
float x, y;
int cnt, i;
srandom(19632019);
ur = ui = 0;
for (cnt = 0, i = 0; i < 1000; i++) {
x = rangef() + 9;
y = rangef() + 0.5;
f = csinhf(CMPLXF(x,y));
dp_csinh((double)x, (double)y, &re, &im);
ur = ulpfd(crealf(f), re);
if (ur > u) u = ur;
ui = ulpfd(cimagf(f), im);
if (ui > u) u = ui;
if (ur > 21 || ui > 21) {
printf(" ur ui: %f %f\n", ur, ui);
printf(" x y: %.7f %.7f\n", x, y);
printf(" csinhf: %.8e %.8e\n", crealf(f), cimagf(f));
printf("dp_csinh: %.8le %.8le\n", re, im);
printf(" sinhf: %.8e\n", sinhf(x));
printf("cosf: %.8e\n\n", cosf(y));
cnt++;
}
}
printf("Max ULP: %f\n", u);
printf("Count: %d\n", cnt);
return (0);
}
--
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: kqueue send over unix socket?
Hi!
I am trying exactly that.
dtrace output gives following
# dtrace -s sendmsg.d -p 61387
dtrace: script 'sendmsg.d' matched 30667 probes
CPU IDFUNCTION:NAME
0 16637 uipc_send:return
kernel`sosend_generic+0x556
kernel`kern_sendit+0x296
kernel`sendit+0x19e
kernel`sys_sendmsg+0x61
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
0 35794sosend_generic:return
kernel`kern_sendit+0x296
kernel`sendit+0x19e
kernel`sys_sendmsg+0x61
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
0 32432 kern_sendit:return
kernel`sendit+0x19e
kernel`sys_sendmsg+0x61
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
0 55533 free:return
kernel`sendit+0x1b0
kernel`sys_sendmsg+0x61
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
0 16604sendit:return
kernel`sys_sendmsg+0x61
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
0 30776 sys_sendmsg:return
kernel`amd64_syscall+0xa38
kernel`0x80f5891d
> On 12 March 2019 23:37 Alan Somers wrote:
>
>
> Is he trying to send the kqueue file descriptor itself using sendmsg
> with SCM_RIGHTS? It sounds like kqueues cannot be sent over unix
> sockets; not every file type necessarily can. But if you want to know
> the nitty-gritty details, just run this:
> dtrace -i 'fbt:::return /arg1 == 45/ {stack();}' -c "my_program
> my_options" and that will usually tell you the exact function that set
> the error.
>
> If the output is too large, then you can filter it by writing a D
> program like this:
>
> #sendmsg.d
> fbt:kernel:sys_sendmsg:entry
> {
> this->trigger = 1;
> }
> fbt:::return
> / this->trigger == 1 && arg1 == 45 /
> {
> stack();
> }
> fbt:kernel:sys_sendmsg:return
> {
> this->trigger = 0;
> }
>
> dtrace -s sendmsg.d -c "my_program my_options"
>
> Hope that helps.
> -Alan
>
> On Tue, Mar 12, 2019 at 3:22 PM Larry Rosenman wrote:
> >
> > I'm working with Aki Tuomi of Dovecot and he asks:
> >
> > I tried to ask if you could ask from some Kernel hacker why I cannot
> > send kqueue() fd over unix socket, I get "Operation not supported".
> >
> > Can anyone help me?
> >
> >
> >
> > --
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> > ___
> > 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"
___
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: kqueue send over unix socket?
On Tue, Mar 12, 2019 at 04:10:19PM -0500, Larry Rosenman wrote: > I'm working with Aki Tuomi of Dovecot and he asks: > > I tried to ask if you could ask from some Kernel hacker why I cannot > send kqueue() fd over unix socket, I get "Operation not supported". > > Can anyone help me? What exactly do you want to know? Events registered on a kqueue may contain state associated with the process that registered them. For example, the identifier for some events is a file descriptor, but different processes generally don't share their file descriptor tables. Note that kqueue descriptors are not inherited by the child of a fork() either. ___ 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: kqueue send over unix socket?
On Tue, Mar 12, 2019 at 04:10:19PM -0500, Larry Rosenman wrote: > I'm working with Aki Tuomi of Dovecot and he asks: > > I tried to ask if you could ask from some Kernel hacker why I cannot > send kqueue() fd over unix socket, I get "Operation not supported". Right, because sending kqfd to other process does not make sense. For the same reason kqueue filedescriptors are closed on fork. Issue is that kqueue operates on file descriptors, it stores events and names them by fd you use for registration. So all registered events names become meaningless when process operates on different file descriptor table, which happens after fork() or if kqfd is passed over unix socket to other process. Technically this occurs because kqueue file ops structure does not specify DFLAG_PASSABLE. > > Can anyone help me? > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 > ___ > 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" ___ 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: kqueue send over unix socket?
Is he trying to send the kqueue file descriptor itself using sendmsg
with SCM_RIGHTS? It sounds like kqueues cannot be sent over unix
sockets; not every file type necessarily can. But if you want to know
the nitty-gritty details, just run this:
dtrace -i 'fbt:::return /arg1 == 45/ {stack();}' -c "my_program
my_options" and that will usually tell you the exact function that set
the error.
If the output is too large, then you can filter it by writing a D
program like this:
#sendmsg.d
fbt:kernel:sys_sendmsg:entry
{
this->trigger = 1;
}
fbt:::return
/ this->trigger == 1 && arg1 == 45 /
{
stack();
}
fbt:kernel:sys_sendmsg:return
{
this->trigger = 0;
}
dtrace -s sendmsg.d -c "my_program my_options"
Hope that helps.
-Alan
On Tue, Mar 12, 2019 at 3:22 PM Larry Rosenman wrote:
>
> I'm working with Aki Tuomi of Dovecot and he asks:
>
> I tried to ask if you could ask from some Kernel hacker why I cannot
> send kqueue() fd over unix socket, I get "Operation not supported".
>
> Can anyone help me?
>
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> ___
> 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"
___
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"
kqueue send over unix socket?
I'm working with Aki Tuomi of Dovecot and he asks: I tried to ask if you could ask from some Kernel hacker why I cannot send kqueue() fd over unix socket, I get "Operation not supported". Can anyone help me? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: ZFS no longer mounted in alphanumerical order
On Tue, Mar 12, 2019 at 4:56 PM Andriy Gapon wrote: > > Valid point. So how do I control the order of mounts of zfs? > > If you really want / need / have to do it, then disable ZFS auto mounting > in one > of multiple ways (zfs_enable="NO", canmount=noauto, mountpoint=legacy) and > use > your own script or fstab to mount ZFS filesystems. > > Personally, I do not see any reason to do that as long as all my ZFS > filesystems > are properly mounted at expected mount points. > Maybe there some method of disabling the parallel mounting for those of us who prefer and expect a bit more symmetry from the output and who don't find much value in that feature. -- Adam ___ 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: ZFS no longer mounted in alphanumerical order
On 12/03/2019 18:40, Rodney W. Grimes wrote: >> On 12/03/2019 11:37, Trond Endrest?l wrote: >>> # Parallel mounting of ZFS filesystems leaves a chaotic listing of >>> # mounted filesystems when viewed by df(1). >> >> df reports filesystems in the order they were mounted. >> If you unmount and remount a filesystem or mount a new filesystem, you can >> see >> it for yourself. Also, if you ever used fstab then you could see that too. >> Just because previously the output happened to look like it was sorted does >> not >> mean that it was or that there was such an intention. > > Valid point. So how do I control the order of mounts of zfs? If you really want / need / have to do it, then disable ZFS auto mounting in one of multiple ways (zfs_enable="NO", canmount=noauto, mountpoint=legacy) and use your own script or fstab to mount ZFS filesystems. Personally, I do not see any reason to do that as long as all my ZFS filesystems are properly mounted at expected mount points. -- Andriy Gapon ___ 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: ZFS no longer mounted in alphanumerical order
On 12/03/2019 18:33, Rodney W. Grimes wrote: >> On 12/03/2019 02:12, Rodney W. Grimes wrote: >>> Perhaps make zfs list -s mountpoint a default? >> >> Why? > > P O L A People have become use to this being sorted, now it is not. Your suggestion would be a POLA violation. Nothing changed with respect to zfs list command. I am not even sure why it was brought up in this thread. -- Andriy Gapon ___ 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: ZFS no longer mounted in alphanumerical order
> On 12/03/2019 11:37, Trond Endrest?l wrote: > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of > > # mounted filesystems when viewed by df(1). > > df reports filesystems in the order they were mounted. > If you unmount and remount a filesystem or mount a new filesystem, you can see > it for yourself. Also, if you ever used fstab then you could see that too. > Just because previously the output happened to look like it was sorted does > not > mean that it was or that there was such an intention. Valid point. So how do I control the order of mounts of zfs? -- Rod Grimes rgri...@freebsd.org ___ 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: ZFS no longer mounted in alphanumerical order
> On 12/03/2019 02:12, Rodney W. Grimes wrote: > >> On 11/03/2019 23:03, Freddie Cash wrote: > >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things > >>> that list the mounted filesystems to use sorted output? > >> > >> | sort [desired options] > > > > Except that df and zfs list have a header that you have to deal with, > > which is not so easy to get sort to do the right things with out > > some hoop jumping. > > Like "| tail +2" ? > Or if it's just for visual inspection (as seems to be the case for the > original > poster) just mentally filter out that line. That just deletes the header. Try to write a one liner that gives you the exact same prior behavior. It is not really fair to make a change to the system that changes behavior and just tell all the users to adapt to the change, it makes FreeBSD "user unfriendly." If I have to adapt to much or too often I see alternatives. > >> P.S. > >> zfs list already supports sorting by a specific property. > > > > Perhaps make zfs list -s mountpoint a default? > > Why? P O L A People have become use to this being sorted, now it is not. > Andriy Gapon -- Rod Grimes rgri...@freebsd.org ___ 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: ZFS no longer mounted in alphanumerical order
> On 12 Mar 2019, at 12:14, Trond Endrestøl
> wrote:
>> An alternative sort approach, which handles df arguments which change the
>> number of columns, and only invokes df once:
>>
>> ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
>> /^Filesystem/ { print | sort }’
>
> Well, yes and no, mostly no.
>
> Why are we feeding each line from df(1) separately to sort(1)?
> It defeats the entire purpose. No sorting takes place.
>
> We might be better off accumulating the majority of the lines and
> sorting them in an END block.
That’s not how awk works. It maintains a pipe and feeds each line to the same
sort process.
There is another bug there, of course. The field number should be (NF - 1)
because of the space in the “Mounted on” header on the last column. That’s what
I get for just typing code into an email.
Regards,
Jan M.
___
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 13:27+0200, Andriy Gapon wrote: > On 12/03/2019 11:37, Trond Endrestøl wrote: > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of > > # mounted filesystems when viewed by df(1). > > df reports filesystems in the order they were mounted. > If you unmount and remount a filesystem or mount a new filesystem, you can see > it for yourself. Also, if you ever used fstab then you could see that too. > Just because previously the output happened to look like it was sorted does > not > mean that it was or that there was such an intention. I am aware of all of this. I was caught by surprise when my ZFS filesystems appeared partially ordered. I know that / and /dev are mounted by the kernel, and sometime later the remaining UFS/ZFS filesystems, and I also have a few synthetic filesystems mounted late in the boot process, and the latter ones (still) appear at the end of df(1)'s output. Order has somewhat been restored. Maybe it's no biggie. -- Trond. ___ 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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 12:14+0100, Trond Endrestøl wrote:
> On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
>
> > > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > > wrote:
> > > I concocted a shell script, it looks promising:
> > >
> > > #!/bin/sh
> > > #-
> > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > > # mounted filesystems when viewed by df(1).
> > > # Separating the header from the remaining lines and sorting the
> > > # latter before recombining is a viable solution.
> > > #-
> > >
> > > DF=/bin/df
> > >
> > > ${DF} ${@} | grep^Filesystem
> > > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> > >
> > > # new-df.sh
> >
> > An alternative sort approach, which handles df arguments which change the
> > number of columns, and only invokes df once:
> >
> > ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> > /^Filesystem/ { print | sort }’
>
> Well, yes and no, mostly no.
>
> Why are we feeding each line from df(1) separately to sort(1)?
> It defeats the entire purpose. No sorting takes place.
>
> We might be better off accumulating the majority of the lines and
> sorting them in an END block.
How about this?
/bin/df ${@} | /usr/bin/awk '/^Filesystem/ { print; sort = "/usr/bin/sort -sk "
NF-1 } ! /^Filesystem/ { if (length(acc) > 0) acc = acc "\n" $0; else acc = $0;
} END { print acc | sort }'
--
Trond.
___
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: ZFS no longer mounted in alphanumerical order
On 12/03/2019 11:37, Trond Endrestøl wrote: > # Parallel mounting of ZFS filesystems leaves a chaotic listing of > # mounted filesystems when viewed by df(1). df reports filesystems in the order they were mounted. If you unmount and remount a filesystem or mount a new filesystem, you can see it for yourself. Also, if you ever used fstab then you could see that too. Just because previously the output happened to look like it was sorted does not mean that it was or that there was such an intention. -- Andriy Gapon ___ 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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
> > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > wrote:
> > I concocted a shell script, it looks promising:
> >
> > #!/bin/sh
> > #-
> > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > # mounted filesystems when viewed by df(1).
> > # Separating the header from the remaining lines and sorting the
> > # latter before recombining is a viable solution.
> > #-
> >
> > DF=/bin/df
> >
> > ${DF} ${@} | grep^Filesystem
> > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> >
> > # new-df.sh
>
> An alternative sort approach, which handles df arguments which change the
> number of columns, and only invokes df once:
>
> ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> /^Filesystem/ { print | sort }’
Well, yes and no, mostly no.
Why are we feeding each line from df(1) separately to sort(1)?
It defeats the entire purpose. No sorting takes place.
We might be better off accumulating the majority of the lines and
sorting them in an END block.
--
Trond.
___
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"
FreeBSD CI Weekly Report 2019-03-10
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-03-10 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-02-03 to 2019-03-10. During this period, we have: * 1890 builds (95.6% passed, 4.4% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 358 test runs (49.2% passed, 50.5% unstable, 0.3% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 14 doc buils (100% passed) (For more meaningful statistics, we omitted the numbers from experimental jobs) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/s/rka6WQnIE and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## New Failed & Fixed jobs * armv6 build job was broken on the Clang 8 importing and was fixed by https://svnweb.freebsd.org/changeset/base/344798 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libarchive.functional_test.test_fuzz_zip (flakey) See https://bugs.freebsd.org/236300 for more details * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sbin.bectl.bectl_test.bectl_mount * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * sys.netpfil.pf.pass_block.noalias (new) See https://bugs.freebsd.org/233678 for more details * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) * lib.libc.sys.sendfile_test.fd_positive_shm_v4 (new) * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4 (new) ## Failing Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * common.rates.t_dtrace_contrib.tst_switchrate_d * common.syscall.t_dtrace_contrib.tst_args_d * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues ### New * Flakey test case: lib.libarchive.functional_test.test_fuzz_zip https://bugs.freebsd.org/236300 ### Cause build fails * [29: genassym.o build race](https://bugs.freebsd.org/29) * Patch available: https://people.freebsd.org/~bdrewery/patches/PR29.diff * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ## Other News * There is a traditional "tinderbox" view of the CI build status at http://tinderbox.freebsd.org (redirect to https://ci.freebsd.org/tinderbox/) ___ 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: ZFS no longer mounted in alphanumerical order
> On 12 Mar 2019, at 10:37, Trond Endrestøl
> wrote:
> I concocted a shell script, it looks promising:
>
> #!/bin/sh
> #-
> # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> # mounted filesystems when viewed by df(1).
> # Separating the header from the remaining lines and sorting the
> # latter before recombining is a viable solution.
> #-
>
> DF=/bin/df
>
> ${DF} ${@} | grep^Filesystem
> ${DF} ${@} | grep -v ^Filesystem | sort -k 6
>
> # new-df.sh
An alternative sort approach, which handles df arguments which change the
number of columns, and only invokes df once:
${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } ! /^Filesystem/
{ print | sort }’
Regards,
Jan.
___
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 08:54+0200, Andriy Gapon wrote:
> On 12/03/2019 02:12, Rodney W. Grimes wrote:
> >> On 11/03/2019 23:03, Freddie Cash wrote:
> >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things
> >>> that list the mounted filesystems to use sorted output?
> >>
> >> | sort [desired options]
> >
> > Except that df and zfs list have a header that you have to deal with,
> > which is not so easy to get sort to do the right things with out
> > some hoop jumping.
>
> Like "| tail +2" ?
> Or if it's just for visual inspection (as seems to be the case for the
> original
> poster) just mentally filter out that line.
>
> >> P.S.
> >> zfs list already supports sorting by a specific property.
> >
> > Perhaps make zfs list -s mountpoint a default?
>
> Why?
I concocted a shell script, it looks promising:
#!/bin/sh
#-
# Parallel mounting of ZFS filesystems leaves a chaotic listing of
# mounted filesystems when viewed by df(1).
# Separating the header from the remaining lines and sorting the
# latter before recombining is a viable solution.
#-
DF=/bin/df
${DF} ${@} | grep^Filesystem
${DF} ${@} | grep -v ^Filesystem | sort -k 6
# new-df.sh
--
Trond.
___
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"
