Re: newfs silently fails if random is not ready (?)

2018-09-04 Thread Xin Li

On 9/4/18 21:39, Conrad Meyer wrote:
> With current libc, I instead see:
> 
> load: 0.10  cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s
> 0% 2328k (SIGINFO)
> 
> $ procstat -kk 1668
>   PIDTID COMMTDNAME  KSTACK
>  1668 100609 blocked_random_poc  -   mi_switch+0xd3
> sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272
> read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940
> fast_syscall_common+0x101
> 
> and:
> 
> $ truss ./blocked_random_poc
> ...
> getrandom(0x7fffd340,40,0)   ERR#35 'Resource
> temporarily unavailable'
> thr_self(0x7fffd310) = 0 (0x0)
> thr_kill(100609,SIGKILL) = 0 (0x0)
> SIGNAL 9 (SIGKILL) code=SI_NOINFO
> 
> So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN
> after we have already slept until random was seeded.  This bubbles up
> to getentropy(3) -> arc4random(3), which sees a surprising failure
> from getentropy(3) and raises KILL against the program.
> 
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition.  This may be sufficient to fix the problem:
> 
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
> error = tsleep(_alg_context, PCATCH, "randseed", 
> hz/10);
> if (error == ERESTART || error == EINTR)
> break;
> +   /* Squash hz/10 timeout condition */
> +   if (error == EWOULDBLOCK)
> +   error = 0;
> +   KASSERT(error == 0, ("unexpected %d", error));
> }
> if (error == 0) {
> read_rate_increment((uio->uio_resid +
> sizeof(uint32_t))/sizeof(uint32_t));

+markm, re

I think the proposed change is reasonable (note that I think the same
theory applies to the tsleep_sbt() case below as well, which should be
handled similarly).

> Best,
> Conrad
> 
> 
> On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer  wrote:
>> Hi Lev,
>>
>> I took a first attempt at reproducing this problem on a fast
>> desktop-class system.  First steps, give us a way to revert back to
>> unseeded status:
>>
>> --- a/sys/dev/random/fortuna.c
>> +++ b/sys/dev/random/fortuna.c
>> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>>
>>  #ifdef _KERNEL
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>> return;
>> }
>>
>> +   /*
>> +* When set, pretend we do not have enough entropy to reseed yet.
>> +*/
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
>> +   if (RETURN_VALUE != 0) {
>> +   RANDOM_RESEED_UNLOCK();
>> +   return;
>> +   }
>> +   });
>> +
>> +
>>  #ifdef _KERNEL
>> fortuna_state.fs_lasttime = now;
>>  #endif
>> @@ -442,5 +454,11 @@ bool
>>  random_fortuna_seeded(void)
>>  {
>>
>> +   /* When set, act as if we are not seeded. */
>> +   KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
>> +   if (RETURN_VALUE != 0)
>> +   fortuna_state.fs_counter = UINT128_ZERO;
>> +   });
>> +
>> return (!uint128_is_zero(fortuna_state.fs_counter));
>>  }
>>
>>
>> Second step, enable the failpoints and launch repro program:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
>> debug.fail_point.random_fortuna_pre_read: off -> return(1)
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
>> debug.fail_point.random_fortuna_seeded: off -> return(1)
>>
>> $ cat ./blocked_random_poc.c
>> #include 
>> #include 
>> #include 
>>
>> int
>> main(int argc, char **argv)
>> {
>> printf("%x\n", arc4random());
>> return (0);
>> }
>>
>>
>> $ ./blocked_random_poc
>> ...
>>
>>
>> Third step, I looked at what that process was doing:
>>
>> Curiously, it is not in getrandom() at all, but instead the ARND
>> sysctl fallback.  I probably need to rebuild world (libc) to test this
>> (new libc arc4random based on Chacha).
>>
>> $ procstat -kk 1196
>>   PIDTID COMMTDNAME  KSTACK
>>  1196 100435 blocked_random_poc  -   read_random+0x3d
>> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
>> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
>> amd64_syscall+0x940 fast_syscall_common+0x101
>>
>>
>> When I unblocked the failpoints, it completed successfully:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
>> debug.fail_point.random_fortuna_pre_read: return(1) -> off
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
>> debug.fail_point.random_fortuna_seeded: return(1) -> off
>>
>> ...
>> 9e5eb30f
>>
>>
>> Best,
>> Conrad




signature.asc
Description: OpenPGP digital signature


Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

2018-08-16 Thread Xin LI
On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
>
> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> > This was caused by r337852, but I didn't investigated further.
> >
> > The problem is that we have a source file called 'moduli.c' in
> > crypto/openssh/ while the build target was moduli, and bmake seen
> > 'moduli' in source tree as older than moduli.c, and decided to rebuild
> > it from source, while the two files are unrelated.
>
> Hi Xin,
>
> I don't see how that could be the case as I didn't move the file around, I 
> just moved how it gets installed.
>
> I have done many many builds with this change in and haven't seen this 
> problem..

Yeah, let me rephrase: this might have been exposed by r337852; I
don't think your change itself really caused or should have caused
problem, but my theory based on what we have observed was that it
might have exposed a bug where either bmake itself, or some .mk files
might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
(haven't traced that part down yet).

The most scaring part is that the build system seems to trying
building crypto/openssh/moduli because moduli.c was newer, and the
file was deleted as part of the rebuild; should moduli.c compile by
its own, we would end up with a binary moduli file.

I'll take another look tonight if I had some time.

>
>
> Regards,
> Brad Davis
>
> > On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  
> > wrote:
> > >
> > > Running:
> > >
> > > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> > > r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> > > amd64
> > >
> > > after updating working copy to r337903, I'm seeing:
> > >
> > > ...
> > > >>> stage 4.3: building everything
> > > ...
> > > --- ifconfig_make ---
> > > Building 
> > > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> > > --- all_subdir_secure ---
> > > --- moduli ---
> > > /usr/bin/ld: error: undefined symbol: main
> > > >>> referenced by crt1.c
> > > >>>   
> > > >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> > > /usr/bin/ld: error: undefined symbol: Fssh_error
> > > 
> > > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > > .ERROR_TARGET='moduli'
> > > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> > > .MAKE.LEVEL='5'
> > > MAKEFILE=''
> > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> > > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> > > --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> > > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> > > -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> > > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> > > -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> > > -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> > > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> > > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> > > -Wno-enum-conversion -Wno-unused-local-typedef 
> > > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
> > > -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments   
> > > -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> > > /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> > > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > > .MAKE='make'
> > > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> > > .TARGETS='all'
> > > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > > 
> > >
> > > (on both the laptop and the build machine).
> > >
> > > I have copied the .ERROR_META_FILE to
> > > <http://www.catwhisker.org/~david/FreeBSD/head/r337903/moduli.meta and
> > > a typescript of the attempted build to
> > > <http://www.catwhisker.org/~david/FreeBSD/head/r337903/typescript>.
> > >
> > > Additional information (previous day's verbose dmesg.bot, etc.) may
> > > be found at <http://www.catwhisker.org/~david/FreeBSD/history/>.
> > >
> > > Peace,
> > > david
> > > --
> > > David H. Wolfskill  da...@catwhisker.org
> > > Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
> > >
> > > See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

2018-08-16 Thread Xin LI
This was caused by r337852, but I didn't investigated further.

The problem is that we have a source file called 'moduli.c' in
crypto/openssh/ while the build target was moduli, and bmake seen
'moduli' in source tree as older than moduli.c, and decided to rebuild
it from source, while the two files are unrelated.

Cheers,
On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  wrote:
>
> Running:
>
> FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> after updating working copy to r337903, I'm seeing:
>
> ...
> >>> stage 4.3: building everything
> ...
> --- ifconfig_make ---
> Building 
> /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> --- all_subdir_secure ---
> --- moduli ---
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c
> >>>   
> >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> /usr/bin/ld: error: undefined symbol: Fssh_error
> 
> make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> .ERROR_TARGET='moduli'
> .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
> -Qunused-arguments   -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> .CURDIR='/usr/src/secure/usr.sbin/sshd'
> .MAKE='make'
> .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> .TARGETS='all'
> DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> 
>
> (on both the laptop and the build machine).
>
> I have copied the .ERROR_META_FILE to
>  a typescript of the attempted build to
> .
>
> Additional information (previous day's verbose dmesg.bot, etc.) may
> be found at .
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: post ino64: lockd no runs?

2017-06-12 Thread Xin LI
On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin  wrote:
> On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
>> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
>> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
>> > of my systems after a full rebuild of src and ports. No log entries
>> > offer any insight as to why :-(
>> >
>> > imb
>>
>> I don't tend to use NFS on my systems that are running head, so I
>> haven't had occasion to test this as stated.
>>
>> However, I just completed my weekly update of the "prooduction" systems
>> here at home, running stable/11.  And I find that lockd seems to be ...
>> claiming that all is well, but declining to run (for long).
>>
>> To the best of my knowledge, that was not the case until this last
>> update, which was from:
>>
>> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316  
>> r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> to
>>
>> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  
>> r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 
>> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
>>
>> The "glaringly obvious" symptom in my case is that I am now unable
>> to (directly) save an email message from within mutt(1) by appending
>> it to an NFS-resident file.  (Saving it to a local file, then using
>> cat(1) to append that to the NFS- resident file & removing the local
>> copy works)
>>
>> After a few variations on a theme of:
>>
>> albert(11.1)[5] sudo service lockd restart
>> lockd not running?
>> Starting lockd.
>> albert(11.1)[6] echo $?
>> 0
>> albert(11.1)[7] service lockd status
>> lockd is not running.
>>
>> I finally(!) thought to ask ktrace what's going on (as tailing
>> /var/log/messages was completely unproductive, even after enabling
>> rc_debug).
>>
>> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
>> the output of kdump(1), I see that the trace ends with:
>>
>>   ...
>>   2811 rpc.lockd NAMI  "/var/run/logpriv"
>>   2786 sh   CALL  read(0xa,0x627fc0,0x400)
>>   2786 sh   GIO   fd 10 read 0 bytes
>>""
>>   2811 rpc.lockd RET   connect 0
>>   2786 sh   RET   read 0
>>   2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
>>   2786 sh   CALL  exit(0)
>>   2811 rpc.lockd GIO   fd 3 wrote 39 bytes
>>"<30>Jun 11 15:43:10 rpc.lockd: Starting"
>>   2811 rpc.lockd RET   sendto 39/0x27
>>   2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
>>   2811 rpc.lockd RET   sigaction 0
>>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
>>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
>
> This is a really good clue.  nlm_syscall is dying with EFAULT.  The last
> argument is a pointer to an array of char * pointers, and the only way
> I can see it dying is if it fails to copyin() one of the strings pointed
> to by those pointers.  You could try running rpc.lockd under gdb from
> ports and setting a breakpoint on 'nlm_syscall' and then printing out
> 'addr_count' and 'p addrs@(addr_count * 2)'.

Yes, I found that the kernel was trying to copyin() from NULL, and
then found that corresponds to 'uaddr'.  After some tracing I found
that the tightened condition for taddr2uaddr have enforced (correctly)
buffer length passed from caller, which was not set correctly since ~9
years ago (r177633, which sets the size to sizeof(pointer)) but never
gets noticed because there is no check on that, so the solution seems
to be to correctly set the length values to (allocated size), and that
have fixed the issue for me.

The code could use some cleanups and I plan to do it at some later time.

> Unfortunately I'm not able to reproduce the failure on a test machine
> I have running head post-ino64.

This should have been fixed by r319852 in -HEAD (
https://svnweb.freebsd.org/base?view=revision=319852 ), and
I'll MFC the change after 3 days' settle  assuming there is no
objections, as this is a regression.

Cheers,
___
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: Build fails in libpcap with WITHOUT_INET6

2017-03-28 Thread Xin LI
Thanks for reporting.  I have applied a fix as r316125.

On Tue, Mar 28, 2017 at 9:31 AM, Randy Westlund  wrote:
> Building r315872 for the Tegra (arm/armv6) board with WITHOUT_INET6 set fails
> in libpcap:
>
>> --- klm_prot_xdr.pico ---
>> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs
>> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free
>> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O
>> -pipe   -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg
>> ra/freebsd/tmp/usr/include/rpcsvc -MD  -MF.depend.klm_prot_xdr.pico -MTklm_pr
>> ot_xdr.pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-
>> body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compar
>> e -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-
>> conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switc
>> h -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arg
>> uments  -c klm_prot_xdr.c -o klm_prot_xdr.pico
>> --- all_subdir_lib/libpcap ---
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:695:9: error: no memb
>> er named 'ai' in 'struct _compiler_state'
>> cstate.ai = NULL;
>> ~~ ^
>> --- all_subdir_lib/librpcsvc ---
>> --- mount_xdr.pico ---
>> cc -target armv6-gnueabihf-freebsd12.0 --sysroot=/usr/home/randy/tegra/freebs
>> d-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp -B/usr/home/randy/tegra/free
>> bsd-obj/arm.armv6/usr/home/randy/tegra/freebsd/tmp/usr/bin -fpic -DPIC -g -O
>> -pipe   -DYP -I/usr/home/randy/tegra/freebsd-obj/arm.armv6/usr/home/randy/teg
>> ra/freebsd/tmp/usr/include/rpcsvc -MD  -MF.depend.mount_xdr.pico -MTmount_xdr
>> .pico -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -
>> Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno
>> -unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conver
>> sion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno
>> -switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments
>>   -c mount_xdr.c -o mount_xdr.pico
>> --- all_subdir_lib/libpcap ---
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4916:13: error: use o
>> f undeclared identifier 'cstate'
>> bpf_error(cstate, "direction applied to 'gateway'");
>>   ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4923:11: error: use o
>> f undeclared identifier 'cstate'
>> switch (cstate->linktype) {
>> ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4961:17: error: use o
>> f undeclared identifier 'cstate'
>> b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR, Q_H
>> OST);
>>   ^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4963:19: error: use o
>> f undeclared identifier 'cstate'
>> tmp = gen_host(cstate, **alist++, 0x, proto,
>> Q_OR,
>>^
>> /usr/home/randy/tegra/freebsd/contrib/libpcap/gencode.c:4972:12: error: use o
>> f undeclared identifier 'cstate'
>> bpf_error(cstate, "illegal modifier of 'gateway'");
>>   ^
>> 6 errors generated.
>> *** [gencode.o] Error code 1
>>
>> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap
>> 1 error
>>
>> make[5]: stopped in /usr/home/randy/tegra/freebsd/lib/libpcap
>> *** [all_subdir_lib/libpcap] Error code 2
>
>
___
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: mlock and jail

2017-02-02 Thread Xin LI
On Thu, Feb 2, 2017 at 1:28 PM, Bruno Lauzé <brunola...@msn.com> wrote:
>
>
> But a simple user with no rights can mlock (64kb by default) why a jail would 
> not be able?
>

No, I'm not, by any means, arguing against having jailed processes
being able to mlock(), I'm just saying that we should have more fine
grained control over it (a knob to allow system administrators to
tweak it would be a good start).

Cheers,

>
> From: Xin LI<mailto:delp...@gmail.com>
> Sent: Thursday, February 2, 2017 1:13 PM
> To: Pavel Timofeev<mailto:tim...@gmail.com>
> Cc: Bruno Lauzé<mailto:brunola...@msn.com>; 
> freebsd-current<mailto:freebsd-current@freebsd.org>
> Subject: Re: mlock and jail
>
>
>
> On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote:
>> 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>:
>>> I like this idea.
>>>
>>> Note that potentially your patch would make it possible for a jailed
>>> root to DoS the whole system by locking too much of pages in memory.
>>> I think it would be sensible to provide a per-jail flag to enable
>>> doing it, or better, have some finer grained control (e.g. per jail
>>> quota of permitted locked pages).
>>>
>>> Why did the application want to lock pages in main memory, though?
>>
>> For example, this secret management tool
>> https://www.vaultproject.io/docs/config/ wants to lock memory for
>> security (surprise) reason.
>> It's available as security/vault in our ports tree.
>
> No it's not surprise but overkill IMHO.  Here is why:
>
> Locking memory does prevent swapping, but in a typical multi-user
> system, if an attacker is already able to read swap (keep in mind that
> disks are by default owned by root and can not be read in a typical
> setup), then the administrator already have much bigger problem to
> worry about, and the attacker would have much more powerful tools to
> steal the secrets.
>
> Additionally, if one really cares about safety of swap, they should
> have used encrypted swap in the first place.  On FreeBSD, appending
> '.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
> /dev/ada0p3.eli) would automatically do one-time keyed swapping.
>
> Moreover, I don't think it's a good idea to use an application that
> advocates locking all memory that it owns for "security" reasons: if
> the application writer does not know which memory pages would contain
> sensitive information, good chances that the application writer have
> no idea what is privilege separation and the design they have created
> could be fundamentally flawed.
>
> Cheers,
> ___
> 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: mlock and jail

2017-02-02 Thread Xin LI
On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote:
> 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>:
>> I like this idea.
>>
>> Note that potentially your patch would make it possible for a jailed
>> root to DoS the whole system by locking too much of pages in memory.
>> I think it would be sensible to provide a per-jail flag to enable
>> doing it, or better, have some finer grained control (e.g. per jail
>> quota of permitted locked pages).
>>
>> Why did the application want to lock pages in main memory, though?
>
> For example, this secret management tool
> https://www.vaultproject.io/docs/config/ wants to lock memory for
> security (surprise) reason.
> It's available as security/vault in our ports tree.

No it's not surprise but overkill IMHO.  Here is why:

Locking memory does prevent swapping, but in a typical multi-user
system, if an attacker is already able to read swap (keep in mind that
disks are by default owned by root and can not be read in a typical
setup), then the administrator already have much bigger problem to
worry about, and the attacker would have much more powerful tools to
steal the secrets.

Additionally, if one really cares about safety of swap, they should
have used encrypted swap in the first place.  On FreeBSD, appending
'.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
/dev/ada0p3.eli) would automatically do one-time keyed swapping.

Moreover, I don't think it's a good idea to use an application that
advocates locking all memory that it owns for "security" reasons: if
the application writer does not know which memory pages would contain
sensitive information, good chances that the application writer have
no idea what is privilege separation and the design they have created
could be fundamentally flawed.

Cheers,
___
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: mlock and jail

2017-02-01 Thread Xin LI
I like this idea.

Note that potentially your patch would make it possible for a jailed
root to DoS the whole system by locking too much of pages in memory.
I think it would be sensible to provide a per-jail flag to enable
doing it, or better, have some finer grained control (e.g. per jail
quota of permitted locked pages).

Why did the application want to lock pages in main memory, though?

On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé  wrote:
>
> I would like to ask if there is a reason I would have to applythe  patch 
> below to make an application work in a jail.
> And who's bad? the app too intrusive or the bsd not flexible enough 
> (allow.mlock?)
>
>
> Index: sys/kern/kern_jail.c
> ===
> --- sys/kern/kern_jail.c(revision 313033)
> +++ sys/kern/kern_jail.c(working copy)
> @@ -3340,6 +3340,11 @@
> case PRIV_PROC_SETLOGINCLASS:
> return (0);
>
>
> +case PRIV_VM_MADV_PROTECT:
> +case PRIV_VM_MLOCK:
> +case PRIV_VM_MUNLOCK:
> +return (0);
> +
> default:
>
>
> ___
> 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"

Panic with some recent changes (between r309016 and r309184)

2016-11-26 Thread Xin Li
Is this known?

The traceback:

panic: vm_page_assert_xbusied: page 0xf807fae225b0 not exclusive
busy @ /usr/src/sys/vm/vm_pager.c:263
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0a528ea620
vpanic() at vpanic+0x186/frame 0xfe0a528ea6a0
kassert_panic() at kassert_panic+0x126/frame 0xfe0a528ea710
vm_pager_assert_in() at vm_pager_assert_in+0x6f/frame 0xfe0a528ea740
vm_pager_get_pages_async() at vm_pager_get_pages_async+0x26/frame
0xfe0a528ea780
vn_sendfile() at vn_sendfile+0xc85/frame 0xfe0a528ea9e0
sys_sendfile() at sys_sendfile+0x11a/frame 0xfe0a528eaa70
amd64_syscall() at amd64_syscall+0x2f9/frame 0xfe0a528eabf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0a528eabf0
--- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x8040eb47a, rsp =
0x7fffea58, rbp = 0x7fffeb00 ---
KDB: enter: panic


Cheers,



signature.asc
Description: OpenPGP digital signature


EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

2016-07-31 Thread Xin Li
Hi,

I finally got some time to explore the UEFI boot process (kudos to
everyone who made this work!) and getting myself familiarize with the
basics.

One quick question -- Is there some technical restriction that prevents
us from merging boot1.efi and loader.efi into one binary?

Cheers,



signature.asc
Description: OpenPGP digital signature


Re: FreeBSD_HEAD_i386 - Build #3460 - Failure

2016-06-26 Thread Xin Li
My bad.  Proposed fix would be:

Index: lib/libmagic/Makefile
===
--- lib/libmagic/Makefile   (revision 302221)
+++ lib/libmagic/Makefile   (working copy)
@@ -19,7 +19,7 @@ INCS= magic.h
 MAGICPATH?=/usr/share/misc

 CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DHAVE_CONFIG_H
-CFLAGS+= -I${.CURDIR} -I${CONTRDIR}/src
+CFLAGS+= -I${.CURDIR} -I${.OBJDIR} -I${CONTRDIR}/src

 WARNS?=3

@@ -40,8 +40,8 @@ magic.mgc: mkmagic magic

 CLEANFILES+=   mkmagic
 build-tools: mkmagic
-mkmagic: apprentice.c cdf_time.c encoding.c funcs.c magic.c print.c
${BUILD_TOOLS_META}
-   ${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC} \
+mkmagic: apprentice.c cdf_time.c encoding.c funcs.c magic.c print.c
${INCS} ${BUILD_TOOLS_META}
+   ${CC} ${CFLAGS} -DCOMPILE_ONLY ${LDFLAGS} -o ${.TARGET} ${.ALLSRC:N*.h} 
\
${LDADD}

 FILEVER!= awk '$$1 == "\#define" && $$2 == "VERSION" { print $$3; exit }' \

Cheers,



signature.asc
Description: OpenPGP digital signature


Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

2016-06-09 Thread Xin Li


On 6/8/16 23:10, Craig Rodrigues wrote:
> Hi,
> 
> I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> current.
> 
> In latest current, it should be possible to put in /etc/rc.conf:
> 
> nis_ypldap_enable="YES"
> to activate the ypldap daemon.
> 
> When set up properly, it should be possible to log into FreeBSD, and have
> the backend password database come from an LDAP database such
> as OpenLDAP
> 
> There is some documentation for setting this up, but it is OpenBSD specific:
> 
> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> http://puffysecurity.com/wiki/ypldap.html#2
> 
> I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> information
> does not apply.  I figure that openldap from ports should work fine.
> 
> I was wondering if there is someone out there familiar enough with LDAP
> and has a setup they can test this stuff out with, provide feedback, and
> help
> improve the documentation for FreeBSD?

Looks like it would be a fun weekend project.  I've cc'ed a potential
person who may be interested in this as well.

But will this worth the effort? (I think the current implementation
would do everything with plaintext protocol over wire, so while it
extends life for legacy applications that are still using NIS/YP, it
doesn't seem to be something that we should recommend end user to use?)

> I would also be interested in hearing from someone who can see if
> ypldap can work against a Microsoft Active Directory setup?

Cheers,



signature.asc
Description: OpenPGP digital signature


Re: [zfs] Cache on SD stops working after updating to 11-CURRENT r291458 amd64

2016-01-09 Thread Xin Li
Please subscribe:

https://bugs.freebsd.org/205882

You can locally apply -r292066 or modify the code to skip the check when
pguid is 0 as a stopgap.

Cheers,



signature.asc
Description: OpenPGP digital signature


HEADSUP: Memory corruption issue with ZFS users using L2ARC [Fwd: svn commit: r287283 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]

2015-08-29 Thread Xin Li
Hi,

Please note that -CURRENT in revision range of [r286951, 287283),
approximately 9 days ago until now, are affected by a buffer overrun
issue that may cause data corruption (!) which may manifest itself as
random panics that relates to NULL pointer deference (e.g. Kernel Trap
12 with 4K fault address), or strange UMA related panics.

Systems that do not have L2ARC devices are not affected by this problem.
 The affected code is L2ARC specific.

For those who are using L2ARC devices -- it's not clear to me how bad
the corruption could affect the on disk data for ZFS.  If you are
running -CURRENT and have L2ARC, please be sure to examine if you have
any data loss.

Cheers,


 Forwarded Message 
Subject: svn commit: r287283 -
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Date: Sat, 29 Aug 2015 09:22:33 + (UTC)
From: Xin LI delp...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org

Author: delphij
Date: Sat Aug 29 09:22:32 2015
New Revision: 287283
URL: https://svnweb.freebsd.org/changeset/base/287283

Log:
  Fix a buffer overrun which may lead to data corruption, introduced in
  r286951 by reinstating changes in r274628.

  In l2arc_compress_buf(), we allocate a buffer to stash away the compressed
  data in 'cdata', allocated of l2hdr-b_asize bytes.

  We then ask zio_compress_data() to compress the buffer,
b_l1hdr.b_tmp_cdata,
  which is of l2hdr-b_asize bytes, and have the compressed size (or
original
  size, if compress didn't gain enough) stored in csize.

  To pad the buffer to fit the optimal write size, we round up the
compressed
  size to L2 device's vdev_ashift.

  Illumos code rounds up the size by at most SPA_MINBLOCKSIZE.  Because we
  know csize = b_asize, and b_asize is integer multiple of
SPA_MINBLOCKSIZE,
  we are guaranteed that the rounded up csize would be = b_asize. However,
  this is not necessarily true when we round up to 1  vdev_ashift, because
  it could be larger than SPA_MINBLOCKSIZE.

  So, in the worst case scenario, we are overwriting at most

(1  vdev_ashift - SPA_MINBLOCKSIZE)

  bytes of memory next to the compressed data buffer.

  Andriy's original change in r274628 reorganized the code a little bit,
  by moving the padding to after we determined that the compression was
  beneficial.  At which point, we would check rounded size against the
  allocated buffer size, and the buffer overrun would not be possible.

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c


Cheers,



signature.asc
Description: OpenPGP digital signature


Re: Read-only /usr/obj/ no longer kosher?

2015-08-25 Thread Xin Li
On 08/25/15 14:55, Pawel Jakub Dawidek wrote:
 Now that I think of it, it might have been that I did
 buildworld/buildkernel before -p1. Then freebsd-update updated
 newvers.sh and then I was trying to do installworld.
 
 Yes, I can now reproduce it with source updated to -p2.

Yes, that's because freebsd-version.sh is generated from the files (but
it's not clear to me whether if it's a bug or a feature that 'make
install' checks if it's up-to-date and decides to regenerate it...).

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die



signature.asc
Description: OpenPGP digital signature


Re: Read-only /usr/obj/ no longer kosher?

2015-08-23 Thread Xin Li


On 8/23/15 14:55, Pawel Jakub Dawidek wrote:
 I used to build world and kernel on one machine and export both /usr/src/ and
 /usr/obj read-only to other machines. It doesn't work anymore (this is from
 'make installworld'):
 
 === bin/freebsd-version (install)
 eval $(egrep '^(TYPE|REVISION|BRANCH)=' 
 /usr/src/bin/freebsd-version/../../sys/conf/newvers.sh) ;  if ! sed -e  
 s/@@TYPE@@/${TYPE}/g;  s/@@REVISION@@/${REVISION}/g;  
 s/@@BRANCH@@/${BRANCH}/g;   
 /usr/src/bin/freebsd-version/freebsd-version.sh.in freebsd-version.sh ; then 
  rm -f freebsd-version.sh ;  exit 1 ;  fi
 cannot create freebsd-version.sh: Permission denied
 rm: freebsd-version.sh: Read-only file system
 *** Error code 1

What's the modification times of
/usr/obj/usr/bin/freebsd-version/freebsd-version.sh,
/usr/src/bin/freebsd-version/freebsd-version.sh and
/usr/src/sys/conf/newvers.sh?

Cheers,



signature.asc
Description: OpenPGP digital signature


Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

2015-08-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/07/15 08:50, Jamie Landeg-Jones wrote:
 Xin Li delp...@delphij.net wrote:
 
 On 8/6/15 22:24, Kevin Oberman wrote:
 Or the code in portsnap could be modified to get the current 
 running version.
 
 I thought about this today but it won't work as advertised:
 someone (currently me) still have to tweak the portsnap builder
 configuration to announce new major version (9, 10, 11 now, and
 we would need 12 when 11.0-STABLE appears).  However,
 freebsd-update or mergemaster would take care for this.
 
 I was going to suggest this too. Isn't this information available 
 using /bin/freebsd-version -u ?

Client side: yes.

Server side: someone has to tell the server to start building for new
- -CURRENT or stop building for old -STABLE.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVxNcgAAoJEJW2GBstM+ns2HQP/iQfmSjJ853Aj4Bs+0qed7Ya
UoE4LDaX1PJSIpqswyWir34mSgqZ5jHC8wuEkNrT3dlXaSnuxBmjvZfm23T/AUFH
9b/ytjJGlZWT0Db88AOnIeiMKKKX786m9mkDxiY2C747Q0L+KqLzQx6Ltrgl7DEm
9arRlB3nQcix9u7badVgP+B3CRfspUwtqmL9m+4LFIlJQA3OPsMxySdKoJlCQD8H
E1rJNV/6NOxIIX2Y+/6EBhtNnhQwbXyKT74B/4UKFaGNaKfw7XIjB5T4yGBaWhPL
4VXqzDRU2g0YGY8VM3/uXA3AfSVuVYi9kmm2R3W/91TFwOVqGH31OQQczeK78Gpn
dx8+kOfC7OLGWaQ9Xb9H3bNcPUknRuUVusb4+Wbe8qXk5cWfeyIJLTK7GC4Vvq4i
dGf+rYpEMls/0t+W+6e1re+XTlZtgepLfWQMuuhCbOQf8egKktClbJ++Th6krc1B
Aob62BmfgNgq4mS8t21Ee2heBTTrjNwp+openjPv9+ffvhmDngshNrdp+z4umQ3G
uryURepM9YYmrRWVmD9ZOei81R2QIpzdFh/Xv4w8bwTAoiV3oJfNIavbJWuhsEsk
sAKU2Kk0oBiTDwOqe4ZEVfF1HWbOZe6X6gBWjwO0f/RG7Rtn9pexU9TRzBL1SmeE
qUix6Wbx6VfCB+7QiQgg
=LDxP
-END PGP SIGNATURE-
___
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: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

2015-08-06 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 8/6/15 22:24, Kevin Oberman wrote:
 Or the code in portsnap could be modified to get the current
 running version.

I thought about this today but it won't work as advertised: someone
(currently me) still have to tweak the portsnap builder configuration
to announce new major version (9, 10, 11 now, and we would need 12
when 11.0-STABLE appears).  However, freebsd-update or mergemaster
would take care for this.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVxEYEAAoJEJW2GBstM+ns6wkP/AoQS/GX6RfJ0r5KBzHJzo1Z
1sFGkqULBYbiS4DNV8Svt1+mMdg0IwK7t5vYhkiQI/RrkeddvU1btDiVPjNGbC3K
Wm5wKAD2uMRLczz9EhKCZehDRq88ckvUMefPdT5R3b+DTo4VKdCXoPC4AqZnu7bb
60wnOL6cyKw8fwKTHhVyui6zcbg9uj7VtGj9MGK+03jHDmekJ6sXZO/0fp/TGju6
ruPVf9yImi9o/T5IUaKlj2D3xfDtwEhjI7Q96K4C5y88Tl5+PXQBh/07SQOKIu59
nalLbAH8eoxITWEAOBFjM/e1KOLH5Hyk+TfR0GXDZVLyL4mi8eIpch0eLFHp3e94
PEbsE1lUN3R3/4IFTmPDj1WYF9dE/AUgV4gzQKBboieVYNLfuL/esI0VOCFa/3r3
3rSW9RAj8MOH3GA3un14eUrWg5prvDcjMq9cJUO5Pebc3cD0CxlKCJ+yNAMlTo4Q
07u8dxBXsZcO//xknW5Gx9rKl+fJxvwy2klLmsiR3+bM2PCd1bt4bvSkOTgv1ZOt
qJZ4g/sDpF2jx3UYj2PF5vnBLkI6RrWer379q8ZqAwVRGE4Z9glnzo9BNUpQoQDy
PXzf3Nsj/qWkvnXXIWxI71rLTsKNejiXpBiYYjZV2eYz9dCveNJEMRFmHQ+xthHz
VrdB3J9EBHa17p5Xlt2y
=nN8J
-END PGP SIGNATURE-
___
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


Proposal: make portsnap generate INDEX-${OSREL:R} only by default

2015-08-06 Thread Xin Li
Hi,

Currently the default portsnap.conf would generate INDEX-11, INDEX-10
and INDEX-9.  The INDEX file is only used for searching ports, and only
one (INDEX-${OSREL:R}) file is actually used.

Traditionally, we create all supported INDEX-* files by default, but the
only users who would benefit from this default are the ones who shares
ports tree across many systems that runs different FreeBSD releases.
 And even in these scenario, it's likely that they would still want to
tweak the configuration, as we may be creating more than needed INDEX-*
files.

So for simplicity and to reduce cycles wasted on everyone's system, I'd
propose the attached change to head/'s portsnap.conf and similar changes
to stable/9 and stable/10's portsnap.conf so that only INDEX-${OSREL:R}
is created by default.  Users who want additional INDEX files can
uncomment the corresponding lines.

Any objections/concerns?  I'll commit the change if no objection is
raised in a week.

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
Index: etc/portsnap.conf
===
--- etc/portsnap.conf	(revision 286392)
+++ etc/portsnap.conf	(working copy)
@@ -30,6 +30,6 @@
 # REFUSE korean polish portuguese russian ukrainian vietnamese
 
 # List of INDEX files to build and the DESCRIBE file to use for each
-INDEX INDEX-9 DESCRIBE.9
-INDEX INDEX-10 DESCRIBE.10
+#INDEX INDEX-9 DESCRIBE.9
+#INDEX INDEX-10 DESCRIBE.10
 INDEX INDEX-11 DESCRIBE.11


signature.asc
Description: OpenPGP digital signature


HEADSUP: password database format change [Was: svn commit: r283981 - head/usr.sbin/pwd_mkdb]

2015-06-04 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please be advised that the password database format have been changed
and no longer have legacy, endianness sensitive formatted entries, as
of r283981.

This change should not have any visible impact to current users other
than slightly smaller password databases, as the base system have been
changed to use the new, machine independent formatted entries more
than 12 years ago, and all modern FreeBSD releases have supported them
since 5.x time.

Old behavior can be restored by specifying '-l' from command line, if
desirable.  Please report any breakage as we currently plan to remove
the -l, -B and -L options from pwd_mkdb(8) in 12.0-RELEASE.

Cheers,


-  Forwarded Message 
Subject: svn commit: r283981 - head/usr.sbin/pwd_mkdb
Date: Thu, 4 Jun 2015 07:24:56 + (UTC)
From: Xin LI delp...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org

Author: delphij
Date: Thu Jun  4 07:24:56 2015
New Revision: 283981
URL: https://svnweb.freebsd.org/changeset/base/283981

Log:
  In r113596, version 4 of entries have been added but pwd_mkdb have
  been generating both new (machine independent) and legacy version
  entries (endianness sensitive).

  The base system have been using the new format for quite some time,
  so disable the generation by default.

  An interim option, -l, have been added to re-enable old behavior.
  The -l, -B and -L options are considered deprecated and will be
  removed in FreeBSD 12.0 release.

Modified:
  head/usr.sbin/pwd_mkdb/pwd_mkdb.8
  head/usr.sbin/pwd_mkdb/pwd_mkdb.c

Modified: head/usr.sbin/pwd_mkdb/pwd_mkdb.8

==
- --- head/usr.sbin/pwd_mkdb/pwd_mkdb.8 Thu Jun  4 06:30:39 2015
(r283980)
+++ head/usr.sbin/pwd_mkdb/pwd_mkdb.8   Thu Jun  4 07:24:56 2015
(r283981)
@@ -36,7 +36,7 @@
 .Nd generate the password databases
 .Sh SYNOPSIS
 .Nm
- -.Op Fl BCiLNp
+.Op Fl BCilLNp
 .Op Fl d Ar directory
 .Op Fl s Ar cachesize
 .Op Fl u Ar username
@@ -61,14 +61,10 @@ different from the historic Version 7 st
 .Pp
 The options are as follows:
 .Bl -tag -width flag
- -.It Fl B
- -Store data in big-endian format.
 .It Fl C
 Check if the password file is in the correct format.
 Do not
 change, add, or remove any files.
- -.It Fl L
- -Store data in little-endian format.
 .It Fl N
 Tell
 .Nm
@@ -116,6 +112,34 @@ encrypted password and the insecure vers
 The databases are used by the C library password routines (see
 .Xr getpwent 3 ) .
 .Pp
+By default,
+the
+.Nm
+utility generates new,
+machine independent format
+.Pq v4
+entries only.
+For compatibility with
+.Fx 5.0
+and earlier releases,
+the
+.Fl l
+option may be specified,
+which enables generation of legacy format
+.Pq v3
+entries.
+The legacy format entries are endianness dependent.
+.Pp
+The following options may be specified and will affect the
+generation of legacy entries.
+.Pp
+.Bl -tag -width flag
+.It Fl B
+Store data in big-endian format.
+.It Fl L
+Store data in little-endian format.
+.El
+.Pp
 The
 .Nm
 utility exits zero on success, non-zero on failure.

Modified: head/usr.sbin/pwd_mkdb/pwd_mkdb.c

==
- --- head/usr.sbin/pwd_mkdb/pwd_mkdb.c Thu Jun  4 06:30:39 2015
(r283980)
+++ head/usr.sbin/pwd_mkdb/pwd_mkdb.c   Thu Jun  4 07:24:56 2015
(r283981)
@@ -112,15 +112,15 @@ main(int argc, char *argv[])
char sbuf2[MAXPATHLEN];
char *username;
u_int method, methoduid;
- - int Cflag, dflag, iflag;
+   int Cflag, dflag, iflag, lflag;
int nblock = 0;

- - iflag = dflag = Cflag = 0;
+   iflag = dflag = Cflag = lflag = 0;
strcpy(prefix, _PATH_PWD);
makeold = 0;
username = NULL;
oldfp = NULL;
- - while ((ch = getopt(argc, argv, BCLNd:ips:u:v)) != -1)
+   while ((ch = getopt(argc, argv, BCLlNd:ips:u:v)) != -1)
switch(ch) {
case 'B':   /* big-endian output */
openinfo.lorder = BIG_ENDIAN;
@@ -128,6 +128,9 @@ main(int argc, char *argv[])
case 'C':   /* verify only */
Cflag = 1;
break;
+   case 'l':   /* generate legacy entries */
+   lflag = 1;
+   break;
case 'L':   /* little-endian output */
openinfo.lorder = LITTLE_ENDIAN;
break;
@@ -465,6 +468,7 @@ main(int argc, char *argv[])
error(put);
}

+   if (lflag) {
/* Create insecure data. (legacy version) */
p = buf;
COMPACT(pwd.pw_name);
@@ -555,6 +559,7

Re: What to do about RCS/OpenRCS

2015-05-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/07/15 12:09, Pedro Giffuni wrote:
 Hello;
 
 Some of you might recall that right before 10.0-Release there was a
 painful attempt to remove GNU RCS from the base system.
 
 From my point of view, the lessons learned from that were:
 
 -A lot more people than you might think find it useful to have a
 small version control system for thing like the files in /etc. 
 -Just removing features without a discussion is not wise. -IMHO,
 people wondering about the bloat in the OS should focus on other
 bigger VCS we carry, namely svn.
 
 For all I know, it looks like OpenRCS is the most viable option and
 can completely replace the old RCS we have in base.

I have objected this in 2013 because OpenRCS did not pass GNU RCS's
test suite:

https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185.
html

More specifically:

+ : -Dhas_conf_h
+ : cc
+ : diff
+ CL='cc -Dhas_conf_h  -o a.out'
+ L=''
+ RCSINIT=-x
+ export RCSINIT
+ SLASH=/
+ RCSfile=RCS/a.c
+ RCS_alt=RCS/a.d
+ lockfile=RCS/a._
+ q=-q
+ test -d RCS
+ rmdir=rmdir
+ mkdir RCS
+ rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._
+ echo 1.1
+ echo 1.1.1.1
+ echo 1.2
+ diff -c a.11 a.3x1
+ diff='diff -c'
+ rcs -i -L -ta.11 -q a.c
+ test -r RCS/a.c
+ rlog a.c
+ rm -f RCS/a.c
+ cp a.11 a.c
+ ci -ta.11 -mm -q a.c
+ test -r RCS/a.c
+ rcs -L -q a.c
+ test ! -f a.c
+ co -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ co -l -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ cp a.12 a.c
+ ci -mm -q a.c
+ co -q a.c
+ diff -c a.12 a.c
+ rm -f a.c
+ co -r1.1 -q a.c
+ diff -c a.11 a.c
+ rm -f a.c
+ cp a.3x1 a.c
+ ci -r1.1.1 -mm -q a.c
ci: RCS/a.c: no lock set by delphij
+ echo '#branches failed'
#branches failed
+ exit 1

The checkout as of today ported to FreeBSD still does not pass the
test cases, so I still object the replacement unless the issues have
been taken care of.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP
3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p
77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM
t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy
0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW
5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z
zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c
b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw
+cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu
2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu
QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj
VgaTuJMDK6pjCpTKfA/B
=di1X
-END PGP SIGNATURE-
___
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: backward dependencies on libzfs

2015-04-27 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/27/15 17:57, Craig Rodrigues wrote:
 On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon a...@freebsd.org
 wrote:
 
 
 I am not sure what's the best list to discuss this issue, so let
 me raise it here.
 
 It seems that libzfs_core can not be used without also linking /
 loading libzfs: /lib/libzfs_core.so.2: Undefined symbol
 zcmd_ioctl_compat
 
 The same is true for libnvpair but for a different reason (and it
 looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol
 aok
 
 Both dependencies seem to be backward, because: $ ldd
 /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 = /lib/libmd.so.6
 (0x801647000) libthr.so.3 = /lib/libthr.so.3 (0x801857000) 
 libumem.so.2 = /lib/libumem.so.2 (0x801a7c000) libutil.so.9 =
 /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 =
 /lib/libuutil.so.2 (0x801e8f000) libm.so.5 = /lib/libm.so.5
 (0x802098000) *libnvpair.so.2 = /lib/libnvpair.so.2
 (0x8022c1000)* libavl.so.2 = /lib/libavl.so.2 (0x8024d6000) 
 libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5
 = /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 =
 /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 = /lib/libc.so.7
 (0x80081f000) libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000)
 
 So, there are circular dependencies between libzfs and the other
 library in both cases. It seems that those dependencies do not
 cause much, if any trouble, in practice, but they are not nice,
 because they are unexpected and they are not present on other
 OpenZFS platforms.
 
 
 Fixes similar to this: 
 https://svnweb.freebsd.org/changeset/base/272484
 
 need to be done to plug these symbol dependency problems in the
 libraries.

Well I think it's different issue.  The backward dependency was
because of our libzfs_core depends on some compatibility shims (I
think it was introduced in r248445).  I don't have much time to work
on it right now though.

Andriy -- maybe file a bug and assign it to me?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVPt+QAAoJEJW2GBstM+ns5g8P/jchSVar1TjU2HoJymmthwPM
W5mwFSp0f0XWbtd2tkOSUHL6DGvV5pVpzhg3Oj20lrSGJv3s7tymffUSwBtKEA5q
fptapAeg/2hXT2U27ns0d5BgaoNz87y0BZgwcWrM4lsDOLpOLt++NPvqf5Jjoq18
y9cRvO06JCZV087Ou/mqU981b7f1T6T+eEUdGXGltP6uynF10HMAlwe53d4hJLgl
mhXvZcK78rjf8swtUCBzvkeTkB1OH/O1kL/w8p1oSTUbTERJneNFHEb1+o18XHsA
3aWrnDtweEDgK6mItK3HI26Rq1HvxdqbaYVnfmQikkufyamehzQofXb0AewJuRNf
EG4DYp1Y48USD2feQRF0an+lGcro6IQPv1GdKox2VdgR6lF0mOUPJr2TMvKNsumQ
4pxPNsM0b637YzL0mp/bt6t2C6YNaStn+PQ8gWCeOzBM2AJIUqliAP8eghEuAR2a
4kFGOOzLlzITdsg8Y7UNvTmiAMJVGm2XIwkOQA7pUR8LfkFeqyFqb846kR0HOK9w
Ce01BAsgM1OFgbo/WELd8ZTTrh+B2eV8dPJhPVEO1tmcniJoeUg3Qj76IPAK34U0
q5FTs5iaEWk2/N+jkd8kAGnZrHhVTLl88aEcdak+eyLj/VtUuvHakZckteDTlYak
k5ZJG2p/nxiY5NJPbDJJ
=tf6a
-END PGP SIGNATURE-
___
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: default pager (csh)

2015-02-20 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/20/15 18:05, Warren Block wrote:
 It doesn't do that on csh.  Or maybe I figured out how to prevent
 it long ago and forgot, but all I use is this:
 
 setenv  PAGER   less -RS
 
 
 You probably did what I used to do. Modify the termcaps/terminfo
 to eliminate this behavior. See Exorcising the Evil Alternate
 Screen.
 
 In the past, FreeBSD disabled this by default. It was changed
 several years ago, but you can change it back as per the aboved
 referenced article.
 
 I'm pretty sure I have not done that, it would show up in
 mergemaster. As far as I can remember, less(1) has never done that
 clear-the-screen thing on FreeBSD, which is why it is so jarring on
 Linux.

Not all terminals will clear screen...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIbBAEBCgAGBQJU5+32AAoJEJW2GBstM+nsZFQP+IoALzoaMRYF+jB9L1kwY+QN
h3mnx6BCjv24nMfnv/wLDvWXQ5N1DY0Di9/RP0YSFxgWetpxQGIf0fDOE2jYAbSW
+xPBMnYfkKWmzenF5W9NxMPi4o6ul/+LIkp1PxGpxHqjktkSFu3lnoeZaI0JB+6U
3XgpyLMsCfKPP1s5jOyn7TcIKQkby69ANUHWN+7Vfcrg7wy7h0cLmEuCfqOjMg0O
CczASshTkCH3JjdwENmT5hwxIKRRqLeqKLvGSyphcZ8FiOl8TKfY+Rnd7wxc9/Cf
/PU4cJFVIYw4v60hknD+Dj3hdgwJYA5pfJY2+8faC5V0qKpsDCnl43xDzKXojJjE
QX74k7fS47bwcAzTZMLD55X95mos6k7pkDdSE+FoEyWld+yCKxxnSGEXE+728xX2
zdpj1OlJLhyijcZXPNYbDmUVbGzjBnWSTcRF73+upeGDtG3Q1cKaCD7ZBx+Eyqq8
r0ILRrINPzW58XzK0i33obT4SqyBKnadCRuSADpKEaEZgjQeDEGhlQ83SBIt2xBr
rqofewSf3jPoN/o03vNaVMRfOT36NT65DOoCjIf0TuEpKbRhfYXb5LVAmt13Bhpv
Uc29/3uOi0r2A1h+2URZ0M5LBJo2NiaNgGRE+TTw4y/+mUwhbMvdOVuRwvYwGatb
2lI/u9fCHmNkyPWf5J8=
=+90O
-END PGP SIGNATURE-
___
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: default pager (csh)

2015-02-18 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/18/15 15:18, Davide Italiano wrote:
 Hi, one of the first things I do when I install FreeBSD is to
 switch the default PAGER from more(1) to less(1). This is
 particularly convenient, e.g. while using git diff, to show
 something more readable. Just out of curiosity, is there a reason
 why more(1) is still the default, and/or is this just historical?

The _only_ reason that I can think of is that more(1) does not clear
screen for certain terminals (done with 'ti' and 'te' sequences),
while less(1) when running as less does.

The less(1) behavior can be annoying to some people (sometimes even
myself when using less to show contents of a file and ^Z to paste
them), and unfortunately quite a few of them also happen to be the
more vocal ones when it comes to a change.

Other behavioral difference are trivial (or people care less to speak up).

I use less(1) instead of more(1) on all systems I have, so if some
brave soul wants to make the change I'd say just go for it! but
that's my $0.02 only.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJU5SMrAAoJEJW2GBstM+nsd7AQAJNJnZtu3YabP0wzbwZuhQHu
7BvG/RLEqUe6ZmR10pcxe/vr6W+d7HpRuBcF09MSclpijTie+w/5AmaP7NNCCrHc
+lAtUhGxGhloTmpkm3GhL94ai1AMoKSIwKgT2Onx76CWYXKfh2ycN4EDfAHUlenZ
4N+3NYua/20deTy0rji0HYMexN4/ZUApsiX9hLwj+mlVl/KVNLMh2OIoUpdbnfJi
MU9h+/WPZGBJeU4VQU3YO77sPm23EIzirFajM4Fqk6AZJp8ueHp5U0Bz1l98fBFZ
EUx2Bh4DLhn/+7AUlCiW3ByAwyaEzdjpeGwIT97hqHE+7r0Yuf69Sf1mdUcIbMNd
TOMo3oKTsVWtYkzB8DZAvGw6y73sLxm6KRwGYWoU3SIhIacU7zer5FC755pPGw3V
RqjBPu6nD8BCCXaBumiFtwrr88+vdDV6HfWRXfwSukT4sAYDAzjDEAhuY8kzDyWB
vW9KG5IqPrTXPabdAKEj8qpfZBbspYUT0jOPrnto9/S5pnxkXmtmTn/gfVELjblj
mLkJYPX9W25ziz3hI9t/wOp2Rl5GzBQdudIXpwD/06/L9h9X4CD38NdEQtJOOLyp
M4twYFkiFJZp64XhuwMJ4BGIunj4OsbDfmvZEbJJfV8Z2mgA0QbRvfZG7UqVThd0
MTHLk0J7hIunFwIdICpI
=whDB
-END PGP SIGNATURE-
___
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: tzsetup chroot

2015-02-03 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/03/15 17:05, Nick Frampton wrote:
 We have our own FreeBSD 10.1 installation script in which we call
 tzsetup.
 
 I'm seeing different behaviour in tzsetup between these two
 invocations:
 
 tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup
 
 With the -C option, no matter which time zone I select, it asks:
 
 Does the abbreviation 'UTC' look reasonable?
 
 Using chroot, I get the expected behaviour, e.g. selecting 
 America/New_York:
 
 Does the abbreviation 'EST' look reasonable?
 
 /mnt contains the contents of base.txz, so it looks like all the 
 zoneinfo files are there.

Could you please submit a bug ticket for this?

It looks like what happens is that tzsetup does not really do a
chroot(2) system call.  Instead, it simulated the effect by prefixing
all paths with the chroot environment.

The problem is that when tzsetup is going to verify your
configuration, it would use tzset(3), which does not respect the
simulated chroot effect.  When no zoneinfo data is present, everything
would be considered as UTC.

Attached is an dirty hack (ugly enough that I don't wish to commit)
that changes tzsetup to use chroot instead, which should fix the
problem.  I'm not very satisfied with it as it does chroot() before
doing init_dialog, which may well fail as the devfs is not necessarily
mounted in the chroot, and on the other hand all termcap related data
would be sourced from the chroot, which is probably an undesirable
side effect.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJU0X+zAAoJEJW2GBstM+nsfpwQAIwPBj11lzJS662RPBPQR6dB
vb3gCGJjqRANCD+Sr8EqxzPlKOcC4UiBB5Khy39lidC+d4qgGQ3Mz3qIwjCdl3Aw
KUzkFfhvspGzE25tIwsPJ3A00NjXNJGqGqcDMitfls4SdYZWzCgs+gwa3zGq+yO3
/pPMQVVhhBz2pgkqxCtznFqY9paN5lzwaOqp9HepNz1g99Q4u+KpIUI93BMcMdMD
9HtY7YQYzDCnhi4OskdIB2BrLm1NSFPMkALASTMuCplFwtyI+emYD/GzOwUF5zay
Vk4QQ33Z9G1pw6jU730kFl/FU5tps35leUYUMcgiz2CG9DTz/wFRJ4SjwD4b1NYx
35nwbrhnp5TV4g94zFfY1NejSwmCpdzq5fvSYwu73yQ+pzwqA2xjXGMwICEo95Tj
Zop/T9gU3g2Hglmz6zTe7m4EXdruFZrADlI6K6cPg/52HosSi7iLnkebwX0nClbQ
HQeCdved38nzRBDZGaJmrDebHD3Uy+qrP5dxTaDe49JZZ+lnkceqy5s+OLQb78S3
Wt9q6GgdKLwa157K74ci/T3rSnty+dJlOXlaq2Bhbru8O7GGmIcmMtsAYzI7+C0z
0cuqsI2sXvT6i/XSjt2VK0D/aQfJ0NfpWDJ6rtlAnFc0g5UBncd8MrAfWo/KOPdH
nIdamgVfmtHcglu07fBq
=0pwZ
-END PGP SIGNATURE-
Index: tzsetup.c
===
--- tzsetup.c   (revision 278173)
+++ tzsetup.c   (working copy)
@@ -40,6 +40,7 @@ __FBSDID($FreeBSD$);
 #include stdio.h
 #include stdlib.h
 #include string.h
+#include sysexits.h
 #include time.h
 #include unistd.h
 
@@ -944,24 +945,19 @@ main(int argc, char **argv)
if (argc - optind  1)
usage();
 
-   if (chrootenv == NULL) {
-   strcpy(path_zonetab, _PATH_ZONETAB);
-   strcpy(path_iso3166, _PATH_ISO3166);
-   strcpy(path_zoneinfo, _PATH_ZONEINFO);
-   strcpy(path_localtime, _PATH_LOCALTIME);
-   strcpy(path_db, _PATH_DB);
-   strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
-   } else {
-   sprintf(path_zonetab, %s/%s, chrootenv, _PATH_ZONETAB);
-   sprintf(path_iso3166, %s/%s, chrootenv, _PATH_ISO3166);
-   sprintf(path_zoneinfo, %s/%s, chrootenv, _PATH_ZONEINFO);
-   sprintf(path_localtime, %s/%s, chrootenv, _PATH_LOCALTIME);
-   sprintf(path_db, %s/%s, chrootenv, _PATH_DB);
-   sprintf(path_wall_cmos_clock, %s/%s, chrootenv,
-   _PATH_WALL_CMOS_CLOCK);
+   strcpy(path_zonetab, _PATH_ZONETAB);
+   strcpy(path_iso3166, _PATH_ISO3166);
+   strcpy(path_zoneinfo, _PATH_ZONEINFO);
+   strcpy(path_localtime, _PATH_LOCALTIME);
+   strcpy(path_db, _PATH_DB);
+   strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK);
+
+   if (chrootenv != NULL) {
+   rv = chroot(chrootenv);
+   if (rv != 0)
+   err(EX_OSERR, chroot to %s, chrootenv);
}
 
-
/* Override the user-supplied umask. */
(void)umask(S_IWGRP | S_IWOTH);
 
___
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: old bug: mount_nfs path/name is limited to 88 chars

2015-01-19 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/19/15 13:20, Garrett Cooper wrote:
 On Jan 19, 2015, at 8:46, Brandon Allbery allber...@gmail.com
 wrote:
 
 On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht
 me...@bris.ac.uk wrote:
 
 So perhaps changing MNAMELEN will break statfs(2) on -stable
 too?
 
 
 I believe the context there is not so much -current is special,
 as changing it for everyone is bad news (and this would
 necessarily need to originate in -current).
 
 A compat layer needs to be created for all of the affected
 syscalls, and the change needs to be made. That’s it in a
 nutshell.
 
 Doing it in 11 makes sense since there is a compat layer for 10
 now… if I knew all of the steps I would happily do them as annoys
 me from time to time as well with the path length issue.

Compat layer may break applications in other funny ways and we
probably have to return e.g. ENAMETOOLONG for legacy applications if
the names are too long to fit into the buffer, but I don't see any
easy solution either: I wish we have bumped it in 2003 when the struct
receives its first big revamp by bumping all statistic fields to 64-bit.

I personally think we probably better create a new API and keep the
existing one for (limited) compatibility.  For instance, it may be
sensible to make f_mntfromname and f_mntonname fields variable length
and have the caller pass a pointer and their length.  If we set an
arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some
time.

BTW. If someone wants to change statfs(2), please make sure to create
reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c
for an example).  The statfs(2) API is used in a lot of places,
especially fts(3), and breaking it either way (running new world with
old kernel, or running old world with new kernel) would be a big pain
to recover from.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.1 (FreeBSD)

iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O
a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f
vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU
4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg
wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c
NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J
55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ
sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj
b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro
IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v
+2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM
PiOk31dmRfQB+3mqZ+Oj
=a3fA
-END PGP SIGNATURE-
___
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: Delayed atime updates (lazytime)

2014-11-26 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/26/14 10:06, Marcus Reid wrote:
 Hi,
 
 Looks like Linux is about to grow another solution to handling
 atime updates differently:
 
 http://lwn.net/SubscriberLink/621046/e59938475fd3e874/
 
 In short, it will only write out atime changes periodically
 (daily), or if there is another reason to write out the inode, or
 if the inode is about to be pushed out of cache.  This seems like a
 pretty good compromise.
 
 Currently, the ZFS configuration that results from using
 bsdinstall disables atime on all but /var/mail, which is the only
 example of disabling atime by default that I'm aware of outside of
 Gentoo Linux. I can't seem to find any information that talks about
 the rationale behind that, though a couple things come to mind:
 
 - some additional IO generated (but that's always been the case) -
 additional wear on SSD devices (enough to compel the change?) - zfs
 snapshot growth (but the snapshot stops growing after one full set
 of inode updates) - wake up otherwise idle spinning media on a
 laptop (the actual reason that was cited as motivation for the
 change)
 
 Something like lazytime would address most of those concerns, and
 people who are even more OCD than that could disable atime
 completely on their machine.

I think bsdinstall disables atime because it's an useful default.
The lazytime idea seems to be a better compromise.

PS.  A while back I have implemented a 'relatime' feature on FreeBSD
in a private branch on my github repository, but never have pushed it
further due to a difference in semantics (which needs to be fixed:
atime should still be updated after some time, while my version only
update it once, the Linux semantics is more useful for cleanup
applications to identify unused files) and partially lack of interest
from the community.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQIcBAEBCgAGBQJUdjhZAAoJEJW2GBstM+nsJvsQAJAYNhKU3+3OTIEX7+1w1WlQ
SPO55FrZ86nRfYIDbioafXqXki5QrjDrZLwaP2wwLMOmclZBVxliKiFUnRSXNdl+
q0j2jSYiue3GKNvN6nLRTCWqe4lYg46btmVhqBsJnATLxDq4fH/5+FwsORgSgTOq
LENUyYDJ8beuYCCD52Rs7RklNhQqfEPPbNWclLuWqjq6YYcqfRjgXD0PHJpmhMcR
NOMRnkv8BtcvsOwD09uYqfsWZX5cO2yb1JdlvGRVft6xHLLOhCaAxOhhz7yeTSzq
OrvUSRw2rCRJdNqfUpLcN1oK7Fu2f13HrqPXGeOKc96VE6pX2ADaoCtKXgtDFf0W
qCmR1jhu5v/NAHxTZjRR+Lpf3zO/NA0lS3+uCFjxFjBy5NwFdh2MsNRBWV6EBdYF
kJ5DqsIqLfW89F7jtKnp3qaxhyySwKlgqDooVMrClCkz6Doy84dBzA44b8yQnHri
YcUlXgfBz33qfMP+pywRKOC25mQe05u1yk33dp1QTTxPVW+BvDMxgwaTqSpqTvyB
yHTm//Dz+UdNDkxL82aVw4pfNhhOPb52jWz7MNTVYTP15w3+rY45sChgux02ltNE
gEm1MnJIBYmFNQq5orcjLSGIKTL6VlrDmC6rd7zXEagQ1D34LknziE61m6/yeZTI
4lcmm6CWRz/L2cfOLR/p
=I8Cg
-END PGP SIGNATURE-
___
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: current panic: Lock (sx) random_adaptors not locked @

2014-11-04 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/04/14 06:01, Julian H. Stacey wrote:
 Hi current@
 
 Maybe this is a transient no one else will see ?: with no
 /boot/loader.conf, my old custom kernel booted  my new one
 paniced:
 
 panic: Lock (sx) random_adaptors not locked @
 dev/random/random_adaptors.c:278

This was fixed in r274006 FYI.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQIcBAEBCgAGBQJUWRmsAAoJEJW2GBstM+nsvZEP/1JKJsptJGPrkOfhE9MznH03
dD9TeDN1fZUvi+54ZZue78SS/hE4/Nbga62nWc5ml8mZkHwrEF/N1+xgHR5Scfw9
EPFFY/bvmzAB9AKDyFLPC7IYLCQ+G9lZKbkNbeSc8q4tze0nmc4Sgpum1FVstS46
njU9cnhIJZ9yScVkofhBuaAeGgbD5w4zK6Ezr1aLdfhTil2cs9nZlN2fuRBTDIot
v8PS52ZZw2pQJZ9SSZaYlB9fbT5vsH3cCUzxFpr5EH7oJdlNs6fPknYoy+2q4SkT
9yjIg+P96jdB42c0HaSO7DvJOzDIrtG8Dy1hMDpxJUkHodwa0HqQWNRYDZ8t3d2f
gEgwwO3/t8H6jyzPqPIwFj5nQuI6ErKfwDOUm/kORWy18zFiApDHhiAltMPsryCo
nz3swJEgmW//viYEW25Yi/WHEBvzrTa3736Q/r5/I6Ssz2nJX/wehuRQ4+pPHKGx
OponYjXeXlHj/1dVjdnieYgC+aCVSQTBiF5i+QBV6gD+NvLosjH2u73aQ73lQisD
AUiGw7AvwfuDaxvqhjT+hu69hCrpRcDhL9QEJZ6TmoPOnL0kaz70iVfO9khEoObr
MbODB+eqDn7j2tZ+klVWagRgFyjRX7uCGi9A3wLD43nvcd7wquNJVRFnSxN3NJD2
hhlH+sXhtcxZcyhwjWo3
=nu2x
-END PGP SIGNATURE-
___
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: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

2014-10-31 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The problem should have been corrected by r273919.  Please update your
system and update /etc/ with mergemaster.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQIcBAEBCgAGBQJUVBaIAAoJEJW2GBstM+nsDHIP/jEgsdtn8ZWbwSHCh8RBXhM7
rr7wdRXcti0h8G0htXTaWWrEaJ1Y7LKGVBjqrUqTJU/g7mRha/p2BrEsYMGBwFbT
uqPDYIiHvfVIDH6wAO5qi1CvPG8UhsGG3IV+RXEazeBFlNUA50ZRhyhYtvuywoWw
9izOCtc1y3pEuR3i7Ybpors6oulyYWIpd/tuafkVWmhrLblvCLNv6wrmwxAcXtNN
UC92bvH320nqA49AC1jAD0zrZ5uc6fPBgcSXi1SZvmnuxnODRrV/O0yD67fUHKtm
59x7woa4tMaVNtP+eQ2QSZv75oko5HmZqfAV4urTQjfb44wDj42uFOKN8WHmMNbe
RxZ/b7dhbU9BMKhnf117IIg2P96o2Hj9jwBN6+PaPoPw2UGSgiJf7/bf3RnEZCoM
TISlyv3fAvbNg7yuGAZsm8onjUPIfjlriOUhUeiKzNDhQDRW8eKWDPEio8IapyJW
wYLtNPjARYUfIswAVMRn5NuNzjqloPKLjXf2YOtREb/c3K1UZMRLTc98zPhJ7za+
6EzIe/CuY7X55ajwK8Fqmqh/G3TiaSomwiVzZrtl2ggdeXsMsWfeaV0E9gtspVwb
Qaprmo1Qx/vZUhHPy8L/OHqvCF39z4RC4N/4ryc7gt5gpW9jkeWzyYvGD/wCdV7b
bHxbVZR+Ukuz2B4aUFH5
=J3ap
-END PGP SIGNATURE-
___
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: zfs recv hangs in kmem arena

2014-10-16 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/16/14 4:25 AM, James R. Van Artsdalen wrote:
 The zfs recv / kmem arena hang happens with -CURRENT as well as 
 10-STABLE, on two different systems, with 16GB or 32GB of RAM,
 from memstick or normal multi-user environments,
 
 Hangs usually seem to hapeen 1TB to 3TB in, but last night one run
 hung after only 4.35MB.
 
 On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
 FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2
 r272070M: Wed Sep 24 17:36:56 CDT 2014 
 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64
 
 With current STABLE10 I am unable to replicate a ZFS pool using
 zfs send/recv without zfs hanging in state kmem arena, within
 the first 4TB or so (of a 23TB Pool).
 
 The most recent attempt used this command line
 
 SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs
 recv -duvF BIGTOX
 
 though local replications fail in kmem arena too.
 
 The two machines I've been attempting this on have 16BG and 32GB
 of RAM each and are otherwise idle.
 
 Any suggestions on how to get around, or investigate, kmem
 arena?
 
 # top last pid:  3272;  load averages:  0.22,  0.22,  0.23
 up 0+08:25:02  01:32:07 34 processes:  1 running, 33 sleeping 
 CPU:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9%
 idle Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free 
 ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M
 Other Swap: 16G Total, 16G Free
 
 PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIME
 WCPU COMMAND 1173 root  1  520 86476K  7780K select
 0 124:33   0.00% sshd 1176 root  1  460 87276K 47732K
 kmem a  3  48:36   0.00% zfs 968 root 32  200 12344K
 1888K rpcsvc  0   0:13   0.00% nfsd 1009 root  1  200
 25452K  2864K select  3   0:01   0.00% ntpd ...

What does procstat -kk 1176 (or the PID of your 'zfs' process that
stuck in that state) say?

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUP+5vAAoJEJW2GBstM+ns0v4P/31s7geR2j22etrRnfReUxbb
lbex0VkmLGm23TbTj2vpVce+ogBeA4zo6h4WzF/yYt2372MpWOfnEoVX2yOuuGku
AFapewXS3UMXLzaRWrdTWng1KQlOyQykAHI2rvQLlYlQNTLA5AbUm6uzNXaKpD8s
PbckREQ6wHnpZOiRcMN695QstjBNCal+XJHgvrwTfyp9vdFrPVD4UHnsN7MU6QSO
XobxOqbuw4Tq95mgYJqrjk+xEYMgzUy2zkVp2QTCBXZn3T3yroI2RcgUZQWaw5SO
xRegPa5jfJqcQJAdSxl8oVs9Sz8+5YDeksAnjCOxIQzLZBbNho+SOAzi+kjnT6W7
ijTc20z5eioQVPekdJ4MBweBsAeS1aGi8VWppuP+ZDLoirmxB0LaZyRv/W/HRQDD
j4CoZswkndh+J+9Crsa9SUkfNGNvVVNjhJUGyIfTGFUsMbWTAWwa4SMj7Ad04aqW
yhg+Ab4H3Yc14TahtX0jrhD3sTBer6ZoMFKE3tl8aStGXHVMyPkj0PHg5xjZEWL2
XGF86eoIgx03A9sIdbdHEZpyTMksfNatDXZk5XpPGF/sVd6txUoYP4Ch2wD8YRFM
O5Ny2r6ash2rZYmlyjf19n4gvKebdGo8d8NbzOJ3oYue6OI/88cu0rv6xLV9hHSF
fwgIbPo5uK4hIpEm0Dk4
=qY45
-END PGP SIGNATURE-
___
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: zfs recv hangs in kmem arena

2014-10-16 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/16/14 8:43 PM, James R. Van Artsdalen wrote:
 On 10/16/2014 11:12 AM, Xin Li wrote:
 On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
 FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2
 #2 r272070M: Wed Sep 24 17:36:56 CDT 2014 
 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC
 amd64
 
 With current STABLE10 I am unable to replicate a ZFS pool
 using zfs send/recv without zfs hanging in state kmem
 arena, within the first 4TB or so (of a 23TB Pool).
 
 What does procstat -kk 1176 (or the PID of your 'zfs' process
 that stuck in that state) say?
 
 Cheers,
 
 SUPERTEX:/root# ps -lp 866 UID PID PPID CPU PRI NI   VSZ   RSS
 MWCHAN   STAT TT  TIME COMMAND 0 866  863   0  52  0 66800
 29716 kmem are D+1  57:40.82 zfs recv -duvF BIGTOX 
 SUPERTEX:/root# procstat -kk 866 PIDTID COMM TDNAME
 KSTACK 866 101573 zfs  -mi_switch+0xe1 
 sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d 
 kmem_malloc+0x33 keg_alloc_slab+0xcd keg_fetch_slab+0x151 
 zone_fetch_slab+0x7e zone_import+0x40 uma_zalloc_arg+0x34e 
 arc_get_data_buf+0x31a arc_buf_alloc+0xaa dmu_buf_will_fill+0x169 
 dmu_write+0xfc dmu_recv_stream+0xd40 zfs_ioc_recv+0x94e 
 zfsdev_ioctl+0x5ca

Do you have any special tuning in your /boot/loader.conf?

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUQJazAAoJEJW2GBstM+ns6dQQAK4NM6X40d7tS7pqoTQvZbrD
U0u5kid703tWgAlSFzvORxeOEB94BxcHu/z1a68nGhUlL2kip8SirWV9A1rqBpes
i4T6asHYTcFj4OvaPfSoA7lSVsZIaLK+RscraN1b7hehSG9UExeYF8D7cRIguhoa
1Gnlv5iZZkjJZGjR0R6DmxC8C1CyNxAZBXnj1L+ofpgUzqH0Rw2TCW1XVKqMcxvI
5lpt+V0uu7MPNgjzgVy/1z5ZD2SUBPco0eHuN/Npj0c6HkmHkoWqd53vxrBhlyCP
eDbzLw7QTO7PaV5hAuC9y9/X1JGlmTVa0GP2irKuE5t1bAbVwUPQqpn+iiFs1Le8
34fL/jkCeSBY6voYYj100CBU1/1mZOh93wuY6FdMVWPJp/bsjbDUtKZUmosGU86j
ZMikfVNl5Jc5dmH30JGFCDOWzfaFq+V34toSfYIihaBQPyFov0Mr7De5MvQ7VJ7D
qiXDcfAXE99CXzAboYpruwrbxyxTqhUmXlWp2uCPqvmo0WhVUsROmhhXhWXkG3tS
S7L0n4X8kgklveirZWq/oDsg4JXNTP2ernNdAYyhD7TbG/N4INdFaVuqZkDVDgny
ibwY0HEzg2zskJOJBqr9a21fZx6c2dvJ1n+j5BaAq6ve2Hw2NyvUVWfMTknp4I8j
t/JJtsDNs9xokH/veS3J
=aBKI
-END PGP SIGNATURE-
___
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: ZFS-related panic: possible spa-spa_errlog_lock deadlock

2014-09-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 9/7/14 9:02 PM, Fabian Keil wrote:
 Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the
 following panic yesterday:
 
 [...] Unread portion of the kernel message buffer: [6880] panic:
 deadlkres: possible deadlock detected for 0xf80015289490,
 blocked for 1800503 ticks

Any chance to get all backtraces (e.g. thread apply all bt full 16)?
I think a different thread that held the lock have been blocked,
probably related to your disconnected vdev.

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUDGarAAoJEJW2GBstM+nsU+AP/0CjAmk3p/j/HD3lOCRYRiyV
JkajIcSI8FFgAfLuiULclnEziBT+XEgYDisoABd7FVaP890mL/Mp52RSLMYlr8VJ
RP9Qv+KePNGVn52djSOPxnNdUNqgNGHiDEllUIZbBu28k/flV4EcSfm799iA9HES
o84LPUUc1pm+NJTtgoT6QKWZ+kfuztfY3/vlwJEluJqSuoZkN8DII1jT3pE55R6h
f++bqSD/eKOd/3EJ5qZ38glXhmeSPEJ+VJlVumuRMwQoe3II7nIrZZBYVMY1sRZ8
qqmi4mUU1EOGvQWYjZ+J+1TYDTQgO9PP/aEPhz39tyJxP4d/VNDbJqPvAw+ez9ZU
jT7n9xuaFXr3WdJSexSFsDOJts9op6kytqnZScPTgVUi2AbUQwBu3wV9v9XKjqBa
YlcHoGFlpUmlc8I9NXdTks0oyORct0K5E/5x00S9QUGw3EtokDVCBQ63n9L1usmd
mRG7F5xgDoTtl6UQSdW+DLhYF0cS08zG6TBDBx630Bdbtye2j5rRVn/bmonZJpOd
Mx0lUyYGKnJFnMaeJe2BsFkrMyUej1JuI0plLVe/QyZ/GBPKsXCIV1R/EC2+2rUF
xgrJl18H5hnwyNpBxjjrBodz1zgbpntijcH301lxRYlJYDBBwUTk3WBxLs/HISTe
itcqBb/VIO33cjBHn3qJ
=QPRD
-END PGP SIGNATURE-
___
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: ZFS-related panic: possible spa-spa_errlog_lock deadlock

2014-09-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 9/7/14 11:23 PM, Fabian Keil wrote:
 Xin Li delp...@delphij.net wrote:
 
 On 9/7/14 9:02 PM, Fabian Keil wrote:
 Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got
 the following panic yesterday:
 
 [...] Unread portion of the kernel message buffer: [6880]
 panic: deadlkres: possible deadlock detected for
 0xf80015289490, blocked for 1800503 ticks
 
 Any chance to get all backtraces (e.g. thread apply all bt full
 16)? I think a different thread that held the lock have been
 blocked, probably related to your disconnected vdev.
 
 Output of thread apply all bt full 16 is available at: 
 http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt

  A lot of the backtraces prematurely end with Cannot access memory
 at address, therefore I also added thread apply all bt output.
 
 Apparently there are at least two additional threads blocking below
 spa_get_stats():
 
 Thread 1182 (Thread 101989): #0  sched_switch
 (td=0xf800628cc490, newtd=value optimized out, flags=value
 optimized out) at /usr/src/sys/kern/sched_ule.c:1932 #1
 0x805a23c1 in mi_switch (flags=260, newtd=0x0) at
 /usr/src/sys/kern/kern_synch.c:493 #2  0x805e4bca in
 sleepq_wait (wchan=0x0, pri=0) at
 /usr/src/sys/kern/subr_sleepqueue.c:631 #3  0x80539f10 in
 _cv_wait (cvp=0xf80025534a50, lock=0xf80025534a30) at
 /usr/src/sys/kern/kern_condvar.c:139 #4  0x811721db in
 zio_wait (zio=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 
 #5  0x81102111 in dbuf_read (db=value optimized out,
 zio=value optimized out, flags=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:649 
 #6  0x81108e6d in dmu_buf_hold (os=value optimized out,
 object=value optimized out, offset=value optimized out,
 tag=0x0, dbp=0xfe00955c6648, flags=value optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 
 #7  0x81163986 in zap_lockdir (os=0xf8002b7ab000,
 obj=92, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=value
 optimized out) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:467

 
#8  0x811644ad in zap_count (os=0x0, zapobj=0,
count=0xfe00955c66d8) at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:712
 #9  0x8114a6dc in spa_get_errlog_size
 (spa=0xf800062ed000) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149

 
- ---Type return to continue, or q return to quit---
 #10 0x8113f549 in spa_get_stats (name=0xfe0044cac000
 spaceloop, config=0xfe00955c68e8, altroot=0xfe0044cac430
 , buflen=2048) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 
 #11 0x81189a45 in zfs_ioc_pool_stats
 (zc=0xfe0044cac000) at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656

 
#12 0x81187290 in zfsdev_ioctl (dev=value optimized out,
zcmd=value optimized out, arg=value optimized out, flag=value
optimized out, td=value optimized out)
 at
 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6136

 
#13 0x80464a55 in devfs_ioctl_f (fp=0xf80038bd00a0,
com=3222821381, data=0xf800067b80a0, cred=value optimized out,
td=0xf800628cc490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757
 #14 0x805f3c3d in kern_ioctl (td=0xf800628cc490,
 fd=value optimized out, com=0) at file.h:311 #15
 0x805f381c in sys_ioctl (td=0xf800628cc490,
 uap=0xfe00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 #16
 0x8085c2db in amd64_syscall (td=0xf800628cc490,
 traced=0) at subr_syscall.c:133 #17 0x8083f90b in
 Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #18
 0x0008019fc3da in ?? () Previous frame inner to this frame
 (corrupt stack?)

Yes, thread 1182 owned the lock and is waiting for the zio be done.
Other threads that wanted the lock would have to wait.

I don't have much clue why the system entered this state, however, as
the operations should have errored out (the GELI device is gone on
21:44:56 based on your log, which suggests all references were closed)
instead of waiting.

Adding mav@ as he may have some idea.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJUDIA5AAoJEJW2GBstM+nsdsgP/RT4nBT4mvOtpF2IEL7VFexJ
OjipGsWIDmG9kc8CEEN+qh3Q4+prJO3IwHGTUPa0Vu13jRZ3T/uoZj/ncVAqnCyW
s+SeEBjVVhZs/B08LqT2A8fZI9jVdqvFVWEL02z3ibWggoCnP60oag1OyvkNGqQU
apWtXkjTnrFmOEcbB95viD8QEhfUzlQgBbeRuK8ADtK/jQNEl6A8xdE5HCT2DIN4
icIwoj9eXqyLB0/aGVIFycRID4hWAZaqPehXVtGhCdnlGut7itdufuXtfmTCEDWs
z3vkGjTCJ3qsyKSxl/2ABGRgAH/lpR6J/N2yZOSNMRTt9PbjN1iLppu2IfD33OdY
QlQrI2HhbwvoZmYe4f4B/1/8qzKag77hzYG2J2aN0OGn45zkThOwoQt854zm7OHq
f3O3pysxUInTnIJrdBa53cT0arhQRtYn1xL5CYyvK4Nto74ht6g/AuBJbBWzWM/B
t2fKuZmpGt32lf+vHjWS0O2VWdkc6I6s5rVZJsSLzAMfc1rWePIcokPdUk9RucyX
qRrNDpMW53APWhPKGpkK+Utyx/OLKhO62d7iiYrGhVX0FU

Recent vt(4) broke moused when hw.vga.textmode=1

2014-08-23 Thread Xin Li
Hi,

I have seen this panic via serial console, but the console is completely
unusable at the time.  VGA console is full of '?'.

Booting single user mode, I can provoke the panic with '/etc/rc.d/moused
start ums0'.

===

Fatal trap 12: page fault while in kernel mode

cpuid = 7;
apic id = 0e
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2c
cpuid = 6; fault code   = supervisor read data, page not present
apic id = 0c
instruction pointer = 0x20:0x803abcf7
fault virtual address   = 0x2c
stack pointer   = 0x28:0xfe085f1b3880
fault code  = supervisor read data, page not present
frame pointer   = 0x28:0xfe085f1b38e0
instruction pointer = 0x20:0x803ae562
code segment= base 0x0, limit 0xf, type 0x1b
stack pointer   = 0x28:0xfe083c9b9950
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, frame pointer
= 0x28:0xfe083c9b9a10
IOPL = 0
current process = code segment  = base 0x0, limit
0xf, type 0x1b

The instruction pointer is Line 831 of /usr/src/sys/dev/vt/vt_core.c.

Reverting /sys/dev/vt to r270269 would solve the panic, but I haven't
investigated further.

Cheers,
___
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: Recent vt(4) broke moused when hw.vga.textmode=1

2014-08-23 Thread Xin Li
On 8/23/14 12:42 AM, Jean-Sébastien Pédron wrote:
 On 23.08.2014 08:38, Xin Li wrote:
 Fatal trap 12: page fault while in kernel mode
 
 And the crash is fixed in r270390.
 
 Thank you for reporting this!

I have verified and r270390 have fixed the crash, thanks for the prompt fix!

Cheers,

___
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: [ZFS][PANIC] Solaris Assert/zio.c:2548

2014-07-22 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think this is my stupid.  Feeling ashamed.

Please try r268980+ and report back if it's fixed or not, thanks!

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTzihjAAoJEJW2GBstM+ns2esP/3zfORqtE11QeveWI8wBzHav
Pl4A3V8kgi8FHP8m33gim1yAERpqf2+WgYuAjUNloFrFD9JCslnnoGtk9yiaOH2N
Y7SJMYfvYkZ50upGE+fJKAcpH3QxLuEpSIlaFMkvA9oXtAiZEJ+BYBJh8VFWFXIs
+bnqY0Mba7T574oqw8KcEysdYYDqSVd4/M/HBUdDTWT0/ZgeStJZw9MKPiSYFJcK
PvV9dglPZ08L+Ra7cqu/EtC93p9IxVtfqxMlNkhMeVkQt+0jMKzHgDZ0dg9j7AVn
SA9e+YvE9Sg2riE6XT2iF9B8Z4vDFf5/8CGtpBpKrB4861bcctdgJ3LIJBdDsz9N
lOCjWXc4Amv8GVpTKPKaAGxeGPeN52Drqd2pD1ljLLENJsBZ3WOdMjt/R4VhpLVl
9LuXNFZ8oQy/PqVxHhYWYOOuqcFQnexB/5Qdmic3grIC/fwELbQwEK+34md5q4iJ
pvy34RzzZrA1pVRfBM2oQ0TnABrdA7+bsb44DLvkPHmVGxPPZdN7QUfVzIrbCNe9
apBkLk/Qx2kOtpuAe6xBxhaOZEAJ9Q26Souew1HOYDSAusyCETB5+tfp1hl7R0ic
xdL4YjSq9FPKOyYATCBh8/F0f2hVPC3mB2SmDz9PvI1+POWHae1tpeSCGonoc3A+
DCOLXRPNLbyZyrxTUtXG
=NzT+
-END PGP SIGNATURE-
___
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: svn commit: r267897 - in head: contrib/file contrib/file/Magdir contrib/file/doc contrib/file/m4 contrib/file/magic contrib/file/python contrib/file/src contrib/file/tests lib/libmagic usr.bin/fil

2014-07-02 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 7/2/14, 12:10 AM, Matthias Meyser wrote:
 Am 26.06.2014 08:03, schrieb Xin LI:
 Author: delphij Date: Thu Jun 26 06:03:39 2014 New Revision:
 267897 URL: http://svnweb.freebsd.org/changeset/base/267897
 
 Log: MFV r267843: update file/libmagic to 5.19.
 
 MFC after:2 weeks
 
 This commit breaks installing world from readonly /usr/src

Can't reproduce with today's -CURRENT.  Any further details?  (I tried
mounting /usr/src read-only and both /usr/src and /usr/obj read-only,
neither broke).

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTs71HAAoJEJW2GBstM+nsdhkQAKwiZtKcHwOVijRvwHq6dWOQ
zlY3OhDCygzW93KxMW3kqT223UNP2tRBDyu3xQqn++av4NVprFo/aRrV/vs+tZYN
RMUcLFFlUeQZHIyF9L4alyAX3/ncABwWrOV97kkg990+O7CeURDycTc7Cwn/YwXq
pzrLT9ebzaRecRN1PJ5jP1dB569CFuKWyVDWjiaKxt32U0oi3T/MWTjaot+cGI0e
RrfJu+zmTwQk6gTl9lFewaIzqEIfVFotOQ3DB6IocQ2XL+wVD5NFnKYhl3UL6fJq
TK2oPuphktHi1WfEycmTIwsDfvR0o7I6ZD1Q5zdvp+PUgJPBmPS6ha2QaqfLZLht
vePNRwcD2lqpeyQRkd9W9N2YIswysiKnVXPd3OL29v2UJ3yafLTXnsLjrDdIFD50
+0xG8Y3E/1Vq/VGyachhAXSFEJfrNrGHPNQ3be0KZXnHcTgUFdg6+1bG+GeCjk4r
NwS10FlcbFUwgKc0d1wF1H5VT9xXQjJJTFa2AGbBqaOKQPEcwPKMnXdYCPfOKmzD
vdh03JNsXJyZYrpRtb7jATjQmgTp13VFlGqBJAEVc0Os8CjKmWnK06TeUQw+8q9B
NNebsCHYDlYrylFnyR7RJ6gD24F6uzUXxV/EXg+Bzidvu8jzg240Zd4aR1MU6obF
qSe3alAzDfUKzP+Y20+L
=5kxz
-END PGP SIGNATURE-
___
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: userland breakage, zfs ?

2014-07-01 Thread Xin LI
I'll take a look on this.


On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno sbr...@ignoranthack.me wrote:

 Just updated two machines in the fbsd cluser, buildworld/kernel,
 installkernel, reboot into single user.

 zfs from oldworld (pre installworld) doesn't work and segfaults in new
 and magical ways.

 Trying to mount root from zfs:zroot []...
 Enter full pathname of shell or RETURN for /bin/sh:
 Cannot read termcap database;
 using dumb terminal settings.
 # zfs set readonly=off zroot
 internal error: pInvalid argumentid
  19 (zfs), uid 0: exited on signal 6
 Abort trap


 I guess, I could multiuser the box on old kernel and installworld from
 multiuser, but this could lead to disaster.  I see no indication of ABI
 breakage of this kind in UPDATING, so ... any ideas?

 sean

 ___
 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




-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
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


HEADSUP -- ZFS users

2014-07-01 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

As some of you may have already noticed, I have accidentally
introduced a regression when implementing backward compatibility to
existing zfs binaries when importing a recent ZFS change as of
r268075, which will cause system to block on 'kmem arena' when running
_old_ zfs(8) binaries, due to an overlooked incompatibility of kernel
data structures.

If this happens, the quickest recovery method would be to roll back to
previous kernel by booting into single user mode, mount -uw /, then
copy /boot/kernel.old/* to /boot/kernel .

The compatibility code was tested against old kernel so if you are
doing 'make installkernel installworld' (NOT RECOMMENDED: new userland
is NOT guaranteed to work with old kernel) rather than booting to a
new kernel, then you would probably be unaffected.

I have a working fix and am testing it right now.  The fix will be
committed after I have done sufficient testing, and I'll send another
headsup once everything is settled.

Sorry for the inconvenience and thanks for your patience.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJTswQiAAoJEJW2GBstM+nsrxkP/iuyV5CYFtdBTaLONTEihGYH
Y5GpkrSy14Dikz+kAhCVBs6BlbEe94tpHvpL7tHKbIfmXQthWXj9WSW5F4PDrJGN
FOLTCGfS0IHfKe2hzAln8jJW+E5uECgL/mLlPVbiVFf1gLsbHgy+YoOS46Zmr4Ro
JmW7zChvIT2ZFvF8NJbP22PThf0R5IRPU9EKSbF1BioUUAePyh3Ml6TlGofCFAFT
kBSuLhRDw6p42SJ+tWHixdPKVFJHj4qrYtAdBCLTa/jeLYUuD1R0wfk3XyZHH6r9
8dfN0L4GVM9vjvh1qD9AC1TZy1IbwE1TsBnmipo2bU8BLxey8/TxdtimLC/JoXol
EcBfsO/GfOcLxvYEdD6ZstOZkAcGRfpxbe8ECfEia3od9bM11eCBo1OTdAHlCnGg
VxhoCzWGtL6Ma3EApZpOELG43wE+8N9tv3ylM30QTEcJ27SS03mewQUTnXPHFvZq
D0kSC6CSF1WfFIm5aS8NkkrZKazhdig7TasBXWq13p9u2p5wvAgPZlh2qWF4uBdb
oP1o/c9kbYyiduUrRDWwL6iGcD4YQG/9vpPntwH17B4r8i6Nf69E1KeU32FUDfbk
Lfn7lY9M2NgsCH5MQrWygR6NfeirEtpq0cGgu6FPnUHq0PAxkl9CtrjEBa3RPLXa
NCYxWySbYXV+I1jKYoZU
=eO6S
-END PGP SIGNATURE-
___
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: HEADSUP -- ZFS users

2014-07-01 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Should be fixed in r268116.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJTsyDiAAoJEJW2GBstM+nsz+kQAJQQHq6tlIhv3MrCzaEF9BWw
PKKdRPKXfBI4d2DD/WIx16q62bI/8T9iSEMLheyiVPpnMWor6AUmDIvZFAtWYuHD
i1SW5bPXKQUGgQXXhrRGH3goD/2K2YW+96yotBHn5Qq5yF6UHixK6aALE1y75UlH
BcYkkuytCSjdTyU7Ujk6unHjMMhg39I36sYt/dLCR6zh6vuMuuCYVNxn61iKVMEG
oXL/GZTQrzABQ4OBT3+kkbBvFX8UC9qHM9jP4pS/Z2ldf5DHemTPseDVgyAZi7Fq
feapjOGAlpgkE/IhXkYuOUEYgbnLhKuzZ8QuwNtyGNI+kjzDHvRZoo3NQa1AUCDg
sNaCh+IYK0A+gdL8yAboc2rUXebZsVpwP/fq2YtZ6BgZohDoT3p67yXwxBlf6GDw
7+niYeY3mZtddCIteLAkgB6a7jOO/HIW6hrmp6QeAHRUhS5e8OO5an08Wk8fY0n7
+gwFJPt9iidVpyQZwYQY9Gg0563azeII3j7MZy2bIYRFYHDfMWYt/JaBRS39kET/
Yw+lahYRwAO0WQFPy4e4c69BfL+k59B5QAi3c/u/8B9Mm7XEh1ufItcrfOl9KNRg
NpCiqOewtoUJSOwv7T1gr3eEwyKYQR0aFnKd4zPc2tCknZtUz4c1ylv6xX89mU6Z
TWkI7+SiBvF0gplro3Uo
=qMaa
-END PGP SIGNATURE-
___
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: svn commit: r267977 - head/bin/mv

2014-06-27 Thread Xin Li
[moving discussion to freebsd-current@]

On 06/27/14 15:23, Jilles Tjoelker wrote:
 On Fri, Jun 27, 2014 at 07:57:54PM +, Xin LI wrote:
 Author: delphij
 Date: Fri Jun 27 19:57:54 2014
 New Revision: 267977
 URL: http://svnweb.freebsd.org/changeset/base/267977
 
 Log:
   Always set UF_ARCHIVE on target (because they are by definition new files
   and should be archived) and ignore error when we can't set it (e.g. NFS).
 
   Reviewed by:   ken
   MFC after: 2 weeks
 
 Modified:
   head/bin/mv/mv.c
 
 Modified: head/bin/mv/mv.c
 ==
 --- head/bin/mv/mv.c Fri Jun 27 19:50:30 2014(r267976)
 +++ head/bin/mv/mv.c Fri Jun 27 19:57:54 2014(r267977)
 @@ -337,8 +337,8 @@ err: if (unlink(to))
   * on a file that we copied, i.e., that we didn't create.)
   */
  errno = 0;
 -if (fchflags(to_fd, sbp-st_flags))
 -if (errno != EOPNOTSUPP || sbp-st_flags != 0)
 +if (fchflags(to_fd, sbp-st_flags | UF_ARCHIVE))
 +if (errno != EOPNOTSUPP || ((sbp-st_flags  ~UF_ARCHIVE) != 0))
  warn(%s: set flags (was: 0%07o), to, sbp-st_flags);
  
  tval[0].tv_sec = sbp-st_atime;
 
 The part ignoring failures to set UF_ARCHIVE is OK. However, it seems
 inconsistent to set UF_ARCHIVE on a cross-filesystem mv of a single
 file, but not on a cross-filesystem mv of a directory tree or a file
 newly created via shell output redirection.
 
 If UF_ARCHIVE is supposed to be set automatically, I think this should
 be done in the kernel, like msdosfs already does. However, I'm not sure
 this is actually a useful feature: backup programs are smarter than an
 archive attribute these days.

The flag is supposed to be set automatically (as my understanding of the
ZFS portion of implementation).

However in order to implement that way, we will have to stat() the
target file (attached).  Personally, I think this is a little bit
wasteful, but it would probably something that we have to do if we
implement a switch to turn off automatic UF_ARCHIVE behavior.

Cheers
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
Index: bin/mv/mv.c
===
--- bin/mv/mv.c (revision 267984)
+++ bin/mv/mv.c (working copy)
@@ -278,6 +278,7 @@ fastcopy(const char *from, const char *to, struct
static char *bp = NULL;
mode_t oldmode;
int nread, from_fd, to_fd;
+   struct stat to_sb;
 
if ((from_fd = open(from, O_RDONLY, 0))  0) {
warn(fastcopy: open() failed (from): %s, from);
@@ -329,6 +330,7 @@ err:if (unlink(to))
 */
preserve_fd_acls(from_fd, to_fd, from, to);
(void)close(from_fd);
+
/*
 * XXX
 * NFS doesn't support chflags; ignore errors unless there's reason
@@ -336,10 +338,19 @@ err:  if (unlink(to))
 * if the server supports flags and we were trying to *remove* flags
 * on a file that we copied, i.e., that we didn't create.)
 */
-   errno = 0;
-   if (fchflags(to_fd, sbp-st_flags | UF_ARCHIVE))
-   if (errno != EOPNOTSUPP || ((sbp-st_flags  ~UF_ARCHIVE) != 0))
-   warn(%s: set flags (was: 0%07o), to, sbp-st_flags);
+   if (fstat(to_fd, to_sb) == 0) {
+   if ((sbp-st_flags   ~UF_ARCHIVE) !=
+   (to_sb.st_flags  ~UF_ARCHIVE)) {
+   errno = 0;
+   if (fchflags(to_fd,
+   sbp-st_flags | (to_sb.st_flags  UF_ARCHIVE)))
+   if (errno != EOPNOTSUPP ||
+   ((sbp-st_flags  ~UF_ARCHIVE) != 0))
+   warn(%s: set flags (was: 0%07o),
+   to, sbp-st_flags);
+   }
+   } else
+   warn(%s: can not stat, to);
 
tval[0].tv_sec = sbp-st_atime;
tval[1].tv_sec = sbp-st_mtime;
___
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] /dev/devstat permissions patch

2014-03-18 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Adding phk@ to cc since the 400 is from his changeset (r112001).

On 03/18/14 12:29, Maksim Yevmenkin wrote:
 hello,
 
 would anyone object to the following patch?
 
 ==
 
 Index: subr_devstat.c 
 ===

 
- --- subr_devstat.c (revision 263311)
 +++ subr_devstat.c (working copy) @@ -503,7 +503,7 @@ 
 mtx_assert(devstat_mutex, MA_NOTOWNED); if (!once) { 
 make_dev_credf(MAKEDEV_ETERNAL | MAKEDEV_CHECKNAME, -
 devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0400, +
 devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0444, 
 DEVSTAT_DEVICE_NAME); once = 1; }
 
 ==
 
 i'm not sure why /dev/devstat has such restrictive permissions.
 can someone please explain the reason for it? having gstat(8)
 require super-user privilege seems like an overkill me. iostat(8)
 and systat(1) do not require super-user privileges to work.
 
 and, yes, i know i can override permissions with /etc/devfs.conf,
 just curious what are we protecting from in /dev/devstat

I have similar change locally (except it's GID_OPERATOR and 0440) and
I think your proposed change would be a sensible default.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTKMofAAoJEJW2GBstM+nspPYQAKt8UiAqDBQwe0KTeH+ykpis
4EG4+oM43Ze8WCc3DgsbB+Dnq4en63z3SXyK7b78ZDN9xVzSmR4Cb6N0W63cuACI
4pE2Wl72P7v6eVgOrrgMJoRjI7BwX0nlOXKCvmwkHznbZSmpjgYTzx9ADYl1T4pP
SKtvgOtCyFXdpGP2adE8kJMRcFvBpbs61Y4hiSLwKE1lGywgLwYWfwkZMWFxGaNW
SU3H7qew5SRoFSF7ZhurhKENwyNR1EHEHXW+Se77TcTUzBIGCQop+78Od+Pxwi/v
KJYFKHS+Z72BRVbpaxowxQGRNSPzqC4dB2nMhrcQaOU8gXRret9OXCfBc7Fmrv31
ot0ewo3GapmNh/9ypMuYNQ+3XsjEmx96ckSeS0oX6lKLR2qIu8+JIMd9Oq0ogNHk
tMdjrX0dkpwedN9UiakbQq8Ws7u/XRfkQEUD8nsDu5gK+f3KlRldboA+GFAjYgX6
F+E4JHfRGWCFYQuzcl48Nkzg4Glw/r8HCHHE+cGqwXXPIGfjtwSIyGGZzw0Nb2Nr
jYfs4aYuGCwFmwUO/hVn47Wbbzmpr7rVbf7EW3PXwZuxPKTVxrEUpYklvCUmkDMi
jYEwQMcIfV7pI+nD1M9bocOk3TQ4nYWqlts2E6J+/qEC/ayXpo4kk/93swimj7wP
p6xDXw3sAX6Xaj0bZqcB
=ktrj
-END PGP SIGNATURE-
___
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: processes stuck in vmo_de state

2014-03-13 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It looks like there is a regression (or a regression that gets exposed
by some new feature) that is related to time-keeping or timecounter,
although I'm not yet familiar with the related code to tell if my
conclusion was right or not.

The problem I observed is that when system boots up, it sometimes
hangs and pressing ^T on console tells me that sleep(1) is running
with 0 second out of 1 second, but the 'real' part of the output is
smaller than 1 or sometimes negative.

For some reason the console may stop giving any output, but trapping
into debugger would unblock it sometimes.

When sh(1) stuck in 'vmo_de' state, it would never recover from that
and a hard reset is necessary.

It seems that commenting hint.apic.0.clock=0 from my loader.conf would
mitigate the issue by the way.  I'll let the system sit there and do a
full universe build, etc. for a while and check it tomorrow.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTIXfgAAoJEJW2GBstM+nsc1EP/1VbIXscDeufiuAOj+UmDWV1
LsEb7n2M6qVYuL7sTTqY7R5svUATcVRAxG/jjXTHObvvCdB/8Gjk+51K/cCN5wIV
bKchxm2mv1ENbkFQJI3akntSbPeNk2iEAzORdvdcD/gkb5sIOxNGfeBp8/PtIO4x
3bKD2aRh7KdHzDWl4PdLiZSstLLuG1w6K0tFaoeWV0wu3e3GgMglK7kSq2H/ZWrn
WCtcw9kJOFuRF2kIj1UMygvqL6IDt2UF8As7A4wO/HKCTMm3xj5tHQzn6JZFoRwR
I2rILJtKrWRz8TUutV+ivD+2c0ZFpL6qn0ByQFtAPU3S1LQsgHZhgPNanvNVcmRQ
zz35CTWYRdxIq1JTZTA9zd/At9jRJtRYenJxgK9btJfwF9TqtmWmwPcOIkaMPr5T
uNHO5c+4gMQK96Km08cwkDCPoZTPNHJcAHgTlDMTM+TZ5vjVqyOI4wLcTwLecLca
yFJIaBhYektAlPJZoNwNJJsv3ReBF77yKMNzaNAUAM5Cfu06I1DGsxmrFTpvx+t/
nnIjHF0djACuJq8CpVHe4r8gdEUSSc180gzgyyyCJc8cHGc8JphOdY10gNBc6Cki
4h5cAdGUNov0+NkqF0tmEwKvDoCb7ASph7yJbVymt+2t2gh4ay8T1BBH2k50deG8
rsO6gv8qzRZshwyXlZd0
=DaxI
-END PGP SIGNATURE-
___
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


processes stuck in vmo_de state

2014-03-11 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I have recently upgraded my home storage box (Avoton based board
running FreeBSD/amd64) from 10.0-RELEASE (patched with some ZFS
changes) to -CURRENT.  It looks like the system would easily hang when
I start 'buildworld', when this happens, I saw sh process stuck in
'vmo_de' state and procstat -kk would give me EBUSY:

$ procstat -kk 1752
  PIDTID COMM TDNAME   KSTACK

procstat: sysctl: kern.proc.kstack: 1752: Device busy

To rule out issue introduced by my local changes, I reverted them all
and used an unpatched 'VT' kernel (with WITNESS, etc. enabled).

In loader.conf I have:

zfs_load=YES
aesni_load=YES
hint.apic.0.clock=0
hint.atrtc.0.clock=0

In rc.conf I have:

powerd_enable=YES

economy_cx_lowest=LOW
performance_cx_lowest=LOW

The zpool I'm using is configured to use SHA256 as checksum.  One
zpool is created over 4 GELI provider and decrypted on boot but I
don't think that matters.

Any hints?  The system have flaky IPMI access so I can't always debug
from remote but would happy to provide more data if helpful.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTHr/cAAoJEJW2GBstM+ns6akP/1nsP8EH1zQ3v04fP4ZrmHp2
/7RgU3LH5/ydRuoiVvMnnJsK0XjZxi/Uu8kad1P/xi4FpqDmMTsQ5/8u/HKoGA9Z
Jik+LS79R7AApU4v64pWpPbUo7a9cs+JWH3gNWPCfqDHpg6FoP6B7sxrGdX4EY+n
UftSstk/UVSeoGaoC1sEgzsR3/ORAN+pQ7YbTlPJ7/RK8OIcrq8GTXTJpXaT0EoP
w0PQZtvPy5lWkB+KwAjrfF3QEr/G6pubLKbeq46eSwY0eDruL79zd7zozHcR5F9e
03tu17VM1QW41Y8zQT16cX8YEWI//5rk1wOQLZXT++jWyty9T9Ekt+d+H0mCPtjm
nIwLlyVQrfXPZnvFi3oZcOxgSdT3x3O9cUDQVebC4yIN4NPUWdyHmn6C57xwjW/h
efPoujEAkjPfD3iykWbLBXHGKyINi3KxU8ht1vndO4LdYKj+Dvtnz/IKs6VxnyT0
ld19nMkXZOjZc8Iftkx9/aLdlA1/BtkwIndod1J18kmMf7fWW9k7Mt8DyaGD8XUA
5QRIz3aeomF/+awTvVWTa07Rib5d4s6qv63ecGPEhNLjR6QA5t19b0W/8Ip2eTQD
B39ROUtBbSE2wzcpYwNdkHQEUiQSOzQithqRPvzXJZrUdEk+I3/4D1870r5BFCIJ
wL8/P0dmN1Y02vYFdJwy
=xBqp
-END PGP SIGNATURE-
___
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: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the strength
 of the hashing algorithm (when combined with my other feature
 request). Updating my bcrypt hashes from $2a$04$ to $2b$12$
 or something. Same applies for the default sha512, maybe I
 want to update to rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
 
 
 This looks like what we wanted. In the feedback you talked about
 some changes to your patch required to make it work, is there any
 progress on those?
 
 Derek's patches worked perfectly for our needs, but we're the sort
 of people who use vipw and our own utilities for user management.
 It wasn't until later that we discovered at least one other file
 would need patching to satisfy everyone.  We didn't want to employ
 the same copy-pasta method, so we asked for feedback about our
 proposed alternative.
 
 secteam@, do you have any comments?  Before we put any more work
 into this, we want to be sure that our proposal is an acceptable
 one.
 

Did you mean adding rounds capability, or transparent upgrade of
crypt() algorithms, or both?

I need some time to digest the whole transparent upgrade idea but in
general I think it's good.

Speaking for adding rounds, the only problem that needs to be fixed is
that the proposed patch makes it possible to create conflicting
configuration (passwd_format and passwd_modular can use different
hashing algorithms) and need to be fixed and polished.  I like the
idea of making it possible to use more rounds though.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGkLzAAoJEJW2GBstM+nsaVoP/017iARGzd++lCsfqyFDozGk
nXJjatlrIcRjrbCmVRT0lsHiK/hoYJ4zZPeOu8EXU1Qs0/wggGHYePX7+zEVob2S
YCxhqUOdG/jqrHnH8bljzWE/OtI7Y4PvFOLpsWkOE/uulssQfGDMSy8WJzFriqzv
GXjAEyFrGXCT29gW6ozTRfDfPSOfd4MhwewbMYAUykSqucMfkG4FaDAgLxv/XdRi
YmLQZuxxTzEqMYanZGq/0e5CvOwOuncd0aVxncJC8ZRcsHs5cqbzcyDkkRwvw/YU
g1OsLXiO08zej0rOz1E4pud8O6q3unG5dNcz9Y96oNo0fJONMrk9IetCUCHBsR8N
eyWJQyHL7wwwNlC5k8U9cOnsL3zxBv54N6bfWuWNNDpJmNrvgMr9LdPso+AX0gLD
y4RhVJeLCQbLrkQawoM1+Ki5N0mQibk9BBGXH/ZPScP1pNqVt9tqXp94N5ZPLV54
Uu4cn/2uKjtTjl76YFlCTvfwwiuWgds1k6CnKZIW8luOp4cG5XOoOSztONqWr6S/
yd7SLDV4f8PC7Fi1iSkSuVW5MYz1I7RRVR1Z27oV3e3UwXwIgqRjHJawNZqIgVe1
4lk84+fm75ULLfiA6bgkMCjylyWHCzrdOQt/Zx+0vyZOer5x2p4gZmnYAyV2EQIP
TM611j1UES6OUGFkfbWa
=4Qur
-END PGP SIGNATURE-
___
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: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote:
 Xin Li wrote:
 Hi,
 
 On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the
 strength of the hashing algorithm (when combined with my
 other feature request). Updating my bcrypt hashes from
 $2a$04$ to $2b$12$ or something. Same applies for the
 default sha512, maybe I want to update to rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
 
 [...]
 
 Speaking for adding rounds, the only problem that needs to be
 fixed is that the proposed patch makes it possible to create
 conflicting configuration (passwd_format and passwd_modular can
 use different hashing algorithms) and need to be fixed and
 polished.  I like the idea of making it possible to use more
 rounds though.
 
 This was deliberate for backward compatibility.  passwd_format will
 be used by default if passwd_modular isn't defined.  If
 passwd_modular is defined as disabled, then passwd_format will be
 used.

Well, my point is that the two shouldn't be allowed to exist together
if they can mean something conflicting.  Allowing passwd_format=sha512
AND passwd_modular=$2a$08$ in the same configuration creates confusion
and it's not good.

My suggestion is that we either have:

a) passwd_format and passwd_round (so that they don't conflict), or

b) extend passwd_format in a compatible manner to allow specifying a
round, or,

c) make passwd_format and passwd_modular conflict so we don't silently
accept it and instead bail out when doing pwd_mkdb.

 What do you think of the idea of putting this into libcrypt instead
 of pam_unix.c, and then patching pam_unix.c and pw_user.c to
 reference libcrypt?

Which part of the idea?  I think it's a bad idea to make libcrypt to
depend on libutil (for login_cap(3)) but we should probably provide
new wrappers in login_cap(3) to do the common things when requested
for various password manipulating tools to reduce duplicated code.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGmYMAAoJEJW2GBstM+nsDJ8QAJ+SM9WuRCXo1KYERj+/NJsC
VoP8psjZDZ7+hGOnG7iSwREYTLpxSEAw+sPnIhMgEy1Tg5jCcPvnIhCN/n+XPvaR
HG0o0TdTXL5ZVU4HyKuhNH6JGF9sWWua7Ki/jFguqE+1rdmivcbhrHMZNqOy8Djc
N/dnoCD/eN8K2/FiwP+KjTsYeSyisKFMyiGimQNcuPA7boF4ZBgJmmJqPASHzO9M
DVccoVPrDUip/6BdM+CNx/rNTry1sW3lMFSAuJkx+LENgulbhFz5R0aRGglzwGnJ
LocXVCZlTv0QB37qp9VIHCtTO5n8GxOx43dEtgjWF1cjDs+s+iKjEylX8NguUi0x
SjYu5WOw8xXNdE48QtqpT0N5aHSw9+CCwbrocGaOVYy11voGzo+r3C7jXprhQl8a
pgeiXH5pyBpo9Eh7+/aZdN3WcBjpaOVDnX8We7A9my1lVjxyuLXFyhC3q2OqUjvl
dX4ywKIjiFHSOz0ivzi+uQPx6PD05UuyrWUDING2PvMD/oMtg/hHbR5IxOHdmgPq
j7brHNOk7gxu1f/NFft/yfJAKem6JXjlX68z6/9jMrwxZ8jwTWWAtHrVBjo9/u2i
7ShSZlsEi62GewoIKRRVKvKmdX7Xl+Of/p/DZMTNGCJ9K5NnhEnLKWSp+I5VF0LN
fVQkTqpRaXglMVa/iRkG
=xSx1
-END PGP SIGNATURE-
___
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: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/07/14 15:07, John-Mark Gurney wrote:
 Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500:
 On 2014-03-07 17:06, Xin Li wrote:
 Hi,
 
 On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
 Allan Jude wrote:
 
 [...]
 
 Honestly, my use case is just silently upgrading the
 strength of the hashing algorithm (when combined with
 my other feature request). Updating my bcrypt hashes
 from $2a$04$ to $2b$12$ or something. Same applies for
 the default sha512, maybe I want to update to
 rounds=15000
 
 Like this?
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
 
 Request for comments:
 
 http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903



 
This looks like what we wanted. In the feedback you talked about
 some changes to your patch required to make it work, is
 there any progress on those?
 
 Derek's patches worked perfectly for our needs, but we're the
 sort of people who use vipw and our own utilities for user
 management. It wasn't until later that we discovered at least
 one other file would need patching to satisfy everyone.  We
 didn't want to employ the same copy-pasta method, so we asked
 for feedback about our proposed alternative.
 
 secteam@, do you have any comments?  Before we put any more
 work into this, we want to be sure that our proposal is an
 acceptable one.
 
 
 Did you mean adding rounds capability, or transparent upgrade
 of crypt() algorithms, or both?
 
 There are 2 separate but related threads
 
 1) specify rounds for crypt()
 
 2) transparent upgrade of crypt() algo (or more likely just
 number of rounds)
 
 Can't the two be merged...  where 2 becomes a flag in login.conf
 instead of an algo fetch, and then if it's true, it does the algo
 fetch from 1?
 
 I really would like us to get 1 in, and then on boot dynamicly
 adjust the number of rounds depending upon CPU usage... obviously,
 a flag will adjust how long/many rounds the admin wants, but it
 would allow an automatic increase in security as faster CPUs are
 used...

Or by the installer/a tool that gets run when doing
mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster
after installation, and we can probably just write in the
configuration anyway?

Personally I'm not a big fan of making it something that changes over
time: the attacker may do offline attacker than doing it on the victim
system that revealed the salted hashes, so how fast the system CPU
runs doesn't really matter, except for how long a system administrator
is willing to have the user to wait.

 Anyways, how many people are still using passwords instead of ssh
 keys? Setting the time to be something like 100ms may seem long,
 but considering few people should be using passwords these days,
 it's less of an issue...

I'm currently using SSH key plus Google Authenticator for my systems
but all remote login via password is disabled.  I am aware of,
however, many people who refuse to use SSH key authentication because
they don't want to carry their keys, which is a bad idea but they do
it anyways.

 Xin Li, if you need help reviewing, testing, let me know...

Will do and thanks for the offer!

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGme0AAoJEJW2GBstM+nsXnkQAIYplCr5wMtENLYMQCDSrOFJ
7oxKbW2Iy1qPbbrjAb6mG0TY4ugJu2T6Sg6Wp1B+um2sWqWkNMr+8auHokwuB8+1
8NpnbcZarFvmA5tgVEsh+JcAJF1qZRFQDku+DbL9f/ZXFn/4CtmLkw5NS/kIKf/0
TIeXykNie5nFCS8ifT5Ai7vEHImOTwS4OEVzXoTQSdFGuLnHrToCnV7LpOK2ceIo
ssZ/0Go49tSzW8y3u2a0TZYTqMnh+0EzQFusWkulyCIam0NYjYON/3UY0/TpRgZd
ik2QLqKXaMZBPmi4EsmgpQr97MS0PRag4lahZZad2CckZmhiwWrHLyECf0Xk5i1W
+ACqSfJAzq+NeyDBW05y31qALeyUhm7+ALolSMDFkQMj5B7ra8qnQsbXVyG+DLmg
itpCWfXUpKPxclkvirnDQx89BE1MOYGYBbw69IR5NWcvF3f4EF177xplwAMjHhn5
EXUVIeTwjHYoYgMiZKX8aFgyNR2EX/g6JvZS8236HUbskLQl5AAKM0RA4aQkAFGW
206DYokJW3TnXNArm8kKJCZrYAJb17XyzN6HcY89N+GA0oEkehy2qyQiBVqtpjgh
6WsslScxAnQM3LG84un98cdipOWwQerTwfeji1yqfmik5oNuCm4D/Jlt6rvJBFLb
S5fUd1BQv+0woAKndGhb
=rCdB
-END PGP SIGNATURE-
___
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


nvi: tab can't be used in the context of substitute

2014-03-02 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It looks like the new nvi version don't accept tab in the context of
substitute.  A minimal use case would be to replace all leading 8
spaces with tabs, what one would do on older version of nvi would be:

: 1,$ s/^/tab/g

Now, with nvi in FreeBSD 10.x+, entering tab won't yield the tab
character.  This seems to be a regression from older nvi version.

Is this a known issue, or did I missed something?

Thanks in advance!

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTExA6AAoJEJW2GBstM+nsRzIQAIfSS4isLQF4ex8ZzXQyE/0I
6Wia9FRHsa5gYt8phJxvWWbPCFeyHuqRjAkUEk+btuReZUSgEen27848v350hmBZ
DXMaJknryGIU1/f9x/XIjLYpmBOf58tN+rPId6psgFiH7NmdTcfAVg320fdAKlKC
gaMQHA3yGBC4ZTmopdj/e71gqmmjQuPe7kjyOx4fpdUWNKU+llIb5bUB1YWKYzyu
/hBBp8bewWoHjlH4qa0hSK/k6ef8yA8WmFEFldHZMQeXizQTmNxDKURZ9gZGOlYQ
m3mmeatE8KN+XVwn46p+iB9FcJu1dpzPq2QrepiWRzZJkxqOJhmjvQ0ZbZG1A6rM
jjQCRvKRi3PjzRPrGkBhhSZcRYmpNsYV8Anf4mUg5GxbJNKYzHAhKJ+dySc+nvqm
5xccpeGXpw/ji/A5OefoEzQSAhujVaBW5x64J28E7VwY5zw38K20wm0hv+KfWofM
OWc/gAB/1OYh5i+BaEb/O7RBoFIK+19MkJU3LFklBpDB2d8AE7vhoCbE4j9uujwB
8yFGNcl4up2z0ln+YhBYfTo8oc4iq6V55vNJYOM5iARKlQKYlhpPpyFgL+ssR4nY
+hAPSJ8qV2dMNqwdwW7oGhlzAMR/+i/s/TMeHyLCJijEcTpZZB/V7k/I6muzHnYg
p9f4hmB2r2f6/TaUyFmH
=5n4i
-END PGP SIGNATURE-
___
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: UDP Lite support

2014-03-02 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/2/14, 10:42 AM, Joe Nosay wrote:
 On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com
 wrote:
 
 
 
 
 On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net
 wrote:
 
 On 02/26/14 18:52, Joe Nosay wrote:
 On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis
 bro...@freebsd.org wrote:
 
 On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay
 wrote:
 The last thread on this was in 2006. Has it ever been 
 reconsidered or is the likelihood of too many damaged
 packets the reason for not supporting? I'm not sure
 where to put this question. Apologies for the noise.
 
 You've provided next to no context.  What is the
 question?  What thread are you referring to?  If this is
 the usual UDP then freebsd-net would be vastly more
 appropriate than -current.
 
 -- Brooks
 
 Thanks. I will ask kevlo and maybe bring it up on
 freebsd-net. It has to do with an implementation of the
 JACK server using UDP Lite for transferring data.
 
 
 http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

  Looks
 
 like nobody proposed a patch?
 
 I think the concern was that this is not very useful in real-world 
 scenarios due to link layer error detection mechanism but that
 doesn't raise a red flag to me assuming this is sufficiently self
 contained feature as it would improve compatibility with other
 operating systems.
 
 Cheers,
 
 
 https://github.com/torelizer/jack_trauma
 
 Not my project;  but, I want to port it to FreeBSD. First is to
 get it to build from source. Use  your raspberry pi with FreeBSD
 to broadcast your tunes and all.
 
 
 
 Thanks for all of the input. The project is being reworked to
 improve the code.

Kevin Lo have a patchset but needs someone to do performance testing
(its impact on non-UDPLite applications), test with vimage, etc:

http://people.freebsd.org/~kevlo/udplite.diff
http://people.freebsd.org/~kevlo/udp-v.diff

Are you interested in working on these and report back?

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTE4+mAAoJEJW2GBstM+nsthoQAIW67l7yDfIPvxDsNIWWJcRd
8brFYCAOPYE4LpuLGjtSgy370aBe9JmwAm41tE4qF0WhGpcu6TLsKjgMGWa/lHCc
JId8+WBfbbQT8XJj/d+3oOETn5/rglvlRhJbnNIwaQpTXxuMC5oz2nGW7rIpIkaA
OHo0D20DzGj4nxrQvijZ7DsMkk3F+KJu/4p7M6lpsIPCakknW1WD7IHRfbZ4Oldz
2xH4HfIk7cAdA7i/YUNjlpSgWFQ5OU03J5HAYfC6W37wiGbjdBYf/PKVhJ8hz7+D
OCl+yCV00u4fCjlY6zXFea9pGr7Cl1P+sapwKDZ4g+NpNHxBUVY+ahbjQUHYON2W
sdzAsLpMMqavCr1o8mcXdm7IPRlLUK9QZUySC9DitPvoF8G2llTAz1mWa4/Oj7/S
JMiUERcaL5gdFN8EgEKkamFgLJguYquAjGtiowa51EMbnZG0Q2yWUcrEBFHWBEZT
RW1u6r4ChIrPE9X5ljfFpQyKG6jFhYFXG+iVlgTB7F2ZWhjPAXi/tLbBnvIcci1m
Md4XFm/bBJj/yNXdPuCi+CtvvdpZ/d4LQn4B7By5bIo1QjCb4Zx5n2Tq5xnYZUOI
CnSVnNSkwLbbrAVtYOVWnrSuwR33JQnqeGHdM+XYBBwKBRhrx+ZgFWD7N6Gm95PU
xXSxkgYVXI4sgi7Lh3Ia
=2Vmc
-END PGP SIGNATURE-
___
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: UDP Lite support

2014-02-26 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/26/14 18:52, Joe Nosay wrote:
 On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis bro...@freebsd.org
 wrote:
 
 On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay wrote:
 The last thread on this was in 2006. Has it ever been
 reconsidered or is the likelihood of too many damaged packets
 the reason for not supporting? I'm not sure where to put this
 question. Apologies for the noise.
 
 You've provided next to no context.  What is the question?  What
 thread are you referring to?  If this is the usual UDP then
 freebsd-net would be vastly more appropriate than -current.
 
 -- Brooks
 
 Thanks. I will ask kevlo and maybe bring it up on freebsd-net. It
 has to do with an implementation of the JACK server using UDP Lite
 for transferring data.
 
 http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

Looks
 
like nobody proposed a patch?

I think the concern was that this is not very useful in real-world
scenarios due to link layer error detection mechanism but that doesn't
raise a red flag to me assuming this is sufficiently self contained
feature as it would improve compatibility with other operating systems.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTDrzbAAoJEJW2GBstM+nsJVoP/29XRcleHMnAVa1UOG0+CD2y
0e/pAmk5vay599gjmiKSAuTSeKNaawRF3FZP+QsxhKw/lNTYEHlppUw7FDc01NqO
pk1GsIu+mVuLlzZBNSuAkXdMMzJz5OKfY9GeK7Uw4iumiNP5LKpoC1RaYqLVASGf
JH6tqJdSVnD+apWxV/PF4orCXZECFLkQZhbgZe+2nni+te6OfzIbkjhBqn8ZIDNY
m9GbYwkTEATBDcMGgl9F0wBfcLhQLF4p4+TnsCguP0HAbxCtbZmt3SXe6Xt4y2YE
iHlO/qstGKrl61aiehtpasjiljJaN5ucmuv8XDGbix4cghiJCJAGmxXGxCoHs/Uq
vkn88wfV901pjYWPWf9HmTdjSmsck0k2+srWYlJuRymVKvMsL2mwPky+QL9SZ6MY
NJ8kXUl5szFwdN4OtO+1iUvVZNLkVDlV5bmnc5KOkciFRoLuTq1/f/xzGj/YDZpx
2DxjddVyvJ6YhrUSSAGoOcdxIpDejKfVif0ANoocsKLAnTHtNxdB76doJH4wBl+W
LAl9a9IqVOiefFe9qb6tZky3lft3HUe4XvLJPraKTfbvA9VAKPqZbc2Z8eeoqb49
LPC2n8WnlnaXB9KXKSWTLXbdcY2L+HnAt2+DEv4viSyKSXQg00aEbm+R95h1pTz7
oMv/8VGg5akyRQtkTTIx
=ukUF
-END PGP SIGNATURE-
___
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: [head tinderbox] failure on powerpc64/powerpc

2014-01-01 Thread Xin Li
/zinject/../../contrib/opensolaris/head
 -I/src/cddl/usr.bin/zinject/../../lib/libumem
 -DNEED_SOLARIS_BOOLEAN -std=gnu89  -fstack-protector
 -Wno-pointer-sign -Wno-unknown-pragmas  -o zinject zinject.o
 translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs
 -lzpool /obj/powerpc.powerpc64/src/tmp/usr/lib/libzpool.so:
 undefined reference to `atomic_swap_64' *** Error code 1

Sorry for the breakage.  I'm testing a fix right now and will commit
once validated.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSxLupAAoJEJW2GBstM+nsYnQQAIlQhsYIff7FuDmD363hHi30
tbCXGPz5gonV6NYQ7tPGD3ododeUdMUXNx10y1e7f/7oG4qKKm787/RPUmaY5aeW
Y3CheoEEWvOIHMSR0HgSX4yc+XoND1LLLRdUn5diUG8AdQ6dCcK0m65E805Z7zpI
B6Yk6TBH8sT6kGIgcLUDTf6+N5DpymKyNcHGSRoyfJi88e6tHtmse4l0XLrfWklk
KWpw91qAQmdPuaUM6xUbOgHDK0G5xwI+Zcx/OyUkQ3NiCYFm8oO/fM/vTKgAerW5
sEFh58CgBWCr8RUVsBwbyeeZ/T7yKFPs53ZEMj2QZxpQzgRhz6emR1O0PxrRfgRC
H//VFSarhbuEtb4j17LLSby/jyBDjoc7vEC/MuoE28ovOF7ZlXF3OdzwsOtB5Q/r
nU+j/QmrGF+vmNh4FCr3sn/+yPdAxHoGkz9xyhBU7Sbomh5SJSjXxzS0D8uPpXIj
orxsl6itEUX2L8BdMJgx8ZpZaj/gB+XnYOxv1XYKovHsBUwHVw8vv0cwI6rfltKA
EvczKl/lkfu4SYeRtSIX080Id9dIihBSXVgOQ0nL813fpFfqGBaBEJd7MU6UDmAx
eNqrWJO6DU4lteFzUvBOqPsvXus9vppsm9GY/4OgC14b3PZYE/dXEsZSuz+JU9u2
0ynVIiFYxaI6RXR/pxjd
=lHMA
-END PGP SIGNATURE-
___
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


[PATCH RFC] Disable save-entropy in jails

2013-12-24 Thread Xin Li
Hi,

I think we shouldn't save entropy inside jails, as the data is not going
to be used by rc script (pjd@126744).  If there is no objections, I will
commit this changeset on January 1, 2014.

Index: libexec/save-entropy/save-entropy.sh
===
--- libexec/save-entropy/save-entropy.sh(revision 259828)
+++ libexec/save-entropy/save-entropy.sh(working copy)
@@ -42,6 +42,10 @@ elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf 2/dev/null
 fi

+if [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ]; then
+   exit 0
+fi
+
 case ${entropy_dir} in
 [Nn][Oo])
exit 0

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
___
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: [PATCH RFC] Disable save-entropy in jails

2013-12-24 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/24/13 14:36, Paul Hoffman wrote:
 On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote:
 
 I think we shouldn't save entropy inside jails, as the data is
 not going to be used by rc script (pjd@126744).  If there is no 
 objections, I will commit this changeset on January 1, 2014.
 
 Even if it is not used by an rc script, it might be used by some 
 userland program (running as root, of course) that knows about the 
 directory and wants some fresh entropy for its own use.

Why a userland application would want to use these?  Would you mind
elaborating what kind of use that would be?

My understanding is that the saved entropy is used for bootstraping
the system only: any applications that wants good random numbers
should just use /dev/random because relying on something saved on disk
is the worst way for someone who wants more entropy.

 Is there a problem with saving the directory in jails? It
 certainly isn't taking up much space.

No, it's not about space.  What I am concerned is that it may have
wasted entropy: each time (every */11 minute) the system would get
2048 bytes out from /dev/random per jail.  This deterministic behavior
may trigger reseeds earlier than wanted.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSuhBlAAoJEJW2GBstM+nss7YQAIYcMq6GflgY7T304J+bdoll
TBYA740eQy6iNoyGTSh4VEeKh5GDrwX7GAM5EshrDQMKfagwm0smdYbpWYklUc07
V6sy8uuIvhxM6GOxQqP86tyzMCu9EtiVzfDakKJz1IL8pzVuu6Kbq/CxdA3fC3G4
qQraPMHvpYRsXiOn30B8i0kojMgRAxMOTZRZ4HRByiuZrsVdFYlNxMoh76reMO40
dSq1UPmQMjeDqlEKkAxpR1nN67ebVgFOuXl8O/YjOvNJLnCtcEr6xQcUQso8cbeR
j7WCgUmiqCKcoPcE6Bf43Qp1otdeLVP+qoeogWcAPIPrK6XL2wxsVxj6Y44fbkeW
Ttfw5iXwR7yt7MSZHP4eXdycZuSRswQUzp9TEyAxclMTE+aHFd0B/C4lViTKTfU1
dglg5goplXCAVCFPXek+R9UnFCFSc9GvlSL2K2d5TNvjDiVdNGc9SDyO7u0qNxV5
Eo+X8W2oR05jiZNHitJyalZSWd62+rn5+R5Pwf3A0hv9opimNX2xVTpfVU7y7DoK
dJpPo7S8GvVKK0JgnP9yOvAD2wIjNnLz0T+hmmnygPA+xkrbVZIYdxMxrMQ491Dm
/3dej3hDg5panfU7kxjpVmA+mTQbaFwQJeV0gSJDeswBl8JeAwhycchA+rgpPWCN
qEziEr9sgMQKdc6JyVf9
=b7jA
-END PGP SIGNATURE-
___
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: [PATCH RFC] Disable save-entropy in jails

2013-12-24 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/24/13 15:26, Paul Hoffman wrote:
 On Dec 24, 2013, at 2:53 PM, Xin Li delp...@delphij.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 12/24/13 14:36, Paul Hoffman wrote:
 On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net
 wrote:
 
 I think we shouldn't save entropy inside jails, as the data
 is not going to be used by rc script (pjd@126744).  If there
 is no objections, I will commit this changeset on January 1,
 2014.
 
 Even if it is not used by an rc script, it might be used by
 some userland program (running as root, of course) that knows
 about the directory and wants some fresh entropy for its own
 use.
 
 Why a userland application would want to use these?  Would you
 mind elaborating what kind of use that would be?
 
 I don't have a specific application in mind, and certainly not one
 for a jail. However, I'm not sure what the value in removing a
 feature for a jail if we don't know if anyone is using that
 feature. Thus, my question.

I see.

 My understanding is that the saved entropy is used for
 bootstraping the system only: any applications that wants good
 random numbers should just use /dev/random because relying on
 something saved on disk is the worst way for someone who wants
 more entropy.
 
 Quite true. Note, however, that we don't delete the saved entropy
 after booting and add it just before shutdown: we leave it there
 for some reason. I'm not sure why a jail is so different of an
 environment that it should be treated differently than a normal
 (non-jail) environment. Maybe there is a reason, but I'm not seeing
 it.

Definitely not for seeding some userland applications :)  If the
application wants secure random numbers, it should rely on /dev/random
because it has more entropy sources and is less predicable.

 Is there a problem with saving the directory in jails? It 
 certainly isn't taking up much space.
 
 No, it's not about space.  What I am concerned is that it may
 have wasted entropy: each time (every */11 minute) the system
 would get 2048 bytes out from /dev/random per jail.  This
 deterministic behavior may trigger reseeds earlier than wanted.
 
 I did not understand this. What changes in the system does removing
 /var/db/entropy cause? (If this is answered in a longer article, a
 pointer to it would be useful to me (and maybe others).)

No, we are not talking about removing /var/db/entropy.  What I am
proposing to do is to disable entropy savings from jails.  Here is why:

The way a PRNG works is that it uses one or many entropy sources to
feed its internal state, and generate a series of pseudo-random
numbers from the internal state via a PRF.

FreeBSD collects entropy from several sources: Ethernet, interrupts,
software interrupts, etc., as well as hardware RNG that is available
to the system, and use all these entropy to derive the internal state
of its PRNG.

When reading from /dev/random, one essentially consumes entropy that
is fed into the random device, and eventually it would cause a reseed.
 In an ideal world, we would want this to be less predicable and
controllable from a potential attacker.

Normal applications tends to read /dev/random in small bites, and do
so in a discrete and nearly random manner, assuming we have a lot of
processes running.  Saving entropy, on the other hand, happen in
larger chunks at a determined time.  With multiple jails running, one
would have a lot of big chunk reads from the /dev/random device,
making its behavior more deterministic, which could have bad consequences.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSuiElAAoJEJW2GBstM+nsW8wP/iJOuLK7gl4xcaZ0WQM9ZbcF
dRo9Wuao4aytIPNcI7BcRvFPkQIVd/N6tIwmi98Uy3vLG1FAkZlSkPT9IXGWKwtX
lil1tfPlGt4+lMPirD7AFkk99DUfMO7nY2TuWw6DG6w6gfbzoBkZfxEZTTBv5XXl
ZtNMsw2CR6xOOY2YTx3HobSnnr4UzwBzT1nif+7W/pYTwQB2LNbnwnVqoDsGn9mv
MMO/9WnYs3/smYDQdChmmybGws4/P53sGjIzds/dv3Gg8ce8fu/ZAPFGCKRzr+uL
CTBCBuaeiRM/BhlG3n6H0o4updgDAOQ0PDH0q6rMXwcg7ODz6tW2x7lJ5hwm/Z2B
nrPCr5p2jk5KE8ULjINypYyIgjbPcgDTZN2ToB+a83RvIf9/DlRMzyOA76b0KsEs
AnygLyG/ZoBqy5s4nrNbLyNERx2T7hrcrGtK4qtMIdpYQK8T/etZZvIebLVPvCGK
kGG9AEgiUYHgG0RASg0LtsiJLi0/LjGzwZl+/Q3lqjrcmV7m6jOLAMT349aWOep9
GXPOcBXxh4emEz2qAQRSn7Y+Xn0T80lIPHb/6Wz04pOIhlMwQPR97X+IfAtybHFf
7HVk4GfhQC/zDiwPKb5Qcx7JRnE3wBZ2vnVaVzPCk9uPImyvMYKDKiNfFl2zlFfS
AdjiKPaOGw2kAZA55dC3
=7Ruf
-END PGP SIGNATURE-
___
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: 10-RC2 current wireless link aggregation not working correctly

2013-12-17 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/13 09:34, Allan Jude wrote:
 If I am am understanding correctly, Dan and Nikolai say that just 
 running 'ifconfig' brings the lagg back to life. Why would that
 make a difference at all? Running ifconfig with no parameters
 shouldn't be changing anything.

I don't really believe these claim.

I had similar issue in the past and found an 'arp -a -d' would fix
it so I didn't pursued further but I think this would be an
interesting problem to get addressed.

If I would take an guess, I would start from making lagg(4) interface
to initiate one or a few gratuitous ARP broadcast when the active port
changes.  Some switches could use this to kick out their (outdated)
memory of where the port is.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSsPQLAAoJEJW2GBstM+nsyXoP/RCeHdu1PVCooIUxzjhqWMJG
3RyN9i85O1WYpgZwHCSC9mkFKM6GjEIiyaNKCvdYzN/k+d9aCQSXIShgIGutM6ie
hFD4GCGrevjquHCddpULlUE+iwj0qIJWSyRMusUgo+ya+Bc/4H+szoxTndXaaamz
CPkZMuzga8kEApXgMvImGfsqB8FqqFNtEELlRmISEHb04iAGqUv6HwoL1DhqEZ3I
tQQi73JvuCU3Lfbp4CDI0IeTzlAoARBX/mWFjlDm7CA8clu4PzIVhdsRxRUhXIId
ijI8432al9XXt0m4+4LIKmJa6DlyvQ3pIZDFodryQ1za3PAaF7IheILFKPi9BAwi
Tn47X2+2XYXx7ZS2S22R7KRgeORZqj2uYZifs/xsNwkBCsyntYZgH+c5qYU7TWb/
tWRi9c5uVFskoPx4JL4W3ctgPvN7TpvKeCBLZTBdLQjy9WT6sqhxChxS57SFT5AH
kTOWNEA0PqWjrrqRlNO47TL/aTg3Js9S4KxIZ2+hHSkDAlMxGi9rHzyHYPQKxJ1V
lLmLGN0ZRYGGKa4Yn2OBAy16q/I2jkLE0Nkb0u1V3EEMkKQWp6pcro/Kb9Hrirfe
n6zrFVyzLTIgNpr9C1+By1CxAmJfg73cIoobJSjNDZ2+EpY+FRDdhKYip3xtpNfA
QFmabonocmaEohNcC8me
=mSYS
-END PGP SIGNATURE-
___
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: 10-RC2 current wireless link aggregation not working correctly

2013-12-17 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/13, 11:28 PM, dan_partelly wrote:
 
 What claims you do not believe ? Not important anyway. This is 
 engineering, so you need not believe, you need to know. Go and
 replicate the bug. You will know then.

I don't believe in merely doing 'ifconfig' would workaround the issue,
it does not make sense, plus I have tested and it didn't work for my
case (iwn+em on my laptop).

I'm aware of the issue but thought it was compatibility issue with my
own weirdly setup wireless AP at the time, and looks like it's not
just me, but I'm not interested nor have time to fix the problem so I
replied the thread and offered what I have tested as a workaround in
the hope that it's useful for someone who is interested and have the
ability to fix the problem.

Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSsVEkAAoJEJW2GBstM+nswTsP/Rs0hdyXNejf2Z98GbSGns0n
lsI+UmjwWUSg0h+8QzCce7/80mwEw0tZH1btoRr6I0tPKXwdUYDO2C3LPM2a/jSV
hvN6aay0ppnldtsqMZcuDv1OznSGfEIt0A04/m/RUTDBYaPKY+F1iqZYNE960zes
u6mbR2elpAUCHjpV3lEchnP5V1v/yLpVziGYabR4WLwohtlOMGVbL92ejLAeKVnr
Ar7SiWA7GVar6lSGBWyyGwoErveb8TaZxRiSKgjHuvciMLgy+KrlyxqZq6gNd7nP
isBDMEe2NsnUawR/gfcxvvzpyHTPYPtSlEJjejdbnGlP4YGy5BT2vm3HqyAgK/iX
N1iRBhx8zuH9UDNN8XiSuvuYuxAw9OfeBoh/2aGifj5dcrEP+IeyYUoAWBoXgny+
IcoitmUwYE4xLduLnIpf2b5KG8Yw1r2bKoZJVOw8+ixJAqCWR0xXONcywB56MXoE
8r9A11D6ASdRmozKjcEQH9+j6/4VuVeydCBfXQSZHIlVL3pTFZAlH0Q0JSZq4NXA
Pb5YGcdYDONi3gPxNIvUn1WeqTfpgJhGveKV5PhI3NY2d+GEB3fBBuBhvlAlrwxg
CPCqH4YC0sntvqMqcOooz44OfiLpB1ARGGTwtKATLNIzpS/iMsS1swW1NZEeaN19
uFZw/dY3w5uhDQ7u2Buc
=4ByJ
-END PGP SIGNATURE-
___
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: [PATCH] Haswell Kernel Mode Setting

2013-11-11 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/11/13 14:29, Neel Chauhan wrote:
 Sorry if I sent a similar patch before. It didn't get accepted so I
 am sending one now. Enjoy.

What does didn't get accepted mean? :)  Since this looks like a
PCI-ID only change that do not affect other existing hardware, if it's
not an explicit objection from a reviewer, I think it's Okay to just
go ahead and commit the change after a reasonable timeout instead of
waiting indefinitely.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSgWqaAAoJEJW2GBstM+ns7pgP/iTu4VI4UYgj/nCmSblhVsjH
kO+YPaBoXkO+3e7GQ+E6LKqnH3Byjvc8WZH6/fBA2qY9Kfjjte0gJIG8t7Fu34IQ
SRiQaErRYUyXCHIIfgjrvRVIrk7bvwe70awnMVQOIktmzdJ4i6cxxEzsvsLqd5OY
Argc77bBkSSa0w/QiWR04bG119u/WVyEhNnJ1XdYq3IzJqTb/fkOYAHm/JaWkhSy
F8Vj2bxSr9fiKD36wb/kV5cFC4ZNP/SounurAhMTMaHfWAGJE/KuUy5aRP0bHzOY
FwcpAAqIsuy13tBKXXsDNgETTJrbnSGQp7AM7BMZJXkX7kfX8SIfpmG0rjoJH02G
V3SDdvMmS/x4sIrKmgwQsUT1MGNGdJtD0Xzx27ng0BVSItPKXkB1azxvRkfRE03N
yyWX4C0IQg/U/UgkV3jwe+8LAezPXNRbnKD5QX165g+EnAkRmferAT1/kNnV1zV/
G7eU7x9TTml8fCi0g5Oid3smL+BiwGOkZA36r+Js+lQd5Pmkn3GUJw1qx3vNTWKz
P6UHeRzSppez1aWx6NigvPH9qUz+HpaN4aWf+Zzl9MFbKcEohtzT8LaBCB/F1BdG
pvGOXcCb+BeUy/IBW+Yx7zal5Ri7YIRIAb2hssqACVBOYwbVzMQidEWuSERMyNdo
gMcNWZw+kXLE5wCklwm9
=zbWH
-END PGP SIGNATURE-
___
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] libdispatch (aka Grand Central Dispatch) in base

2013-10-29 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/29/13, 7:40 PM, Julian Elischer wrote:
 
 
 On 10/30/13, 10:33 AM, Allan Jude wrote:
 
 There is a wiki page that provides a bit of information:
 
 https://wiki.freebsd.org/GCD
 
 But it seeps the last time the port was touched was over 2 years
 ago
 
 
 a lot of people over the years have indicated a liking of it in a 
 general way but no-one has had anything that needed it.  Launchd
 may be one such user but efforts to make that available stalled at
 the same time. The anti-bloat party seem to have successfully
 taken the momentum out of any moves to import it on the if we
 needed it, we'd have it argument.

Simple -- create a killer app that depends on it and import
libdispatch altogether :)

Cheers,

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJScIjWAAoJEJW2GBstM+nsq7QP/1vftsUVJqepny99ICB67ywQ
6h7PFdNkZIDPd6Dj/BVfbpusDe7lsxaeRP9AxnFVwWJ+raqG8Xgd6DS+UGym5Az6
M/TUjbnfU9U+BUQI5vq3oYhjZlGg2MqpCPiDj1tBWMaAIu4iI2qVcl77rW66qH7B
4Z+gay6cOoBzgKS9qgc/cWOV2+ff946Rempjtknumk5Mlu4MxLx8MThzWj+Ly3fW
H+uScYfEIdMOQrEU2qQaGAkF9u/RZsToFKn2Z/FDaedqcJifoeLwZvLnfl3jrjjL
5spcZflpM43bKOPNLqgmIYfWtxARoqyMFLsLrTZDZGq/g7Ieitz2nLL4nDfdbm7T
IV/OILb2e/xVm2aKuBhBTrDXV88upSOnGzBBVMHWj3U0HL+OEGyw1qkN2t/LFECj
+3NXyPTdiLQcKoDtMWgTzwN8gBIWcSd8OoYT3u++hKeGsARoYF+QkBX3CAvuwd/e
1Ep5vVdatNhnJBXr0kEia0x9XphXu+9cCFJqlIJzThbJlAzHWDhC/7zRqsqYR6bb
oeA9gnjpiR2D+a61eUvb0+9Pp91mL0X8gljQH1dcipJSFE1emoCzgsww3uwSAwwb
zUMW6kS8xATQCuI2NRSOv7tEx/DiG9I6URoij/QKJOKZCjtpH7To+1J+yERO5Wz3
h4sVc38uy/JGWDccdd9O
=Si87
-END PGP SIGNATURE-
___
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: ZFS txg implementation flaw

2013-10-28 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/28/13 14:32, Slawa Olhovchenkov wrote:
 On Mon, Oct 28, 2013 at 02:22:16PM -0700, Jordan Hubbard wrote:
 
 
 On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov s...@zxy.spb.ru
 wrote:
 
 As I see ZFS cretate seperate thread for earch txg writing. 
 Also for writing to L2ARC. As result -- up to several thousands
 threads created and destoyed per second. And hundreds thousands
 page allocations, zeroing, maping unmaping and freeing per
 seconds. Very high overhead.
 
 How are you measuring the number of threads being created /
 destroyed?   This claim seems erroneous given how the ZFS thread
 pool mechanism actually works (and yes, there are thread pools
 already).
 
 It would be helpful to both see your measurement methodology and
 the workload you are using in your tests.
 
 Semi-indirect. dtrace -n 'fbt:kernel:vm_object_terminate:entry {
 @traces[stack()] = count(); }'
 
 After some (2-3) seconds
 
 kernel`vnode_destroy_vobject+0xb9 zfs.ko`zfs_freebsd_reclaim+0x2e 
 kernel`VOP_RECLAIM_APV+0x78 kernel`vgonel+0x134 
 kernel`vnlru_free+0x362 kernel`vnlru_proc+0x61e 
 kernel`fork_exit+0x11f kernel`0x80cdbfde 2490
 
 I don't have user process created threads nor do fork/exit.

This has nothing to do with fork/exit but does suggest that you are
running of vnodes.  What does sysctl -a | grep vnode say?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSbtlWAAoJEJW2GBstM+ns1BgP/iD89HXV3g/c4/GliMG27yB0
WMoWJVDvHmzvRuHBMC6rUIqvyfSaK4EdFDK2jYUIM9qQwWcrSXRXIDBLNE/5MHwl
FgcsaBlFaE17bMwzWrZRCzSb1YMxHXmHG5e10YrGUW8TKkGBVtDD6SIMVK8xg6SQ
5HM2HJR8BVaB65z4S1tLxA+VIqHitUZ0/kTME6X1Z+Y/CwS29F+seXk1DlDYNZM3
W3UVTxJnVwf9HhHRvx/kDtPIPeuIz0O/M5cgtbYq78wjG9Zim6a8SWpuxKeduDoT
CTllgyEidc+vtDiEiksRsja3ATwynzjLGlNribnMKP2U4KMu9qfVUXDse3wwKKXa
+f9Yfzg+fif3r6d/hdlQCtHJhjNlqfjDjCXHHpuTftLU2ONpj9hwKYKOqp6ykmt9
Ok2QziXqBxRMVXJjDAOybv8P1zCAcTpRtvR25bbE7T0M49dvVw51CdAdX8m8nJR+
tX72r+j4BeoNflQWqSsG8P9ao3AuOk6jGgXdtngbbpteyplaVqLragFo8shfUNmY
dWaJp46wUq3gaRBSO/4CkzdyWl99eTTOAW4/Zr78LuYT5wN7FL590AAT3Jmc9N4Z
edZsR2a8VwluLAVuJNqf9odg7MW03xxjKKf9Wm/I112XtFHDg/dCIrdf4cWc5iuA
SvGKci6yZfy5e6hj+ZH5
=aVMu
-END PGP SIGNATURE-
___
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: ZFS txg implementation flaw

2013-10-28 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/28/13 14:45, Slawa Olhovchenkov wrote:
 On Mon, Oct 28, 2013 at 02:38:30PM -0700, Xin Li wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 10/28/13 14:32, Slawa Olhovchenkov wrote:
 On Mon, Oct 28, 2013 at 02:22:16PM -0700, Jordan Hubbard
 wrote:
 
 
 On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov
 s...@zxy.spb.ru wrote:
 
 As I see ZFS cretate seperate thread for earch txg writing.
  Also for writing to L2ARC. As result -- up to several
 thousands threads created and destoyed per second. And
 hundreds thousands page allocations, zeroing, maping
 unmaping and freeing per seconds. Very high overhead.
 
 How are you measuring the number of threads being created / 
 destroyed?   This claim seems erroneous given how the ZFS
 thread pool mechanism actually works (and yes, there are
 thread pools already).
 
 It would be helpful to both see your measurement methodology
 and the workload you are using in your tests.
 
 Semi-indirect. dtrace -n 'fbt:kernel:vm_object_terminate:entry
 { @traces[stack()] = count(); }'
 
 After some (2-3) seconds
 
 kernel`vnode_destroy_vobject+0xb9
 zfs.ko`zfs_freebsd_reclaim+0x2e kernel`VOP_RECLAIM_APV+0x78
 kernel`vgonel+0x134 kernel`vnlru_free+0x362
 kernel`vnlru_proc+0x61e kernel`fork_exit+0x11f
 kernel`0x80cdbfde 2490
 
 0x80cdbfd0 fork_trampoline:   mov%r12,%rdi 
 0x80cdbfd3 fork_trampoline+3: mov%rbx,%rsi 
 0x80cdbfd6 fork_trampoline+6: mov%rsp,%rdx 
 0x80cdbfd9 fork_trampoline+9: callq  0x808db560
 fork_exit 0x80cdbfde fork_trampoline+14:jmpq
 0x80cdca80 doreti 0x80cdbfe3
 fork_trampoline+19:nopw 0x0(%rax,%rax,1) 
 0x80cdbfe9 fork_trampoline+25:nopl   0x0(%rax)
 
 
 I don't have user process created threads nor do fork/exit.
 
 This has nothing to do with fork/exit but does suggest that you
 are running of vnodes.  What does sysctl -a | grep vnode say?
 
 kern.maxvnodes: 1095872 kern.minvnodes: 273968 
 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 62399 
 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 10680 
 vfs.freevnodes: 275107 vfs.wantfreevnodes: 273968 vfs.numvnodes:
 316321 debug.sizeof.vnode: 504

Try setting vfs.wantfreevnodes to 547936 (double it).

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSbt2BAAoJEJW2GBstM+nsknMP/1QQQ0BHJOu//nG2M2HnYGsQ
bS0he2xdom/GpPuMS3AwGYYwZTWwauGwr3c2K4czW5AzghNDxpVfycobuGeWVvcB
mvyBgkGhxy33nxVuw9hH4FJW62vJc9sJKlgg5QNQhER81OpCBS2AcVv7qNNtj9f6
svZrhu6X28maas+JnwSr5U82gudC1uhHD3h1pZqc+ogFiEgHlQOoL3Pl6SrpTKUZ
WNFnKd9xWQ/28n26r+jzQu9SlTSStKNQcZiCsMO/5TcGs6Ul8Ft2pS0EKYvVMdVF
poPLItT7qa38nM9BXZYNiESIoZpe1coYXX0en6NMTa0q7JerN05tk3d8q31Rn/Hp
toodJuZB8zA+ZN732s295G06j9gDbSj/iFLumV/0s9OHMVT5lgqVjxmPurmjE+ay
nnPrTDpO3Ef45nC6Gb87yN2ML2GG40de5kYWtieLFt5aSJhQjvmDA+zOxdC9orrh
raspOHfgysvSh8ykaS9SsNdzgEJr5TTzbxh91Ft06e65TEdIzX9HhnqxOLBT+lC1
E6OKYVuU1rLjZPPTplCFI922JbyKEhSc73Gu03zPma8cJEzP/ztCxm/Jv0PrV+4b
SzphVQdMbUr2TMKAUIJXcCwHSWhmqmODoDcHoTbC0kBAqyAbaTCZ8PJaR/A8
jxbZvQV8dGjSYu0LVhnT
=3Xt/
-END PGP SIGNATURE-
___
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: rcs is gone?

2013-10-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/07/13 17:42, Glen Barber wrote:
 On Mon, Oct 07, 2013 at 05:36:42PM -0700, John-Mark Gurney wrote:
 So there's no version control in the base at all now?.. When
 did FreeBSD decide to move away from distributing a usable
 OS? Why not just distribute a kernel and a few bits that are
 barely sufficient for the initial set up, and then make users
 fetch everything from ports?
 
 
 svnlite?
 
 cd /etc svnliteadmin create svn svnlite co file:///etc/svn . 
 svnlite add rc.conf svnlite commit rc.conf
 
 instead of: cd /etc ci rc.conf
 
 really?
 
 
 No, not really.
 
 # mkdir local # svnadmin create ./local # svn import /etc
 file:///$PWD/local

There is a feature that is lacking from svn: the permissions is not
quite tightened up.  With RCS, for instance, a mode 600 file would
result in a mode 400 ,v file.  With subversion, everything is
dependent on the current user's umask.  So let's say the root checks
in master.passwd, with RCS, the resulting ,v file would be mode 400
but with svn, the local cached copy and the file in the repository
would be both world readable.

Of course, this can be worked around by chmod'ing all the toplevel
directories to 700 or group accessible but it's not quite convenient
and can be easily overlooked.

However, even when I use RCS pretty often, I don't think it's a good
idea to keep it in base system (actually I am supportive in removing
it from the base).  The version shipped with base was not touched for
many years and shipping it with base makes it hard to use a newer
version from ports.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iQIcBAEBCgAGBQJSU1y2AAoJEJW2GBstM+nszXkQAKmaSZVELYkQY0i6SqeWXRAd
gOONugSTFq1jMS0fd7LVkrrcGsFa1VpMOf4FctS6iWK1cY8ZJhqYizsu4Qb9eP5e
DciRRtcB337VX3iBAN9vJEgLYiyj7X6RlvspGVJW00QaJFmgrbLuMjkFGxjs/PYN
OVDaIEZCW7FmdHXSbsX7nTiWkWkh/UoMPAzdNNwb+ICKrQB6iWscWBOVQWhufSQZ
mEJr/3exbu9We9kBtk8Qa9pnHYw5Xao8jqNyESORRtDnrznK14Dyc2jdr61Bnlc6
nRGioYhViioVt6x3FekKszZ5/zNr39/Wm+Xv/RNLbhB8SlyEcXjSTfIGByostI2B
r+GibrjOiIGPwntNQcvbm2gwaDaSoWo/xKCeXPoOAViolIALUTkxKlZ7h9qYuoZp
h4rxgENtJlAdKH1SNrSPAaMPnyTzD5GBz2VWN9QGo2TPyxC4NywF/tN0Hz/WEcRN
ruEQ+E9bG0JiiffIo1OJQLeaLp2yTStqgPJG9jYg2e7yfK+Wa66U40sWpWhdIvPq
K5xDtPb01Q91V+J16V++qJPu9uq4rnO7Rk5Ak1vFGRXYuvPHpMovnKKSDO9SaGb2
DXIfTDl4rWTn/WV9o0lriZJyqP31z4ABN47nMc0/2b2+Z1tKLwbaJ5btOHkxFBL3
dJUp+dP1IeZCeESiVBlL
=6X09
-END PGP SIGNATURE-
___
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: rcs is gone?

2013-10-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/07/13 18:37, Adam Vande More wrote:
 On Mon, Oct 7, 2013 at 8:30 PM, Adam Vande More
 amvandem...@gmail.comwrote:
 
 
 I would like to see RCS remain in base as well.  Many enterprise
 distro still ship it by default too.  There is no compelling
 reason to remove it.
 
 
 I sort of retract that statement.  I thought the base RCS was
 already OpenRCS.  I support the inclusion of OpenRCS.  That
 functionality is very useful and many admins are used to having it
 present.

I thought about this a few years ago but figured out that OpenRCS have
many incompatibilities with GNU RCS (and fails GNU RCS regression
tests) so if we do it, someone has to sit down and make sure the
replacement have at least equal quality.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iQIcBAEBCgAGBQJSU2OFAAoJEJW2GBstM+nskxIQAJtRPwPA2S6FIYyPTsKbVgfE
yYI0+yh1MBPssL0OYGLOC4r4Ot/dleCAMJMDSm/yZL4oj2ewLU3TCCq+0g6nvdAn
32ElrfYXKDYLWXManTx6ZUO4EsEPWQTyd9oYQA7x0yWJus4FirR1jUJ0PqHS5TXJ
BcDZFO+BAN70wgR0NJZqUjXML+Z/u7lXEGwDZ27PurGtrQUhQ+QpauPTYQxAqkT+
X0GqxRDwt02zDUWo3zitDoMUqRxWXB4AzOaVDhbs8B2aLIIhNHOYjGytE0gVGOb+
GitDib13B5zEFYb+UtTOKv5dfvUMNNa8XIUAX4zD9uNP3ckEy5ZzvS65+n4ClInX
2eyeaVznnntTSNmjzCZSTKYXhxwmUSyeBQWTGVZk/o+m9qeFMv3cHGSXND6WWqJ2
2IYhX1i6Gj1gllIAIJ6PZ9/fScMz7GcZC9940xfnQbgF61A2+Rxrv/B44w6l/xeM
sbLBomqozJXJ1d+9qo1x7tgl6EP5grZQGtSdLBlao936/PhzCCgwoHNkMiypl0MD
jTlDVyvjUidfavL3rbhmf92x0ih+yNfoNFX5T42mOKEyUesV3uFqypVoAEn9Q9Q1
m7NTunH1t2gJ2EK/mckqU+V5pVXeK4Tfj+QKLddfTzGZyI0VIqsqlm8/x0mXSByd
casIsVahiDmGxwztBljE
=nH+R
-END PGP SIGNATURE-
___
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


[PATCH] mtree should not output size if the file is not a regular file

2013-09-09 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I think it doesn't make sense to emit size information for non-regular
files like directories, symlinks, etc. although both our and NetBSD's
mtree would emit it.

Comments?

Index: usr.sbin/mtree/create.c
===
- --- usr.sbin/mtree/create.c   (revision 255424)
+++ usr.sbin/mtree/create.c (working copy)
@@ -208,7 +208,7 @@ statf(int indent, FTSENT *p)
output(indent, offset, mode=%#o, p-fts_statp-st_mode  
MBITS);
if (keys  F_NLINK  p-fts_statp-st_nlink != 1)
output(indent, offset, nlink=%u, p-fts_statp-st_nlink);
- - if (keys  F_SIZE)
+   if (keys  F_SIZE  S_ISREG(p-fts_statp-st_mode))
output(indent, offset, size=%jd,
(intmax_t)p-fts_statp-st_size);
if (keys  F_TIME)

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iQEcBAEBCgAGBQJSLj8GAAoJEG80Jeu8UPuzfr4H/RU/qxwVIBAdiXzaD7CvPnCr
3fl+wMIaugYYyZCOWXu1cW4NS8eq5PGPtkJyXCjxGjnyjIpJgZ9XWxZMzdNR4ID0
qLuDOStThE3jjQ/11vx4G4qwsd7iB/BE0O8dfpf68VQu50b40IRl6nDRfHrUETuZ
wYFT+tbm6EiJlNif6Y9XNFJhdAuow3oPEexx6fxv5AUaC9ZeyoSZQdCJoDcfOsXm
gEnB1IJiS5hRXckimvTrq8pjnfj+u6oTAj9U4klAx0yDk6VZuZPIWaYOnPZJr7BR
rVuiRbLFnc2yIPyFFq7y3guqCJpRvOwRuOF/N5vj3qSCYJXmIasXkUjUM6hsxA0=
=hteB
-END PGP SIGNATURE-
___
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: Positional arguments/load command broken in boot loader; cannot load old kernel

2013-08-13 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/13/13 09:36, Garrett Cooper wrote:
 I made the mistake of installing CURRENT on my file server at home 
 this morning and thought I could just boot the old kernel, do a
 zfs rollback, then continue on my merry way.
 
 Turns out I was horribly wrong.
 
 In addition to colors added to the boot loader (h shiny!!!),
 it appears the loading kernels with the load sub command from zfs
 pools does not work (load kernel.old, boot -s kernel.old, etc).
 Period. It works just fine with my stable/9 kernel/userland, but
 not the CURRENT one.

Don't work -- how?  I rebuild my laptop daily and does not see that
and I don't see a way Devin's changes could possibility cause problems
like this.

BTW since this sounds like a ZFS related issue -- did you do a 'zpool
upgrade' without updating loader or boot block and used some new features?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (FreeBSD)

iQEcBAEBCgAGBQJSCmmWAAoJEG80Jeu8UPuztf8H/3Ya4U7YVsPlNR6cnGMMFeTB
LU3rXeQ0Eir+Tv2aQ1vh4/4HvA/iOI33/eRZEJo3tx0B+HgCNQbnECT5I1DfbO2I
Oh0BTSVWWF9ovvkFGnqbOr+XITWbYJafI4M046DgS3HjfhhO1FmHvuyfdW457gKs
UvHw3XEHyl3E4j/D5y1j7lJ0uQ/Jk5rjNKXylo/saFPrK4bb6NiRm+KH9NYm1qMD
PTx90HoAL0fEfJDutQ99zyTSspoCq13zU/rYEkzxVhqp2Eb8NYvEs9yElYYfFY+O
0FqTPf9MqZpLmtqaVSCmg9sZ5Krfl0VyRyLQwPUbuiNIolEwojoYsQma+ex56N0=
=jkdf
-END PGP SIGNATURE-
___
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: [Heads up] BSD-licensed patch becoming the default RSN.

2013-07-28 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 7/27/13 8:08 AM, Pedro Giffuni wrote:
 OK; On further revision ...
 
 On 26.07.2013 20:01, Jan Beich wrote:
 bsdpatch doesn't list files of the failed hunks with -C and -s
 option. This may be less convenient if you edit a patch directly
 rather than regen it after polluting the tree.
 
 $ patch -CEfsp0 -i /path/to/varsym.diff 1 out of 1 hunks failed 1
 out of 2 hunks failed 2 out of 2 hunks failed 1 out of 5 hunks
 failed 1 out of 1 hunks failed 1 out of 1 hunks failed 1 out of 1
 hunks failed zsh: exit 1
 
 $ gnupatch -CEfsp0 -i /path/to/varsym.diff 1 out of 1 hunks
 failed--saving rejects to contrib/openbsm/etc/audit_event.rej 1
 out of 2 hunks failed--saving rejects to
 lib/libc/sys/Makefile.inc.rej 2 out of 2 hunks failed--saving
 rejects to sys/security/audit/audit_private.h.rej 1 out of 5
 hunks failed--saving rejects to sys/security/audit/audit.h.rej 1
 out of 1 hunks failed--saving rejects to
 sys/bsm/audit_kevents.h.rej 1 out of 1 hunks failed--saving
 rejects to sys/kern/syscalls.master.rej 1 out of 1 hunks
 failed--saving rejects to sys/sys/priv.h.rej zsh: exit 8
 The change came from OpenBSD, which took it from DragonFlyBSD:
 
 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c.diff?r1=1.49;r2=1.50

 
 
 It was merged as part of some OpenBSD syncing in patch.c 
 http://svnweb.freebsd.org/base?view=revisionrevision=246091

Ah, thanks for the detective work.

I think the showing the filename would be more reasonable.  How about
this?

Sample output:

[delphij@zeta] /usr/src/usr.bin/patch patch -RCfs  1.diff


1 out of 1 hunks failed while patching patch.c

[delphij@zeta] /usr/src svn diff -x -p usr.bin/patch/
Index: usr.bin/patch/patch.c
===
- --- usr.bin/patch/patch.c   (revision 253736)
+++ usr.bin/patch/patch.c   (working copy)
@@ -406,8 +406,8 @@ main(int argc, char *argv[])
say(%d out of %d hunks %s--saving
rejects to %s\n,
failed, hunk, skip_rest_of_patch ?
ignored : failed, rejname);
else
- -   say(%d out of %d hunks %s\n,
- -   failed, hunk, skip_rest_of_patch ?
ignored : failed);
+   say(%d out of %d hunks %s while
patching %s\n,
+   failed, hunk, skip_rest_of_patch ?
ignored : failed, filearg[0]);
if (!check_only  move_file(TMPREJNAME,
rejname)  0)
trejkeep = true;
}

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJR9MOIAAoJEG80Jeu8UPuzBu8H/AnbhUFoCDI5WNqXzYNi6is3
t989x+Tg01rI1hWimvWnZOWXVVosIP8JZfFydPhd1FHGZ2mxlB8kCpxAO33fhGkO
90v07+qNpA8fIzxNUtb7fbrzEpILRJ2TxzVEeIRHJ3rNzTFIOpJoII+wNSukD3om
Jl3x2OXv0UL1dCyIgvi7MtpwwllpK9mBuZhjQRQjKzh9k9TYW6n5dLsMIoFfvp4s
syXqxAWNdR+couvE8Q1ia9jKi6veE6UP2U6FT43GHTYym8srzWOj0dAXNjyrWqBr
EVIw4oKS9tPv4OAaDVjYhQJwtBdtmbCW3HVQ1OJ+GvH3IK1JlPzVYmIdQt2SAnQ=
=bU/M
-END PGP SIGNATURE-
___
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: CURRENT: system crashing while shuting down - files system corruption

2013-05-24 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/24/13 06:50, O. Hartmann wrote:
 Since r250670 (last known stable) I face a lot of problems.
 
 On systems with SSD, after a couple of seconds the box is crashing
 and rebooting, showing up a lot of CAM/SCSI stuff on the console.
 
 A system with traditional disks I get while shutdown in progress
 (via ACPI power button or shutdown -p now command) corrupt
 filesystems (UFS disk).
 
 Below an error message after such a crahs, /usr/ports is a
 partition and while the shutdown was in effect, there were no
 activities on that partition, but is has been repaired while the
 box then powered up again. Now it seems to be corrupted in the way
 that I can not svn update the ports tree anymore.
 
 What happened?
 
 
 root@thor:/usr/ports # make update 
 --
 Updating /usr/ports using Subversion
 -- cd
 /usr/ports; /usr/local/bin/svn update svn: E155036: Please see the
 'svn upgrade' command svn: E155036: Working copy '/usr/ports' is an
 old development version (format 12); to upgrade it, use a format 18
 client, then use 'tools/dev/wc-ng/bump-to-19.py', then use the
 current client *** Error code 1

Have you tried 'svn upgrade' by chance?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRn+oaAAoJEG80Jeu8UPuzukkIAKadxoGeM+9QiJim5QIV6uWx
GgY2Doz04R3+Ow89IRCQdrrlgsG/lJkR7hV7XD9H4dfbD8Fkh1X79vnRcJ/CSSPg
OZu3FgVHE4CVVJZLMFv+4wM9VIPeGMVBV8wnbP2CcleqJlJWDoI4OUddHhEeOHoU
8qqjylxUUcvijWj6c4P3MZloiopE8L9mHZmyuhh85LYszr/2lRCPeFjXQh/b+9C0
RsC0fZoJtCr/X+8ekvj4SIGwOTIvyJyXCfeNaHEhlGFj86bjuEA3OIwG1UOMebMv
y9hTeNrso0eB32BDNOPqwpL6pxnTS7rKS2Wxp/16zb9Lh/Hiui8UILRhwwbPcy4=
=HGvA
-END PGP SIGNATURE-
___
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: [PATCH] Analysis of bug in BSD patch

2013-05-23 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/23/13 06:07, Stefan Esser wrote:
 Am 23.05.2013 13:02, schrieb Stefan Esser:
 This appears to be a problem with the new BSD patch in -CURRENT:
 
 # gnupatch -d /usr/ports/textproc/texi2html/work/texi2html-5.0 -E
 -p0 \ -V simple -C  files/patch-texi2html.pl Hmm...  Looks like
 a unified diff to me... The text leading up to this was: 
 -- |--- texi2html.pl   2012-07-09
 10:54:41.0 +0200 |+++ /usr/local/bin/texi2html
 2012-07-09 10:53:16.0 +0200 -- 
 Patching file texi2html.pl using Plan A... Hunk #1 succeeded at
 1933. done
 
 # bsdpatch -d /usr/ports/textproc/texi2html/work/texi2html-5.0 -E
 -p0 \ -V simple -C  files/patch-texi2html.pl Hmm...  Looks like
 a unified diff to me... The text leading up to this was: 
 -- |--- texi2html.pl   2012-07-09
 10:54:41.0 +0200 |+++ /usr/local/bin/texi2html
 2012-07-09 10:53:16.0 +0200 -- 
 Patching file /usr/local/bin/texi2html using Plan A... Reversed
 (or previously applied) patch detected!  Assume -R? [y]
 
 Obviously, BSD patch does not select the file with the shortest 
 path name as the target. I have not checked the source code, but 
 you should definitely open a PR for this bug!
 
 Further information: The implemented logic does not follow the 
 logic explained in the man page. Instead of using the file with the
 least order of path name components, shortest filename and finally
 shortest basename (with the search stopping as soon as one of these
 conditions is true), it uses the first file name to check as the
 reference, and only chooses another file name if *all* of the above
 comparisons are in favour of the latter file.
 
 This is wrong, because files with less components will only be 
 considered, if both of the other conditions are true as well. In
 fact, the first filename to be checked has good chances to be
 selected in the end, since it only needs to be better with regard
 to any one of the criteria ...
 
 The following patch fixes the behaviour and makes it compliant with
 both the man page and GNU patch:
 
 Index: pch.c 
 ===

 
- --- pch.c (revision 250926)
 +++ pch.c (working copy) @@ -1537,10 +1537,16 @@ continue; if ((tmp
 = num_components(names[i].path))  min_components) continue; -
 min_components = tmp; +   if (tmp  min_components) { +
 min_components = tmp; +   best = names[i].path; + 
 } if ((tmp =
 strlen(basename(names[i].path)))  min_baselen) continue; -
 min_baselen = tmp; +  if (tmp  min_baselen) { +  
 min_baselen =
 tmp; +best = names[i].path; + } if ((tmp =
 strlen(names[i].path))  min_len) continue; min_len = tmp;
 
 Please review this patch - I'd like to commit it to HEAD if there 
 are no objections.

Sounds good to me, thanks for working on this!

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRnk4XAAoJEG80Jeu8UPuzOsUH/jw0nYAL7HzUw9diyOJb9uJb
if4IZeVQzqwd66gVQGg4PD/ZRbuTlLNugA+ljb+oIEB6P5i4psx4ki0QNZbjmhgS
Ft4UnyeaOYe4IxpevvO5Tzq0LbUVLS2fnzPzHhkv2aCmddALpQ5sPJgLpMQZ/VCa
WAjPY9CZhu3aWXLCOVAH8KlL4crwMEVlgnL+onP4eqZydddvP5t058otvggZqHVL
oNgzMYanT6BANQlUD9B/bnnLK7kTdIvBSB5hEd4l8oIa2zMrEjWrnC+5K/WlbarU
yXdCiixnBrsrkaECrXZPJE6ImzOxw7f6GKOJ4cyJ2fUzJ9mwq8Oe84VGGiI+Rbw=
=Kkia
-END PGP SIGNATURE-
___
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: CURRENT r250636: ZFS pool destroyed while scrubbing in action and shutdown

2013-05-15 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/15/13 10:20, O. Hartmann wrote:
 Several machines running FreeBSD 10.0-CURRENT #0 r250636: Tue May
 14 21:13:19 CEST 2013 amd64 were scrubbing the pools over the past
 two days. Since that takes a while, I was sure I could shutdown the
 boxes and scrubbing will restart next restart automatically.
 
 Not this time! On ALL(!) systems (three) the pools remains 
 destroyed/corrupted showing this message(s) (as a representative, I
 will present only one):

Have you tried to import the pool with '-f -F -X', i.e.:

zpool import -f -F -X ASGARD00 ?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRk8hEAAoJEG80Jeu8UPuzypYH/1rhgkdLEdEAnsvRn7K1wGi2
AWoLL7Sei7G0PbV2fFsnZ/+gc8MDsqiZo8TkHbZYWboV/ofmkxVYJMViLrvut5Mt
j/j1nDWVub1iSLk/dUug4JW41AuhqjEv2PXn1sRcr0NN/YTXr/gHHhhPwjqovURP
Db4OUCgdc5uMYr4teZbITMQfLLu/vJ28MoPuKWAuzEJKbHAwuetnpNHcApGPUDWI
R+f8NDKm52EVstPBi4EZK+jb/QRy00ypXdp4o1JgUj/WPd1h98ImIaBirj+PHK4t
AVXQk3vFdQ2qo5Yps5je1XR19TqKoKgYmb27d93qK6hZVHIDLTRNWJvzQC7XEcg=
=QMe8
-END PGP SIGNATURE-
___
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: CURRENT r250636: ZFS pool destroyed while scrubbing in action and shutdown

2013-05-15 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 5/15/13 12:17 PM, O. Hartmann wrote:
 On Wed, 2013-05-15 at 10:39 -0700, Xin Li wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 05/15/13 10:20, O. Hartmann wrote:
 Several machines running FreeBSD 10.0-CURRENT #0 r250636: Tue
 May 14 21:13:19 CEST 2013 amd64 were scrubbing the pools over
 the past two days. Since that takes a while, I was sure I could
 shutdown the boxes and scrubbing will restart next restart
 automatically.
 
 Not this time! On ALL(!) systems (three) the pools remains 
 destroyed/corrupted showing this message(s) (as a
 representative, I will present only one):
 
 Have you tried to import the pool with '-f -F -X', i.e.:
 
 zpool import -f -F -X ASGARD00 ?
 
 Cheers, - -- Xin LI delp...@delphij.net
 https://www.delphij.net/ FreeBSD - The Power to Serve!
 Live free or die
 
 
 All right, I had first to export the pool before i could import it
 again. After import, the scrubbing goes on and it seems all right
 so far.

Ok.

 The One-Disk-Pool, the other one that failed, seems to have
 different IDs since import compalins about multiple existences of a
 pool with the very same name. How can this happen?
 
 root@b211:/root # zpool import pool: BACKUP00 id:
 257822624560506537 state: FAULTED status: The pool metadata is
 corrupted. action: The pool cannot be imported due to damaged
 devices or data. The pool may be active on another system, but can
 be imported using the '-f' flag. see:
 http://illumos.org/msg/ZFS-8000-72 config:
 
 BACKUP00FAULTED  corrupted data ada3p1ONLINE
 
 pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One
 or more devices contains corrupted data. action: The pool cannot be
 imported due to damaged devices or data. The pool may be active on
 another system, but can be imported using the '-f' flag. see:
 http://illumos.org/msg/ZFS-8000-5E config:
 
 BACKUP00   FAULTED  corrupted data 8544670861382329237
 UNAVAIL  corrupted data
 

I don't really know if I don't have further information but I'll give
a guess: one possibility is that you created two pools with different
partition scheme (e.g. created a pool on whole disk, didn't wiped the
ends, then created a pool inside a partition), you need to be very
careful at this point.

If the first one looks sane (which looks like to be the right pool),
you can import the pool with:

zpool import -f 25782262456050653* BACKUP00

(I've replaced the 7 with * so you don't blindly follow the operation
- -- double check if the pool looks right).

If that won't work, the next step I would try would be import -f -F -X
with the same numerical id.

To prevent confusion, you could replace 'BACKUP00' with something like
'NEWBACKUP00', which will rename the pool when it's imported.

THe reason why the system thinks the pool may be active on a different
system might be that you are in single user mode and didn't run
/etc/rc.d/hostid start, or the system's hostid was changed for some
reason.

Hope this helps.

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRk/eOAAoJEG80Jeu8UPuzx28H/jfuUmEBkkA4D60m3UjZwwNP
luQ2Hpm2dCYFLAG8vEl5Q/nArFFw+EUwJPde9QZdgddap8U7TE3ENyWauQ98/1az
m6nZhdBU4WAgw2HzkBkk7kfgNH7twDSTbT9LGYe5p8wImBZOlYphFp48DvZOTXoA
51A95JgCYrEfkXTUCUTpAk+YHVrbgJS2+uLUteHLmzDH8UUK8qojrpG0H54NHzxa
/2dbGcyRWs2eoulJyOCv7bTZWZ9RcZhMnWmReE8UFHyCjFcxwWBnXQeaO2rtEgX0
DYQpWOegp6XhDeqb3t8UfISzrttRVf1unD/dCNVhuz/uwo3/zuDffdIfLxtv0iE=
=/Hl0
-END PGP SIGNATURE-
___
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: Root on zfs fails to mount: illegal option -- L

2013-05-06 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 5/6/13 12:56 AM, Beeblebrox wrote:
 After latest world / kernel update (r250260 Sun May 5, amd64) I
 cannot mount root - message is: Addditional ABI support: linux 
 Clearing /tmp Updating motd *Mounting late file systems:mount:
 illegal option -- L* Mounting /etc/fstab filesystems failed,
 startup aborted System then falls into single-user mode.

I believe that you have a stale mount(8) binary compared to your rc.d
scripts.  Did you do a full 'make buildworld' and 'make installworld'
before doing mergemaster?  You can probably remove /etc/rc.d/mountlate
for now and use mergemaster -i to install it back later.

[...]
 I get consistent system freezes / screen blackouts after folders
 mounting stage, and can only get around the issue by selecting
 safe mode at the BTX loader.

No idea here.  What changes have you made before this happens?

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRh2pBAAoJEG80Jeu8UPuzc+4IALB+kAPQaoK4ZSv8Qy5KIFSE
A4oaN5nuf5yQ0FqviaxXsnmOpJtFFFQh5mBek/qp4nNDjt67R2xnJeqLnU+U5yin
Sz4chaX3r0MhwCFZMMN5+NWj5q/hZgdrQA8hMx27IT1wicmeS53DOoPFCyC2muop
l87Cxr71E3OwJSs3FZ+FQRFEl2duu//rWoxhGTRx9R2CB8+iQtQpEuBak+9M/8u1
EALCBsxNHBr+83Mrz+oG3NmYzX8GI3PzDJvPhg/NZlB5RRCkqinopQVB5HMO3Op8
A8AXD+XSEKTnTMV5OfyMnimoSf2lDKd3aB9pdvu5npiq4rtzohoFcR/X7eYtVJc=
=VeYq
-END PGP SIGNATURE-
___
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: [head tinderbox] failure on sparc64/sparc64

2013-03-24 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 3/24/13 12:20 AM, FreeBSD Tinderbox wrote:
 TB --- 2013-03-24 06:26:48 - tinderbox 2.10 running on
 freebsd-current.sentex.ca TB --- 2013-03-24 06:26:48 - FreeBSD
 freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0:
 Mon Mar 26 13:54:12 EDT 2012
 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64 
 TB --- 2013-03-24 06:26:48 - starting HEAD tinderbox run for
 sparc64/sparc64 TB --- 2013-03-24 06:26:48 - cleaning the object
 tree TB --- 2013-03-24 06:26:48 - /usr/local/bin/svn stat /src TB
 --- 2013-03-24 06:26:53 - At svn revision 248671 TB --- 2013-03-24
 06:26:54 - building world TB --- 2013-03-24 06:26:54 -
 CROSS_BUILD_TESTING=YES TB --- 2013-03-24 06:26:54 -
 MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 06:26:54 -
 PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 06:26:54 -
 SRCCONF=/dev/null TB --- 2013-03-24 06:26:54 - TARGET=sparc64 TB
 --- 2013-03-24 06:26:54 - TARGET_ARCH=sparc64 TB --- 2013-03-24
 06:26:54 - TZ=UTC TB --- 2013-03-24 06:26:54 -
 __MAKE_CONF=/dev/null TB --- 2013-03-24 06:26:54 - cd /src TB ---
 2013-03-24 06:26:54 - /usr/bin/make -B buildworld
 Building an up-to-date make(1) World build started on Sun Mar
 24 06:26:59 UTC 2013 Rebuilding the temporary build tree 
 stage 1.1: legacy release compatibility shims stage 1.2:
 bootstrap tools stage 2.1: cleaning up the object tree stage
 2.2: rebuilding the object tree stage 2.3: build tools stage
 3: cross tools stage 4.1: building includes stage 4.2:
 building libraries stage 4.3: make dependencies stage 4.4:
 building everything
 [...] cc -O2 -pipe  -I/src/sbin/fsck_ffs
 -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector
 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
 -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe
 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
 -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c
 /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors 
 /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': 
 /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type
 'int', but argument 2 has type 'time_t' 
 /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type
 'int', but argument 6 has type 'time_t' 
 /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects
 type 'intmax_t', but argument 8 has type 'long long int' 
 /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type
 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o]
 Error code 1

This should fix the issue, can someone review and commit it?

Index: sbin/fsck_ffs/fsutil.c
===
- --- sbin/fsck_ffs/fsutil.c  (revision 248678)
+++ sbin/fsck_ffs/fsutil.c  (working copy)
@@ -507,8 +507,8 @@ static void printIOstats(void)

clock_gettime(CLOCK_REALTIME_PRECISE, finishpass);
timespecsub(finishpass, startpass);
- -   printf(Running time: %ld.%03ld msec\n,
- -   finishpass.tv_sec, finishpass.tv_nsec / 100);
+   printf(Running time: %jd.%03jd msec\n,
+   (intmax_t)finishpass.tv_sec,
(intmax_t)finishpass.tv_nsec / 100);
printf(buffer reads by type:\n);
for (totalmsec = 0, i = 0; i  BT_NUMBUFTYPES; i++)
totalmsec += readtime[i].tv_sec * 1000 +
@@ -519,10 +519,10 @@ static void printIOstats(void)
if (readcnt[i] == 0)
continue;
msec = readtime[i].tv_sec * 1000 + readtime[i].tv_nsec
/ 100;
- -   printf(%21s:%8ld %2ld.%ld%% %4ld.%03ld sec
%2lld.%lld%%\n,
+   printf(%21s:%8ld %2ld.%ld%% %4jd.%03jd sec
%2lld.%lld%%\n,
buftype[i], readcnt[i], readcnt[i] * 100 / diskreads,
(readcnt[i] * 1000 / diskreads) % 10,
- -   readtime[i].tv_sec, readtime[i].tv_nsec / 100,
+   (intmax_t)readtime[i].tv_sec,
(intmax_t)readtime[i].tv_nsec / 100,
msec * 100 / totalmsec, (msec * 1000 / totalmsec)
% 10);
}
printf(\n);

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRTsUUAAoJEG80Jeu8UPuziSkIAImVgY8aEExJ1b2zLu2wLL2y
hHpQ+oMf63WFEQ3XN+wYnY0sZyjpBCTUULkdSQPbnj9eymJ8UkaPkdvE2JN4jWDu
UqTuSI4E7IYZpoH06LiAZTnNFI0+H072sdFTw7bUVwLTm4x7lOUD2G9JFZCOhBKi
QyXJ1r6i/jTORoRH+3oAYEl5hZk9IniFBkQp7i5Elzm/mxFpT/H7b48ptTmv+3+o
fKRLduuu6zNd+DtCOUmPAgyOOLyh1szAxhoIdQj5iopRgzdS1f5uQ7xP+SWqDhrl
PdT8YtEfFuXFeAg+PpgDWTank7lMKn4QBNn9g4CsvLrs4eA/JN3aSStuMWkzfgQ=
=VsRR
-END PGP SIGNATURE-
___
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


FULL_PREEMPTION

2013-03-08 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I have seen a few posts from Andriy as as well as the PC-BSD default
that for desktop systems, kern.sched.preempt_thresh=224 would improve
responsiveness.  Looking at the code, it seems that this is equivalent
to compiling the kernel with FULL_PREEMPTION.

The sys/conf/NOTES says, however:

# FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel
# threads.  Its sole use is to expose race conditions and other
# bugs during development.  Enabling this option will reduce
# performance and increase the frequency of kernel panics by
# design.  If you aren't sure that you need it then you don't.
# Relies on the PREEMPTION option.  DON'T TURN THIS ON.

Despite the possibility of exposing race conditions as well as
potentially hurting throughput because of (possibly more) context
switching, is it considered as a goal that we should support it?  If
so, should we enable it on -CURRENT?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJROia5AAoJEG80Jeu8UPuzv7MIAKoBNZyR28E5Wdnj2+IkHXvi
Vg9TipTxAWSyCBcuywJEoZUCXZs1f/WbGOrbPQv0iS9AWFt9GZJ+arVsk23hwVdw
kRredDAoF4kMR85wo0h8Zl04comNN+pdPNlftCGc4B6J63ysg1m7KlhUAHyXWLW9
lS7wleILiF1HRhggq7qBj4OChgbWUUgUBqf9ZMraLQMyFvfdnktE3OkDBOE1J0zu
QgEdAtQ2RL5JkocsqGziq4zWKGjqM60WLQAR/5i8sCP+oQ5qRbIebUpc/GKWY7r8
mAQDwrvKU26pbHSWOkT0Qi9cXw+GGG2vTU6fLh1e0p2QBgzpyXO2TfpkL6kioQA=
=xenl
-END PGP SIGNATURE-
___
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


[PATCH] Fix build after r247570

2013-03-01 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Marius,

The attached patch fixes two places where 'count' is not properly
initialized.  They should be merged together when 247570 is merged.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRMSJpAAoJEG80Jeu8UPuzsxsH/2cArvN1kjTXod8IlSVh3ImV
81pjIcBoNRDAOes6lptsdOOdOeNg4/MweG2PT1ZpxQ5yUQHdBld9eIsaruYnD2/y
RcfGeMdSJCZ216yaFHLu54nxvlJJXK1lsO1R1cdeBDdSoQChXulVv38FnKiB9J1m
ldFCC8oBdPX6yCRR5ZIuLXHXYXZjGw0Vyvta74NFTNwysrUcgtLT/1tpDpcVtDdd
Kd+hJtBif4+3zk4py6IS9qiiiO5wC2YkCC5oNhKy2Dh48l/QIagj0Fx/dWRNW8Q4
VUnKJMn4wnnrEmXAFxKMECaFWXKMmI7pQ/dxLMCaMSl2WJgVxHt5skv4iLKcgxc=
=Ah/7
-END PGP SIGNATURE-
Index: sys/dev/aac/aac_pci.c
===
--- sys/dev/aac/aac_pci.c   (revision 247583)
+++ sys/dev/aac/aac_pci.c   (working copy)
@@ -340,7 +340,7 @@ aac_pci_attach(device_t dev)
 {
struct aac_softc *sc;
const struct aac_ident *id;
-   int count, error, reg, rid;
+   int count = 0, error, reg, rid;
 
fwprintf(NULL, HBA_FLAGS_DBG_FUNCTION_ENTRY_B, );
 
Index: sys/dev/bce/if_bce.c
===
--- sys/dev/bce/if_bce.c(revision 247583)
+++ sys/dev/bce/if_bce.c(working copy)
@@ -1039,7 +1039,7 @@ bce_attach(device_t dev)
struct bce_softc *sc;
struct ifnet *ifp;
u32 val;
-   int count, error, rc = 0, rid;
+   int count = 0, error, rc = 0, rid;
 
sc = device_get_softc(dev);
sc-bce_dev = dev;
___
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: ZFS problems

2013-02-27 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/13 16:33, Glen Barber wrote:
 Hi Martin,
 
 On Wed, Feb 27, 2013 at 07:21:39PM -0500, Derrick Dantavious
 Edwards wrote:
 [...] I updated sources a couple of days ago and when I
 rebooted to continue to the upgrade process I received
 errors when I attempted to mount zfs filesystem. The error
 looked like this.
 
 zpool mount -a
 
 internal error: Invalid arugment
 
 [...] the Kernel and the ZFS tools in userland need to be
 updated at the same time.
 
 Boot back into the old kernel and (cd /usr/src/cddl  make
 install) to update the tools to a compatible version.
 
 
 In mid-February, zpool version was upgraded to include
 lz4_compress.  My understanding was that changing from the
 OpenSolaris ZFS version number scheme (i.e., v28) to what we have
 on -CURRENT (i.e., 5000) was so that we can track crossing the
 point of no return with pool version upgrades.
 
 On my system, vfs.zfs.version.spa has been at 5000 since this
 original change.
 
 Is my understanding incorrect?  Or should vfs.zfs.version.spa be 
 incremented with major, non-backwards-compatible changes?

That's incorrect.  In theory vfs.zfs.version.spa will never ever
change in the future, and all new features will be denoted by feature
flags, which is an extensible way of representing features and whether
they are compatible with the running system.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRLqbbAAoJEG80Jeu8UPuzSC0IAKasVsGlPKhjTl7Eu/Ocmdxz
ZnWC1hUEt6MJxrLPprRvDBZRMnGMD5YoQ8maMshy27FzxnKXJ3kHpX60gMCkkRFX
aRI4cPTHm6w+935KOMjA/Mso7rM8MUmr6b4qhf0Ar/E55sThAvy3BO1R/KVWYRro
4LuwfHGIg6z/vNYo4SDAtw7SOcD43Wk5JTPb1WlAUJOgMiTK+ceFx7mpd5EYCPvb
p6DWttzQ5yqxhmCayvBKLjpLBntdD4/88qRuMn5+TQBOZBrGoiK+9GZTwPMVu2U3
MT+hsUJ6uO8oPwKNSz6BgpP9BwyxreWEI/C7Wk0lbZkNeaauiPyN6qUiDD2di9g=
=R5LQ
-END PGP SIGNATURE-
___
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: ZFS problems

2013-02-27 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/13 16:44, Glen Barber wrote:
 On Wed, Feb 27, 2013 at 04:37:47PM -0800, Xin Li wrote:
 In mid-February, zpool version was upgraded to include 
 lz4_compress.  My understanding was that changing from the 
 OpenSolaris ZFS version number scheme (i.e., v28) to what we
 have on -CURRENT (i.e., 5000) was so that we can track
 crossing the point of no return with pool version upgrades.
 
 On my system, vfs.zfs.version.spa has been at 5000 since this 
 original change.
 
 Is my understanding incorrect?  Or should vfs.zfs.version.spa
 be incremented with major, non-backwards-compatible changes?
 
 That's incorrect.  In theory vfs.zfs.version.spa will never ever 
 change in the future, and all new features will be denoted by
 feature flags, which is an extensible way of representing
 features and whether they are compatible with the running
 system.
 
 
 Thank you for clarifying.
 
 As there does not seem to be a specific sysctl that we can look
 for, I am inclined to say there should be UPDATING entries for such
 changes to note (at least for now) that 'make -C /usr/src/cddl
 install' can help prevent foot shooting.

Grrr I should have noticed this when doing code review for the change.
 No, this is not intentional and has to be fixed, the issue was
introduced in r247265 (deadman feature).

Martin actually have done very good job maintaining ioctl
compatibility when we jumped from v15 to v28 that most people didn't
even notice that the ioctl was changed.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRLq4uAAoJEG80Jeu8UPuzlKAIAKPpCInGW6cIUXrrVkY11xMW
IK49TAUrxbBECpgo86gNtUZjWt7ik7nYRjxvocR4qKK5yM35fKsAInEN6LOYLCJm
ho4AIUex40sDr3K7avKMzi09Flsb3LfVtOYeAiZNk+oTPWRMj4vnw+VGxDMUq4/2
MXnaOpwI1mWDqnyBvtqspYh6dcUrqTX5+WrmucYuMgVHa7jsmJkorfhDp2ZBDjaM
afbvuVxcWV0aCajg44EHfKwQxTKGSNPIs7x3BTxBkao+TVuT1KJHbebF4EapNhe9
7jwM6XJhnSKIgXYgy8hpUPZB81mvxtvLuimTXi7c2rA9vs7sFu05wXgjbmKNLyQ=
=hW3e
-END PGP SIGNATURE-
___
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: compiling libc and libthr with debugging?

2013-02-22 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/07/13 10:14, Steve Kargl wrote:
 What's the preferred method for compiling libc and libthr with
 debugging enable?

I think that would be to compile and install libaries with
DEBUG_FLAGS=-g?  Not sure if this is what you wanted though...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJ9klAAoJEG80Jeu8UPuz3iEIAKXjl4nvYpf1kp9jAV+wtsWT
rNJEzzx6gr366b0NZuYJHTmIRA317Ip3VCCxgIRBhE40caLX7CHfb7NV0eTJh2Lh
lcWB9mkr+LsxTHLyJu/2ePAbTxuf+po8GSFuQkfCn9y29v1MIeeGyl6w3YowA2xx
fS51NC7IYvuXMcv2lyeM1B7iIKRdOY0/zD3G8RjutCvzMvuX2BzqWJZuLxohAYmN
8o8xChMk45x6VVkEn2VZgVHRfAMxipY/fSaSzJiwfHcO54v2bvqoXBMUk1vf+3FX
7EoFPRZvFYjXML8jF1r+lINaDz8Fd/GKOcRqfW8LQrXo4qi4TBSlTIlcDkp3y6s=
=+b4P
-END PGP SIGNATURE-
___
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: -CURRENT userland regression

2013-02-21 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/21/13 12:19 AM, Andriy Gapon wrote:
 on 21/02/2013 01:16 Xin Li said the following:
 I think it's unlikely -- I have r247057 of sys/ which worked
 fine...
 
 userland 246957 works good by the way.
 
 Just a very wild guess - are you sure that it is the userland that
 is to blame? It is rather unfortunate that we install boot blocks,
 including loader which gets _really_ installed, as part of
 installworld (and they are built as part of buildworld).  So there
 is a possibility that it is loader that causes the trouble.  I
 would try to rule that out.

Since loader is in /sys/ which I have updated to -HEAD and done a full
buildworld/buildkernel cycle, can I rule loader out, or did I missed
something?  (my experiment was to update src/ to a certain revision,
then update src/sys/ to latest, then a full buildworld buildkernel)

I do not have console access and had some other tasks yesterday so I
didn't continue the tests further but will do it today.

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRJdxXAAoJEG80Jeu8UPuz8TEIALTGsoH7tbTOk7Hh3QJPeuHc
PU3VLWo7fb3puoPnQXu1eAlTuAjXGpw2+3ITjgmunGWWpN2ABeFGIauIPk7RAWLV
E6/c/EpTfFNDWG0KoSDGJnDoTQ1KO9zp17Gp6KfaVYL3MLYEo/tNXWUBfdfg0ddv
4dNocl34GvPK4LXonIw+oBy2ha5MkzL4BARGP2QgYsv07uMk0MZ8fUSngmQFCiaD
LpOVe/mPoBc5GmBI7TZENBN/g9mMVNVu9gZXvQronnw52N3wNxIxy7jmWdv5uLUf
PXOjLrx930d88tN3HOjgtxrwbZBRyIJUdckbhXthpezlMsy81vWfn2+x9agG+mk=
=9OlU
-END PGP SIGNATURE-
___
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: [patch] remove negative socklen_t checks

2013-02-20 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/20/13 09:19, Sergey Kandaurov wrote:
 Hi.
 
 These checks are useless after the address length argument is
 converted to socklen_t (up to SUSv2). Any objections?

No objection in general but there is a minor style issue, see below.

[...]
 Index: sys/kern/uipc_syscalls.c 
 ===

 
- --- sys/kern/uipc_syscalls.c(revision 246354)
 +++ sys/kern/uipc_syscalls.c(working copy) @@ -353,8 +353,6 @@
 kern_accept(struct thread *td, int s, struct socka
 
 if (name) { *name = NULL; -   if (*namelen  0) -
 return (EINVAL); }

The { } for if () is no longer needed now per style(9).

By the way I wonder why there is no compiler warning for this -- or do
we compile kernel without signedness warnings?  Just curious...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJRkcAAoJEG80Jeu8UPuzagkIAICE9uJzbLS8MvPPYLEMCop3
mamlq7AOJSpGfEyBzB0CZV2badJC91LEtUGADMN0CANPbvX6EpDsYoPygpXBuxei
etNelbp1+9jbqwV6yK+9FVCioRiMMLrPKkyh02+s1ZhWCf6kjz3Xl9MEYKUKYuV1
ay7xLcLnQMxOzf1oS7Sovm6NsIFnDC06WZ0PZDFdBtv7typtGblw3rrgWMsOnshL
x35C1UC8NgLnauMEOhX6Vr1zeRz+hqfw+YauCi/P+3chxfUgpe6XR551IN2h9xBU
mYTNEjLkRgX8u5sCHYGB16r/OZ3X59w1sJH/21ayrHuF0gNEmQbnMlBnA/krH94=
=iiGi
-END PGP SIGNATURE-
___
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


-CURRENT userland regression

2013-02-20 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

It seems that fresh -HEAD would give an unusable kernel that
overwrites screen buffer in a way making it impossible to debug.
Using an old world source to do 'make buildworld buildkernel' results
in a (mostly: I have some strange USB issue right now and still
looking for the cause) usable kernel.

For now my known good combination is world 246858 with kernel 247057.
 I'm still trying to find out which revision have broke the stuff.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJUrOAAoJEG80Jeu8UPuzJBsIAMi/2gkOd2ApEGWRi7DgHu5c
MVRBIgmGW72BfQUWGkNyBCg0nsOO67oKpxMPYx0xzSKMvt2vAohS4+55VuytjOKF
mdKjs2wSVeMSYguJ5+OtM3cUxK1OuYRgqla6cvW5DCKdhF4WPFK27+tRgYlGTkzw
poGgznOTP2jJlPjICQI+VXkSNrI46xRJqxM3d3/jeYjjujGDOKTthYZJsPNxkTqh
mY3ng0hv18vFVxhQMDceRnaXl9QIYQKmzTPc1pnmF21GMDgpHeSfWDdPwvwYDVmO
04Jl8p0jyjfZvgpLddMoBy9GWfMLDY/qwYRE8sGYqWGQqR4y2dFXZTPZZN/YmO8=
=0shF
-END PGP SIGNATURE-
___
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: -CURRENT userland regression

2013-02-20 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/20/13 14:25, Konstantin Belousov wrote:
 On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote:
 On 02/20/13 14:14, Xin Li wrote:
 Hi,
 
 It seems that fresh -HEAD would give an unusable kernel that 
 overwrites screen buffer in a way making it impossible to
 debug. Using an old world source to do 'make buildworld
 buildkernel' results in a (mostly: I have some strange USB
 issue right now and still looking for the cause) usable
 kernel.
 
 For now my known good combination is world 246858 with kernel
 247057. I'm still trying to find out which revision have broke
 the stuff.
 
 I ran into this earlier today.  Selecting safe mode in the boot
 loader menu seems to work around the problem on my system.  Now I
 will not reboot until I see a fix for this in head :-)
 
 How much 'the earlier today' is ? I.e., could you specify some
 revisions ?

It would take some time to bi-sect as one needs to do full
world/kernel build.  The only thing I can say definitely is that
something from userland was broken within the (246858,247057] range.
I'm compiling 246957 right now.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJU5RAAoJEG80Jeu8UPuzvh0H/3gL+Og4fmzZ8TYrkhseuIS4
Pll3sWdIZnCqorfUV2ZFiRzV9Awvt4KRfl3m15lCM6ornl6jdVilQq9o07cfTQFK
mvkD6J08nraG/7D/raSzQ9oO4uTUYLVkzoaCDDa3Lz6fdpoIQ6JvuzcvOAsV+DJa
DjjKCIB6bOITaA+boyvTAsMwkv437Mz4Ze2eVqUbexwhWktHkzlROhX/H2Cz7CQn
fMNxpZFntjhEszi5HRYXQXVkdr/M0t92FpykZQCEXIClyw6tdXWEPJcMZFWVPRip
Rg6AR9Iys/BhlMJRUl5BzVK0eOB4Jx2PS1pckAduXBKykIrpsEIqY2Ybf1I=
=0Hzl
-END PGP SIGNATURE-
___
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: -CURRENT userland regression

2013-02-20 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/20/13 14:37, Konstantin Belousov wrote:
 On Wed, Feb 20, 2013 at 02:29:37PM -0800, Xin Li wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 02/20/13 14:25, Konstantin Belousov wrote:
 On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar
 wrote:
 On 02/20/13 14:14, Xin Li wrote:
 Hi,
 
 It seems that fresh -HEAD would give an unusable kernel
 that overwrites screen buffer in a way making it impossible
 to debug. Using an old world source to do 'make buildworld 
 buildkernel' results in a (mostly: I have some strange USB 
 issue right now and still looking for the cause) usable 
 kernel.
 
 For now my known good combination is world 246858 with
 kernel 247057. I'm still trying to find out which revision
 have broke the stuff.
 
 I ran into this earlier today.  Selecting safe mode in the
 boot loader menu seems to work around the problem on my
 system.  Now I will not reboot until I see a fix for this in
 head :-)
 
 How much 'the earlier today' is ? I.e., could you specify some 
 revisions ?
 
 It would take some time to bi-sect as one needs to do full 
 world/kernel build.  The only thing I can say definitely is that 
 something from userland was broken within the (246858,247057]
 range. I'm compiling 246957 right now.
 
 My first guess would be r247047, but I did booted the kernel+world 
 with this change applied, on amd64. Hm, I booted on the machine 
 with serial console.

I think it's unlikely -- I have r247057 of sys/ which worked fine...

userland 246957 works good by the way.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJRJVldAAoJEG80Jeu8UPuzxBcH/AntMKSKAou10EU8/PbZEAHH
q7A4enMQll13UuG9DzcXoQLEdmy+oCTpOcCn1Fe7YcY/ykvKgZhSUgTwwmZseL/N
vHRgLH44ctAHEZMGW50oAVLgpR4ac4/dwbqeCThFwMb6C0wwRgo2SJD1w5GW8TMw
JI40BeGdSEggJVOuYf+GJh433Wg5IhhxTsVkd5DXNrqjY5QfbtFwWJmUS7DKCb4X
Ds153GhyxVJ2YXHBp6HjJ8ccmocBZ+plnda9uNTTVYcvklbQDzYWIFmxHsUO1OBq
rXXSh93PJ7yJh/vrSFncDyxxpjfEfqlpCyM60Htd6CaFri1JbAn1kl4OmaDrlt8=
=i2Ev
-END PGP SIGNATURE-
___
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: sysctl -a causes kernel trap 12

2013-01-18 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/18/13 12:50, Brandon Gooch wrote:
 On Thu, Jan 10, 2013 at 4:25 PM, Xin Li delp...@delphij.net 
 mailto:delp...@delphij.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 To all: this became more and more hard to replicate lately.  I've 
 tried these options and the most important progress is that it's 
 possible to get a crashdump when debug.debugger_on_panic=0 and I 
 managed to get a backtrace which indicates the panic occur when
 trying to do mtx_lock(Giant) - __mtx_lock_sleep - turnstile_wait
 - propagate_priority, but after I've added some instruments to
 the surrounding code and enabled INVARIANT and/or WITNESS, it
 mysteriously went away.
 
 Reverting my instruments code and update to latest svn makes the
 issue disappear for one day.  I've hit it again today but
 unfortunately didn't get a successful dump and after reboot I can't
 reproduce it again :(
 
 Still trying...
 
 
 Any updates Xin?

No, it mysteriously disappeared for now.  According to my
understanding to recent svn commits, I didn't see anybody committing
something that fixes it but I can no longer panic my system, with or
without debugging code :(

 I was actually hitting what I believe to be exactly the same issue
 as you on one of my systems, and, as you've seen, adding any extra 
 debugging or diagnostics seemed to eliminate the issue.
 
 I was able to generate quite a few vmcores and still have these
 sitting around in my filesystem (along with the kernels that helped
 produce them).
 
 I can recreate this crash on my system by compiling the NVIDIA
 driver with clang at -01 and above. Although it's been noted that
 this issue has been seen in scenarios without an NIVIDIA driver in
 the mix, whatever is happening in the kernel to cause the panic is
 somehow triggered by this, at least on my system.

I'm not sure if this is the same problem.  Could you please try using
gcc to compile the nVIdia driver and see if that fixes the problem?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJQ+bcKAAoJEG80Jeu8UPuz5D8H/RFSmPv2nNqGmLCNZpElesN5
IYHWTNwxekFLC5M/jeYCLePLGEozBqOBzryrVr1xslvIJJf2w0NLCEIzyC+kdWy9
ksi+DihihuwqEp7BIieQi/HQkwhFKxm0SmovPYu8Al3rFFyazuMCHstuToWyT9sN
OV8ZjyinFIyb8EPqm7V6Ziwi7A6sApHO5SlQXscqANrT03FrU4I8tseNzdDX9uwQ
zzewf05rkcko771Vk7JI9Xwu7VHZ+eN4NbujBhuVhMWw+utZSJFOf67o11JZw9B0
aM1PCfZef2NM9OfAN40JTY4/Hjk6TSygJKu3mGd3R5tjcRywU0ypwPXgOsUxlVg=
=3Kk8
-END PGP SIGNATURE-
___
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: sysctl -a causes kernel trap 12

2013-01-10 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

To all: this became more and more hard to replicate lately.  I've
tried these options and the most important progress is that it's
possible to get a crashdump when debug.debugger_on_panic=0 and I
managed to get a backtrace which indicates the panic occur when trying
to do mtx_lock(Giant) - __mtx_lock_sleep - turnstile_wait -
propagate_priority, but after I've added some instruments to the
surrounding code and enabled INVARIANT and/or WITNESS, it mysteriously
went away.

Reverting my instruments code and update to latest svn makes the issue
disappear for one day.  I've hit it again today but unfortunately
didn't get a successful dump and after reboot I can't reproduce it
again :(

Still trying...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ7z/sAAoJEG80Jeu8UPuzJbMIAL2xM6xWATXp2swY1E25WaCj
UoDAJtVkGvI5pOQmt7UBvDJfqr74/1c1ugGodFVAtRluKihxQ6amXcmF62eqPu0g
ARj7R+g/5qQ+QDDOVFcqnvuz1A1KwoDD5jkfAyq+oWECQ5a4ROk/59EhlriK9CQd
I4NRzuJLgOf3t4xNk7nAEYSnx+zL07vpGmSNIHdWkLieGNIoa1X5W9HtfpOGgRpm
c5ELbWTpxGTtAFmFxc7h2hygu38/hlj6KPJHRK6HGcR1t/EMc2Rauzn7Bl3R3C/W
TjDrxknPjZUUA70oI2V2Vo8tGZaJCzpq8dDWb8fx5rbKxLM+svmShHYftow78rM=
=ooDY
-END PGP SIGNATURE-
___
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


setlocale() for base system utilities

2013-01-10 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I just noticed that many base system utilities, like rm, cat, etc.
does not do setlocale() at beginning.  Is this intentional or just
nobody have yet to done it?

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ73VUAAoJEG80Jeu8UPuzWR4H/Ap79HVGQso6/HPmiud2JC5q
dzeY20K1P2rlQAjDhday1HWJg3bW4ZCzvIX09AVi+lQB8fRAcRzLIFjXt611ovqC
tBOhTgtwJvFEYGBs5batWCrEOtbTnbM2YZlOyJegSdjqhIoXiWrj5BCpbr5OaGw7
GK9yJhiYX60vHQwL0kRP4Xwn9Yc1+UPyyzPXj0HpgTutJhFFwcXCymK2ZpWmyxT4
6SdwEcIEsBH2iluunS9yDGKCexk8v8BT/uPUOGOQ6vK9y4L/3egJ3RKrQj4Q3Mu+
Yksn+jIT5eXdijmmbnYZKR0QW/7+eyJbZ4w4ZNasYhEYGskCfj2ce32sbYa7ilw=
=p9Ch
-END PGP SIGNATURE-
___
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: setlocale() for base system utilities

2013-01-10 Thread Xin LI
On Thursday, January 10, 2013, Zhihao Yuan wrote:

 On Thu, Jan 10, 2013 at 8:13 PM, Xin Li delp...@delphij.netjavascript:;
 wrote:
  I just noticed that many base system utilities, like rm, cat, etc.
  does not do setlocale() at beginning.  Is this intentional or just
  nobody have yet to done it?

 Enabling locale in the non-wide-char-awared utilities only makes
 difference for 8-bit locales, like ISO8859-*, but not multibyte
 ones.  From a user's point of view, this is an inconsistency.


It's inconsistency that some utilities use localized messages while some
do, too.  So I don't buy that argument.


-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
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


sysctl -a causes kernel trap 12

2013-01-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I've recently (by mid-December I think) noticed that sysctl -a can
sometimes cause kernel trap 12.  Tried enabling INVARIANTS and the
problem mysteriously disappeared.  After some experiments on this, it
seems that this can be triggered by sysctl -a but the system have an 1
in 10 chance to survive.  When INVARIANTS is enabled however, I can
not trigger the panic.  sysctl hw triggers the panic sometimes, but
not always.

Do anybody have clue on this?  The system hangs hard when it panics so
kernel debugger won't work.  When it panics, the fault instruction
pointer is always 0x20:0x808d61c9, which is
sys/kern/subr_turnstile.c:297:

 /* Resort td on the list if needed. */ if
 (!turnstile_adjust_thread(ts, td)) { mtx_unlock_spin(ts-ts_lock);
 // 297 // return; }

This sounds like a race condition but I haven't yet able to track it
down...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ62AvAAoJEG80Jeu8UPuzW0IH/0D0PxoTIr6qdHFhzG1It1r2
HRnkCaVKzllc6a0obdHzthBLe7dd3bMARuVLR/NiD611mhrFGY2P4W9x+bp9KwMH
gTp18fWsHamkj5jEO8zpLjVWF62WwaFKuCEvg1zKLS+Fo3K7vSr5i5O6SeUhueeR
iUNldC5m5E6Nwkbn9OW8jHzadhHmmIbUAfoWs8K7FCFQpLYXg5e8Q8gW5RsJvPmT
v92vwAC2L3MOBiSGKfRkKngBihHlDnkX0xRhWuI+PIh5yr8kijgA4DDroOhJv3RF
ga0NKanjZFk9k1+gFVua3gmMmCopvkIs7XHsjJbKBcMcvEtTXQxkrJwVmgX+q80=
=Wubv
-END PGP SIGNATURE-
___
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: sysctl -a causes kernel trap 12

2013-01-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/07/13 16:02, Konstantin Belousov wrote:
 On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Hi,
 
 I've recently (by mid-December I think) noticed that sysctl -a
 can sometimes cause kernel trap 12.  Tried enabling INVARIANTS
 and the problem mysteriously disappeared.  After some experiments
 on this, it seems that this can be triggered by sysctl -a but the
 system have an 1 in 10 chance to survive.  When INVARIANTS is
 enabled however, I can not trigger the panic.  sysctl hw
 triggers the panic sometimes, but not always.
 
 Do anybody have clue on this?  The system hangs hard when it
 panics so kernel debugger won't work.  When it panics, the fault
 instruction pointer is always 0x20:0x808d61c9, which is 
 sys/kern/subr_turnstile.c:297:
 
 /* Resort td on the list if needed. */ if 
 (!turnstile_adjust_thread(ts, td)) {
 mtx_unlock_spin(ts-ts_lock); // 297 // return; }
 
 This sounds like a race condition but I haven't yet able to track
 it down...
 
 Could you try to isolate the sub-leaf under hw which causes the
 panic ? Just shot in the dark, do you have Intel GPU gemified
 driver loaded ?

It seems that it was not hw itself that causes the problem (I thought
about isolating to sub-leaf and at one point believed it was
hw.acpi.battery but doing so repeatedly doesn't panic the system, with
or without INVARIANTS; doing 'sysctl hw' sometimes causes panic but
not always).

The laptop is running nVidia but it's using i7-3610QM which does have
Intel GPU, but I have not loaded drm2.ko and the panic is reproducible
in single user mode.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ62OpAAoJEG80Jeu8UPuzsYgH/iw8ispGuIqYkDAcfH1rh2AR
MvSF3kf6OsPUAm3hRpa+VGcwssqgPTnyTgB2AGDPQ4FPurep/9sVD7rEmjy+4jFY
6bpUvirTcfSVnuEXWKq+ySaq7K+zR9SvorNMOnufS91oY+hzwwnZd3iykjhLAAth
MNjmhAoSsT+MHvMBNweIoWA7FH9MxE7yfOi89foM/ZTcbibt9vY+gTpAPAlrfsab
xG1w8aQhgX6/91QZGh8E1nVDo8vqO9Fqte+tkaZbEh3eJQFx8uRktvAps6T052T/
la/1zzGoqxfZZRbc0/bK7CnhyM4N5xPM1Q+eB2Q9F6F/S+XQPPhASnJNJXh0XAw=
=tCfp
-END PGP SIGNATURE-
___
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: sysctl -a causes kernel trap 12

2013-01-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/7/13 4:21 PM, Ryan Stone wrote:
 Have you tried dropping into the debugger by setting 
 debug.debugger_on_panic=1 instead of trying to generate a core?
 You might have some success generating at least a backtrace.

My setting was debugger on panic but that's a good point, will try
unattended tomorrow to find out (I don't have high expectation here
though).

 Also it would be worth setting kern.stop_scheduler_on_panic=0 to
 see if that lets you generate a core.

Hmm...  I don't know how will this help but will try.

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ64TcAAoJEG80Jeu8UPuzhLoH/RVSZKhc4TkhWM3GF9FgiZY0
s5TH738pyh0+fe+FsGItr4uw83MvLLkjVZTlvstwXjEZhrXH6ehnXibcAQnNKACo
0mJKUOQq5xbWVVDSkLeJwthavrAXEBwUPVTVjx6ZhRLJmikkQNbtOkvOypvJ5Jjh
i/1/HSFgFrI3x71OpPJOdKMru18VvN5K74A8v34HlaYMgEpnPGmuTJ6hPvkgC8a+
1w0vGBInmLQWQZ4UEGUhPyoVly2zp81zFpCUfIzf6jd+FPMOcN+gj2JPSYLVUHS2
Rv7ReaT5U6gWvTxTm+lc2zkaUnSkXb8oAwQafWWD/NopnUZHvlQsIdZgSjGhG1k=
=Nf0J
-END PGP SIGNATURE-
___
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: sysctl -a causes kernel trap 12

2013-01-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/7/13 5:33 PM, Brandon Gooch wrote:
 On Mon, Jan 7, 2013 at 6:09 PM, Xin Li delp...@delphij.net 
 mailto:delp...@delphij.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 01/07/13 16:02, Konstantin Belousov wrote:
 On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Hi,
 
 I've recently (by mid-December I think) noticed that sysctl -a 
 can sometimes cause kernel trap 12.  Tried enabling INVARIANTS 
 and the problem mysteriously disappeared.  After some
 experiments on this, it seems that this can be triggered by
 sysctl -a but the system have an 1 in 10 chance to survive.
 When INVARIANTS is enabled however, I can not trigger the
 panic.  sysctl hw triggers the panic sometimes, but not
 always.
 
 Do anybody have clue on this?  The system hangs hard when it 
 panics so kernel debugger won't work.  When it panics, the
 fault instruction pointer is always 0x20:0x808d61c9,
 which is sys/kern/subr_turnstile.c:297:
 
 /* Resort td on the list if needed. */ if 
 (!turnstile_adjust_thread(ts, td)) { 
 mtx_unlock_spin(ts-ts_lock); // 297 // return; }
 
 This sounds like a race condition but I haven't yet able to
 track it down...
 
 Could you try to isolate the sub-leaf under hw which causes the 
 panic ? Just shot in the dark, do you have Intel GPU gemified 
 driver loaded ?
 
 It seems that it was not hw itself that causes the problem (I
 thought about isolating to sub-leaf and at one point believed it
 was hw.acpi.battery but doing so repeatedly doesn't panic the
 system, with or without INVARIANTS; doing 'sysctl hw' sometimes
 causes panic but not always).
 
 The laptop is running nVidia but it's using i7-3610QM which does
 have Intel GPU, but I have not loaded drm2.ko and the panic is
 reproducible in single user mode.
 
 Cheers, - -- Xin LI delp...@delphij.net
 mailto:delp...@delphij.net https://www.delphij.net/ FreeBSD -
 The Power to Serve!   Live free or die
 
 
 Xin, did you compile the NVIDIA driver port with clang? I was
 having this issue until I set an exception for the NVIDIA driver
 port to be built with GCC.
 
 Actually, I just remembered (and checked), and what I'm actually
 doing is setting CFLAGS for the NVIDIA driver port to -O0, and
 building with clang. Clang optimizes out important bits, I didn't
 investigate deeply enough to determine what was actually going
 awry...

Yes my nVidia driver is compiled with clang.  I'll try gcc tomorrow,
thanks for the pointer.

(Note that the panic was a NULL pointer deference and it's a race
condition so I doubt if it's compiler related but will try).

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ64cNAAoJEG80Jeu8UPuzkLwIAKgjgbcBaow64mWzrJ0XtczM
6Xi4mC0Oq5kdomx0y+Vgks/qTvq28Ff/JqyxN8osD959Vwaq0vbQumFiDtbWCr0h
/MD0w5m7Asdbf8KzJE80il90Vv1/nJrOVdwj3qoNIqtKIomi12CHDKL5zFs2Ja2i
rscN22SBh8+3vV1rBSE6NGzJ7jPSs/B0o73YuIdwj6bUYMiBqHWWGGTfFStNhc4U
1JX6WWsDdiWxNvGPH5lE3HelSgya+WCltD+B6/8mYaByBQbXD+JBOA9AvX97h2kk
muQROSMOz6OVdGmtM6U/19Bsiv/8kUtItJF2k19Y/eTQEohH/2xBhq+37EG8cqg=
=b9UF
-END PGP SIGNATURE-
___
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: FreeBSD services startup problems

2012-12-26 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/26/12 15:33, Derrick Dantavious Edwards wrote:
 Hi, I am having problems with startup services in FreeBSD current.
 I am at a loss on where the problem lies. Even though I have
 services explicitly defined in rc.conf for startup they do not
 start. Startup scripts both in /etc/rc.d (powerd/moused) and
 /usr/local/etc/rc.d (dbus,hald, and gdm ) are experiencing this.
 Initially, I checked out my rc.conf file as well as the
 /etc/defaults/rc.conf because I continue to get this message.
 
 /etc/rc: WARNING: $auditdistd_enable is not set properly - see 
 rc.conf(5).
 
 This is weird because I don’t have this service defined in my
 rc.conf. I even went so far as commenting out all entries in
 /etc/defaults/rc.conf that related to auditdistd to verify that it
 was not the problem. This was done because I disabled the service
 in my /etc/rc.conf with no joy. I also checked the /etc/rc file
 against what is in /usr/src and they match up.

Quick fix:

rm /etc/defaults/rc.conf
mergemaster -Ui

The problem is that your /etc/defaults/rc.conf is inconsistent with
/etc/rc.d.  If you make any changes to /etc/defaults/rc.conf (which
you shouldn't), please migrate the change to /etc/rc.conf{.local} and
discard these changes.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQ22MvAAoJEG80Jeu8UPuzNK0H/1pKulntacEr0HJqLIYiv/be
XGTeYixSnRJFSD7PjmYLizRc6ayF+UWXKD7NQzH/pp4mY31Sq+mghO7f1gyDzmY/
nGZnmO9z3SxCyI5MDJcvyrKMc8YU3abrfczJZ8CqDojnz3mLZ2ykhaZfDoOm0Wd5
8kl+nun6RHEdnahoW4FqZ/U3IIeEu5k1130urJxMO/H2C+4yOqS/Eq7ELKc0tU7Q
B2egmi6Wfbm005h9oMxEPuPD7zvwoCna7GZJugdr7uezsIq3LUirkyqSqcyc9v2g
kFLCcnPYGxPdzopPxP44bz0TocJZhuvEaxuiPWyIP8M2c5NzmlcTTvUMepwN8pw=
=O3jx
-END PGP SIGNATURE-
___
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: watchdogd coredump

2012-11-03 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/3/12 3:13 PM, Garrett Cooper wrote:
 On Sat, Nov 3, 2012 at 2:55 PM, Alexander Leidinger 
 alexan...@leidinger.net mailto:alexan...@leidinger.net wrote:
 
 Hi,
 
 I updated from r239708 to r242511 and my watchdogd coredumps (and 
 brings down the system... well, the WD works).
 
 Before I have a deeper look (recompiling with debugging and such)
 at this, can someone confirm that with a recent -current and a WD 
 configured to call a shell script which does a simple ls to
 /dev/null there is a segfault in watchdogd?
 
 watchdogd_flags=-e /root/bin/wd_check.sh -s 5 -t 60
[...] ^^
 Do you have watchdogd_flags set to something non-standard? Xin
 CCed since he made the last commit.

I think my commit have nothing to do with Alexander's issue, it's
fairly self-contained with no outreaching memory access that could
cause access violation.

I think Kostik was right that he may be running an older version of
kernel with watchdog newer than 239896.  Alexander, can you confirm if
that was the case?

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQlZvBAAoJEG80Jeu8UPuzmXIH/j1w4BFxPEfkj4nipSurLq/n
3jLExTaGho4ElO82HjAx6hK0BO5aLHKG5A5FrLJaD5oH61xqDMg0vjcbtausLUJs
Pknnf91UtWuyZ3odvcrY0Y7Uv1flQvBri6ZpsmJXCqMQvNh2Uks4+0iNi6vRs8dN
eh3igb6tGt+arOwcUohUo60sivTUPl3KVOSRvZlxAuCzrTGwwJ3B2wDSI2aBI34B
qdfUFB1XcZwalCCbI9opKYnVdQOFrTbypVB0aV38IYkRNLPIbKzvDwHbNTA3N8Fz
wHe3qMiN+De23X19sNvfKHDBZtaz3LFfTnyw4eDkaxocEVscUgeSZxJdhDSBaHg=
=ar5w
-END PGP SIGNATURE-
___
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: watchdogd coredump

2012-11-03 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/3/12 3:34 PM, Alexander Leidinger wrote:
 On Sun, 4 Nov 2012 00:08:43 +0200 Konstantin Belousov 
 kostik...@gmail.com wrote:
 
 Are you sure that your kernel is at r242511 ?
 
 The issue should have been fixed by r242011.
 
 # svnversion 242511M
 
 # svn status M   contrib/bind9/bin/named/interfacemgr.c M
 etc/defaults/rc.conf M   etc/rc.d/jail M
 sys/dev/ata/ata-all.c M   sys/dev/drm/drmP.h M
 sys/dev/usb/serial/ulpt.c M   sys/kern/kern_jail.c M
 sys/sys/jail.h M   sys/sys/priv.h M   sys/vm/uma_core.c
 
 The uma_core patch is the one floating around which shall prevent 
 memory fragmentation, the others are mostly my X-in-jail and some
 minor default values (ata, ulpt) changes.
 
 Currently I'm back to the previous kernel+world, but I still have
 the r242511M boot environment available (I have no time to
 investigate the problem this evening, and I want to have a stable
 system until I get time to have a deeper look at this).

What was 'strings /boot/kernel.bad/kernel | tail' saying?

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQlZ8LAAoJEG80Jeu8UPuz2S8IAKfvH1m7L3TQay3tghddaI1k
ohMic676FX/u24lxFpO9ENPxZq28VKyTIKG+5XD2dxfYvX9kRRmfRUVQHHc5Ri2H
c/ZPusPFkOCS3/U74puHvgIF+ypi7110AOC4S+T6whW9D8SVLL/Hauu05CbbjYb1
ef5Vhj0xnxa+XlWhDY6h4QPeduvzulrxhcjJiyiS5aH+ZBMph26cBUfxyrzfMV+2
akJbI0KV0z0AR5HgwS16CLVahApqEuRyXWNmwEuE2c234q0clXarsJS7biDy0X2P
eeFogNkoOJzVbLVOmKtgG1l63yEfAKtDTJURtaOTB7/COG4KkeWolj3elL60MVw=
=a1YO
-END PGP SIGNATURE-
___
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: [head tinderbox] failure on amd64/amd64

2012-10-15 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The attached patch will hopefully fix the build...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQfLF7AAoJEG80Jeu8UPuzblMH+wUf3f24s3Uer0+R50evGz/g
49rC9XmDT4v4CYWV80nUmIzy21ZeuSkKOXOoDjxyknKTz510PtC4PwE4ETNWdE39
vTwSF5lpGfjsDO0mF/uERvJl2EblgDmgaUO9lz4OTbcIX2dA0EIwBTjpQ2hICt6H
ogrqNskoGhNj6b35PW/7901pN9jtrTqViOfvVEy63XgSwBlSdceK3hu398vbWPJw
YB7fBXmnrrtj/Zl93eIOytnfBuD3Cx7RLvl4Q/bRQv5EWD9jb0vY0RvIQ/05Jzbd
qiaSrjx9z821jDxpRMegOZbPU0CGxsZwqS79IJkE9nY+bA42n6RpE7V9PhZuYAE=
=sgg+
-END PGP SIGNATURE-
Index: sys/dev/aha/aha.c
===
--- sys/dev/aha/aha.c   (revision 241599)
+++ sys/dev/aha/aha.c   (working copy)
@@ -62,6 +62,8 @@ __FBSDID($FreeBSD$);
 
 #include sys/param.h
 #include sys/bus.h
+#include sys/conf.h
+#include sys/rman.h
 #include sys/systm.h
 #include sys/malloc.h
 #include sys/kernel.h
@@ -173,8 +175,7 @@ static void ahatimeout(void *arg);
 
 /* Exported functions */
 void
-aha_alloc(struct aha_softc *aha, int unit, bus_space_tag_t tag,
-  bus_space_handle_t bsh)
+aha_alloc(struct aha_softc *aha)
 {
 
SLIST_INIT(aha-free_aha_ccbs);
@@ -1107,7 +1108,7 @@ ahaexecuteccb(void *arg, bus_dma_segment_t *dm_seg
device_printf(aha-dev,
Encountered busy mailbox with %d out of %d 
commands active!!!, aha-active_ccbs, aha-max_ccbs);
-   callout_stop(aacb-timer);
+   callout_stop(accb-timer);
if (nseg != 0)
bus_dmamap_unload(aha-buffer_dmat, accb-dmamap);
ahafreeccb(aha, accb);
@@ -1833,7 +1834,7 @@ ahatimeout(void *arg)
 * later which will attempt a bus reset.
 */
accb-flags |= ACCB_DEVICE_RESET;
-   callout_reset(aacb-timer, 2 * hz, ahatimeout, accb);
+   callout_reset(accb-timer, 2 * hz, ahatimeout, accb);
aha-recovery_accb-hccb.opcode = INITIATOR_BUS_DEV_RESET;
 
/* No Data Transfer */
Index: sys/dev/aha/aha_isa.c
===
--- sys/dev/aha/aha_isa.c   (revision 241599)
+++ sys/dev/aha/aha_isa.c   (working copy)
@@ -62,6 +62,7 @@ __FBSDID($FreeBSD$);
 #include sys/kernel.h
 #include sys/lock.h
 #include sys/mutex.h
+#include sys/rman.h
 
 #include machine/bus.h
 #include machine/resource.h
@@ -126,7 +127,7 @@ aha_isa_probe(device_t dev)
if (aha-port == NULL)
return (ENXIO);
 
-   port_start = rman_get_start(port_res);
+   port_start = rman_get_start(aha-port);
aha_alloc(aha);
 
/* See if there is really a card present */
@@ -261,7 +262,7 @@ aha_isa_attach(device_t dev)
}
 
error = bus_setup_intr(dev, aha-irq, INTR_TYPE_CAM|INTR_ENTROPY|
-   INTR_MPSAFE, NULL, aha_intr, aha, aha-ih);
+   INTR_MPSAFE, NULL, aha_intr, aha, (aha-ih));
if (error) {
device_printf(dev, Unable to register interrupt handler\n);
aha_detach(aha);
@@ -321,9 +322,9 @@ aha_isa_identify(driver_t *driver, device_t parent
 * XXX kldload/kldunload.
 */
rid = 0;
-   aha-port = bus_alloc_resource(parent, SYS_RES_IOPORT, rid,
+   aha.port = bus_alloc_resource(parent, SYS_RES_IOPORT, rid,
ioport, ioport, AHA_NREGS, RF_ACTIVE);
-   if (aha-port == NULL)
+   if (aha.port == NULL)
continue;
aha_alloc(aha);
/* See if there is really a card present */
@@ -336,7 +337,7 @@ aha_isa_identify(driver_t *driver, device_t parent
 * that.
 */
not_this_one:;
-   bus_release_resource(parent, SYS_RES_IOPORT, rid, aha-port);
+   bus_release_resource(parent, SYS_RES_IOPORT, rid, aha.port);
aha_free(aha);
}
 }
Index: sys/dev/aha/ahareg.h
===
--- sys/dev/aha/ahareg.h(revision 241599)
+++ sys/dev/aha/ahareg.h(working copy)
@@ -370,12 +370,12 @@ struct aha_softc {
int  irqrid;
int  portrid;
int  drqrid;
-   void**ih;
+   void*ih;
device_t dev;
struct mtx   lock;
 };
 
-void aha_alloc(struct aha_softc *, int, bus_space_tag_t, bus_space_handle_t);
+void aha_alloc(struct aha_softc *);
 int aha_attach(struct aha_softc *);
 int aha_cmd(struct aha_softc *, aha_op_t, uint8_t *, u_int, uint8_t *, u_int,
 u_int);
@@ -389,11 +389,11 @@ int aha_probe(struct aha_softc *);
 
 #define DEFAULT_CMD_TIMEOUT

boot2/loader: serial port handling

2012-10-12 Thread Xin Li
Hi,

We have some rather hacky quick hack at $WORK that addresses a problem
we have found with boot2/loader and wants to share it and see if we can
have more neat solution.

Here is the problem: the current boot2 and loader have various places
where it considers serial port to exist.  When the port is not there,
the code would hang because it tests whether the hardware's -READY bit,
basically something like:

do {
} while (inpb(state register)  READY_BIT);

This unfortunately would enter an infinite loop when the device is not
present -- all in operations would get all bits set.

To reproduce this, one can compile boot2/loader with non-existent port
and the system will hang at very early stage of boot.

---

Because boot2 is size constrained we can not use very sophisticated
detection logic there, what I did is to use something like:

outb(line control register, word)
if (inb(line control register) != word)
Disable the serial port read/write

For loader I'm not sure if we should use better detection logic.  By the
way, it seems that the system may force using the default console in
loader regardless if the detection logic said no, if it decides that's
the only usable one.

So what would be the right way to solve these issue?

Cheers,
-- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
Index: sys/boot/i386/boot2/boot2.c
===
--- sys/boot/i386/boot2/boot2.c (revision 241434)
+++ sys/boot/i386/boot2/boot2.c (working copy)
@@ -415,8 +415,10 @@ parse()
}
ioctrl = OPT_CHECK(RBX_DUAL) ? (IO_SERIAL|IO_KEYBOARD) :
 OPT_CHECK(RBX_SERIAL) ? IO_SERIAL : IO_KEYBOARD;
-   if (ioctrl  IO_SERIAL)
-   sio_init(115200 / comspeed);
+   if (ioctrl  IO_SERIAL) {
+   if (sio_init(115200 / comspeed))
+   ioctrl = ~IO_SERIAL;
+   }
} else {
for (q = arg--; *q  *q != '('; q++);
if (*q) {
Index: sys/boot/i386/boot2/lib.h
===
--- sys/boot/i386/boot2/lib.h   (revision 241434)
+++ sys/boot/i386/boot2/lib.h   (working copy)
@@ -17,7 +17,7 @@
  * $FreeBSD$
  */
 
-void sio_init(int) __attribute__((regparm (3)));
+int sio_init(int) __attribute__((regparm (3)));
 void sio_flush(void);
 void sio_putc(int) __attribute__((regparm (3)));
 int sio_getc(void);
Index: sys/boot/i386/boot2/sio.S
===
--- sys/boot/i386/boot2/sio.S   (revision 241434)
+++ sys/boot/i386/boot2/sio.S   (working copy)
@@ -24,12 +24,15 @@
.globl sio_getc
.globl sio_ischar
 
-/* void sio_init(int div) */
+/* int sio_init(int div) */
 
 sio_init:  pushl %eax
movw $SIO_PRT+0x3,%dx   # Data format reg
movb $SIO_FMT|0x80,%al  # Set format
outb %al,(%dx)  #  and DLAB
+   inb (%dx),%al
+   cmpb $SIO_FMT|0x80,%al
+   jnz sio_init.1
subb $0x3,%dl   # Divisor latch reg
popl %eax
outw %ax,(%dx)  #  BPS
@@ -41,8 +44,13 @@ sio_init:pushl %eax
outb %al,(%dx)  #  DTR
incl %edx   # Line status reg
call sio_flush
+   xor %eax,%eax
ret
+sio_init.1:popl %eax
+   movb $0x1,%al
+   ret
 
+
 /* void sio_flush(void) */
 
 sio_flush.0:   call sio_getc.1 # Get character
Index: sys/boot/i386/libi386/comconsole.c
===
--- sys/boot/i386/libi386/comconsole.c  (revision 241434)
+++ sys/boot/i386/libi386/comconsole.c  (working copy)
@@ -33,7 +33,7 @@ __FBSDID($FreeBSD$);
 #include libi386.h
 
 #define COMC_FMT   0x3 /* 8N1 */
-#define COMC_TXWAIT0x4 /* transmit timeout */
+#define COMC_TXWAIT0x80/* transmit timeout */
 #define COMC_BPS(x)(115200 / (x))  /* speed to DLAB divisor */
 #define COMC_DIV2BPS(x)(115200 / (x))  /* DLAB divisor to speed */
 
@@ -57,6 +57,7 @@ static intcomc_speed_set(struct env_var *ev, int
 
 static int comc_started;
 static int comc_curspeed;
+static int comc_disabled;
 
 struct console comconsole = {
 comconsole,
@@ -76,9 +77,12 @@ comc_probe(struct console *cp)
 char *cons, *speedenv;
 int speed;
 
-/* XXX check the BIOS equipment list? */
-cp-c_flags |= (C_PRESENTIN | C_PRESENTOUT);
+u_char dlbh;
+u_char dlbl;
+u_char cfcr;
 
+comc_disabled = 0;
+
 if (comc_curspeed == 0) {
comc_curspeed = COMSPEED;
/*
@@ -102,6 +106,22 @@ comc_probe(struct

Re: boot2/loader: serial port handling

2012-10-12 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/12/12 17:04, Garrett Cooper wrote:
 On Fri, Oct 12, 2012 at 4:30 PM, Xin Li delp...@delphij.net
 wrote:
 Hi,
 
 We have some rather hacky quick hack at $WORK that addresses a
 problem we have found with boot2/loader and wants to share it and
 see if we can have more neat solution.
 
 Here is the problem: the current boot2 and loader have various
 places where it considers serial port to exist.  When the port is
 not there, the code would hang because it tests whether the
 hardware's -READY bit, basically something like:
 
 do { } while (inpb(state register)  READY_BIT);
 
 This unfortunately would enter an infinite loop when the device
 is not present -- all in operations would get all bits set.
 
 To reproduce this, one can compile boot2/loader with non-existent
 port and the system will hang at very early stage of boot.
 
 ---
 
 Because boot2 is size constrained we can not use very
 sophisticated detection logic there, what I did is to use
 something like:
 
 outb(line control register, word) if (inb(line control register)
 != word) Disable the serial port read/write
 
 For loader I'm not sure if we should use better detection logic.
 By the way, it seems that the system may force using the default
 console in loader regardless if the detection logic said no, if
 it decides that's the only usable one.
 
 So what would be the right way to solve these issue?
 
 Have you tried out Andriy's commit yet to loader(8) (r241301)?

Ah I wish I am not this far behind my email backlog.  Yes I think
these (241300 and 241301) will solve the problem.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJQeLFFAAoJEG80Jeu8UPuzktAH/3nyrSCrvHWlOSp/eOWf1oMU
KQwzyUXOVgKWCVTHUYHN6tCs0sN1Vguc1n+Q8tqSCuDOJ4/x0lyb6GcyxZv2tf6+
gGYE54yYjf9UDM0HQ3Zb3ZxmH8Z06eH3jK/SlUg8nMXnReLW2v1KkuQ+T3yTyhQH
7vCjOzQylF4CmzpS7l/skNL2lxkJsoD/XROFzRrDAUSK2rdnupjUIxuTXI2G+Bjf
i51qFZk6JRHnecL2c4Zm6ynO65eXyD0Ux7l+FOa00ntOKD33/HJP/Qtpl2UrU+J5
YhMcPUU2uRM3LTSl2D3mtbasrgKQMTmH4syp4ucR7belFPloX7RYjHItQdO6x1M=
=0R8e
-END PGP SIGNATURE-
___
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: sysctl kern.ipc.somaxconn limit 65535 why?

2012-10-03 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 10/03/12 11:45, free...@chrysalisnet.org wrote:
 Hi everyone.
 
 Actually 65k sockets is incredibly easy to reach.

No, this is not kern.ipc.maxsockets.

kern.ipc.somaxconn is for baclkog and not the maximum connections.
Accumulating 64K of pending connection request without giving them
some love (e.g. accept()) means there is something wrong.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJQbJqgAAoJEG80Jeu8UPuz+x0H/2y+aJC1/yotlnjZcjzAmhm2
WpI8l2WNO7oezUH9t6z8SI543Ky0mLjq52oVJTlBWyXuFkGNQdtKJgrbm5hLAiCz
FPojm0p/y3T/ujosunPQl0e/yws6odbEdpGrjSCGJ0VXPQrsWj7NqAJNcDn5hW6m
2wYDkkY9gIxgdfLh8GINvEGO1uY0fyKaPZesepzUsAOOSj/fVdvRK7gSKqaHwDdW
u8VCvfrgD1I1rKj57ymVsf/lpIVPDAv020rJzDnNWWM1dekqzvM7xZ5HiZgkdCca
rTZQGJM3wujuHrjkHP3U5LDMflRWdOHzU236m7vw6jR7ll1xU5GljeNuwp95wFo=
=8tip
-END PGP SIGNATURE-
___
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: sysctl kern.ipc.somaxconn limit 65535 why?

2012-10-03 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/03/12 13:47, Garrett Cooper wrote:
 On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd adr...@freebsd.org
 wrote:
 Hi,
 
 somaxconn is the connection queue depth. If it's sitting at a
 couple hundred thousand then something else is going crazily
 wrong.
 
 I understand your frustration, but there's a lot of instances
 where the application just isn't doing things right and the OS
 tries to hide it as much as psosible. Blowing out somaxconn to
 chew up a whole lot of resources seems a bit silly. I'd rather
 investigate why the userland application is not servicing the
 connect queue often enough.
 
 I've written network services that supported tens of thousands of
 new TCP connections a second on a LAN and I never once had to
 bump somaxconn past 32767. I'm not saying that it won't apply to
 your scenario, I'm just trying to explain that there's likely
 more going on.
 
 Or the TTL of TCP connections might be too high for the volume of 
 connections received. Someone else on net@ reported that changing
 this value to more aggressively reap sockets improved performance
 greatly (at the cost that more connections potentially needing to
 be reestablished and/or getting dropped on the floor if things go
 too high volume).

That's a different topic I think.  On busy web servers it's fairly
typical to have a lot of TCP sockets staying in TIME_WAIT state for
extended time and the usual tuning would be to set MSL to about 2
seconds at the expense of sacrificing slow clients who can't make
3-way handshake in time (*), etc.  The TTL of IP packet have nothing
to do with this though, and our default (64) is saner than many other
operating systems.

 But yeah... the listen(2) queue might be too high, or the 
 application might be accept(2)'ing too much and thus the queue is 
 backing up too much. I was merely providing the pointer to why 
 things are the way they are.

Well, not accept'ing fast enough is a big problem and has to be
solved.  Think about this example: at a shopping center there are a
lot of customers waiting for checkout.  The right solution is not to
draw zigzag lines or to remodel the shopping center's building and
create a large waiting room in order to increase the capacity of the
queue, but to increase the number of cashiers or prioritize simple
cases (like, if you have less than 10 items for checkout, go this queue).

(*) which is actually not a bad idea because the usual web visitors
would just walk away in that case and this can also be used as a
leverage for attacks.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJQbKhIAAoJEG80Jeu8UPuzcZMH/1yzMaKmgyJhfHL3P05SDUdZ
nKx4EEg/4KyA7jkodNzbQONr/icem3uUZ/TnwxTkZ7Aq9Ezg8nqF8RXFXPUqE7V2
H3aptIkRqVt/02SRb1Y3Cd7meqt6ikEQcfQZxT9cFDQWc8BXduyh6J0P6pvaiXSS
he8LVeg5SfT1o43lf8q4N6I/mlPmc2EKhzcrxeNwXOL3jqjHJ7NNPjIX8l4cu6a/
g6JvkDwSVyve6L91b7Jrp1y505aYRlAIioIH9CTcYJx/nQMjXFLYEsJA5dley/sw
1c3IilJ8zJFzLzNmjaUF0emY4QcMYX5eA/gododDEXWF+WjZs2Qv+/w1Fu9McKQ=
=dCYl
-END PGP SIGNATURE-
___
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: Bull Mountain (IvyBridge +) random number generator

2012-09-06 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/02/12 03:34, Konstantin Belousov wrote:
 It is relatively well known that Ivy Bridge CPUs (Core iX 3XXX)
 have built-in hardware random number generator, which is claimed to
 be both very fast and high quality. Generator is accessible using
 non-privileged RDRAND instruction. It is claimed that CPU performs
 sanitization of the random sequence. In particular, it seems that
 paranoid AES encryption of the raw random stream, performed by our
 padlock driver, is not needed for Bull Mountain (there are hints
 that hardware performs it already).
 
 See 
 http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0

 
http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/
 and IA32 ADM.
 
 Patch at http://people.freebsd.org/~kib/misc/bull_mountain.2.patch 
 implements support for the generator. I do not own any IvyBridge
 machines, so I cannot test. Patch makes both padlock and bull
 generators the options, you need to enable IVY_RNG to get support
 for the generator.
 
 I would be interested in seeing reports including verbose boot
 dmesg, and some tests of /dev/random quality on the IvyBridge
 machines, you can start with
 http://lists.gnupg.org/pipermail/gnupg-devel/2000-March/016328.html.

CPU:
 
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (2294.83-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x306a9  Family = 6  Model = 3a
Stepping = 9

Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

Features2=0x7fbae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
...
random: entropy source, Hardware, Intel IvyBridge+ RNG


[delphij@epsilon] ~ dd if=/dev/random bs=1m count=256 | ./ent
256+0 records in
256+0 records out
268435456 bytes transferred in 8.330823 secs (32221961 bytes/sec)
Entropy = 7.99 bits per byte.

Optimum compression would reduce the size
of this 268435456 byte file by 0 percent.

Chi square distribution for 268435456 samples is 237.19, and randomly
would exceed this value 78.17 percent of the times.

Arithmetic mean value of data bytes is 127.4968 (127.5 = random).
Monte Carlo value for Pi is 3.141569721 (error 0.00 percent).
Serial correlation coefficient is -0.80 (totally uncorrelated = 0.0).
[delphij@epsilon] ~ dd if=/dev/random bs=1m count=256 | ./ent
256+0 records in
256+0 records out
268435456 bytes transferred in 8.110786 secs (33096109 bytes/sec)
Entropy = 7.99 bits per byte.

Optimum compression would reduce the size
of this 268435456 byte file by 0 percent.

Chi square distribution for 268435456 samples is 265.06, and randomly
would exceed this value 31.95 percent of the times.

Arithmetic mean value of data bytes is 127.4982 (127.5 = random).
Monte Carlo value for Pi is 3.141918140 (error 0.01 percent).
Serial correlation coefficient is 0.05 (totally uncorrelated = 0.0).
[delphij@epsilon] ~ dd if=/dev/random bs=1m count=256 | ./ent
256+0 records in
256+0 records out
268435456 bytes transferred in 8.094252 secs (33163714 bytes/sec)
Entropy = 7.99 bits per byte.

Optimum compression would reduce the size
of this 268435456 byte file by 0 percent.

Chi square distribution for 268435456 samples is 263.17, and randomly
would exceed this value 34.92 percent of the times.

Arithmetic mean value of data bytes is 127.4969 (127.5 = random).
Monte Carlo value for Pi is 3.141545045 (error 0.00 percent).
Serial correlation coefficient is 0.17 (totally uncorrelated = 0.0).



- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJQSQY2AAoJEG80Jeu8UPuzHTUH/37b3iinQ3/yjc2tfTjKAMZh
KJGEzZ1hlr8Ifoax3ul27U7Mpyss85Vza+tICeiyDpPulFlKuJa9lFfadNXIiDqR
AAB4PtK+cZ8uyVze00sstU+7tK7AqKCyuz/yL6fzK2h2Bx8mYVgE3UTK+DOwQcEa
4Y0pFlO7gPnw1NGK6T7Ofnl/s9wum3JWELPhaTmo5L11JioXnufTmsJpB2MzqSxT
iK0B0FCzF32e1Hl5HNNEMbfx7Rrx+Pf1OzdhP+/1+WHdXn8qtr8htsmsA/4zV+pT
jAHHGuPxNaFmb2xyEZtQerPPdexoadWjrNlFQtl2gsVyMrWYBX2PyT3n3bbos50=
=eiAK
-END PGP SIGNATURE-
___
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


xzexe

2012-06-26 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Here is a small utility that uses xz(1) instead of gzip(1) for
compressing executable, derived from the base system gzexe(1).

http://people.freebsd.org/~delphij/misc/xzexe

There is no plan at this time to put this into base system or a port
unless people thinks it's useful.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJP6issAAoJEG80Jeu8UPuzU14H/3rI6g8FJc+fFaW88LHc5Iwr
psAzBWh/TFlyRvtcN6FmiCCTFy9nxi07P8hqd902Qa9yxRbKItD02hGehZCw/czM
d5fHq5SXF2pJxZznae/TU4xrrZd3niCFJNQReO/bw5a6IooTgW26d6JaBrjGpUf2
eTLcVEzY6MS9DacUnHiwQAdWRdRIxr6ropBlKEIpkbvwNED+BAt9JOkjDP1YrZe5
M+gfzbEU3Lx+X1UBLmtah7zEF+Fwq89Y32KERrcadCvEOP0jqGrDM+njnq8eqk8a
QK9wgxwg+SZLBGbYkVVtZEgIWKldxOBxEDwosizlrPPIJWbpOssc1k9lLsTlZ9U=
=kl8S
-END PGP SIGNATURE-
___
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: Using TMPFS for /tmp and /var/run?

2012-03-29 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/29/12 09:59, Vitaly Magerya wrote:
 Chris Rees utis...@gmail.com wrote:
 Any rc script that complains about an empty /var/run is buggy- it
 should be assumed that it will be emptied on boot.
 
 Then why are there entries for /var/run/{named,ppp,wpa_supplicant} 
 in /etc/mtree/BSD.var.dist? Should they be removed?

No, they are populated by /etc/rc.d/var...

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJPdMsBAAoJEG80Jeu8UPuzug4H/joM719VK0TeISLSRusdcdnQ
9k0VnmuBtxUgzh+Wrsb/Ka5jROg39+hVLHKEIszMrZ1Ip85YW4JpnL1cq2OJ+ZKV
dXFt8b8KVPcO0XBMAnvaD8x7J9emrNQU54VMhumAun+IpyGXTvATBCPaPB5zewMJ
DAai5rSXi/jOdjdXmgxydtRsaXdwR4dHlQ/EPmpby9pnxEwqRjQHkl4ZvTYC0yNU
+UCffIqbQsn/Zerwxzg9NnTSjVDKNgN192xhsDJN9hXDAFro1aG2LMSA4iYPxsYH
ge0P6cO21qb7fRDB6KdHB/qUF1zcTt9cw+IsWKmBV3qN+GkDiB7vtKJa7hX/1XE=
=3B8C
-END PGP SIGNATURE-
___
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


  1   2   >