Early use of log() does not end up in kernel msg buffer
Using log(9) when no process is reading the log results in the message going only to the console (contrast with printf(9), which goes to the console and to the kernel message buffer in this case). I believe it is truer to the semantics of logging for messages to *always* go to the message buffer (where they can eventually be collected and in fact put into a logfile). I therefore propose the attached patch, which sends log(9) to the message buffer always, and to the console only if no one has yet opened the log. It may be more complete to log to the console only if the log level is greater than some (user defined) value, but this seems like that might be more than necessary for this case. Thoughts? Eric diff --git share/man/man9/printf.9 share/man/man9/printf.9 index 84ac822..505ea9b 100644 --- share/man/man9/printf.9 +++ share/man/man9/printf.9 @@ -67,7 +67,8 @@ The .Fn log function sends the message to the kernel logging facility, using the log level as indicated by -.Fa pri . +.Fa pri , +and to the console if no process is yet reading the log. .Pp Each of these related functions use the .Fa fmt diff --git sys/kern/subr_prf.c sys/kern/subr_prf.c index 7e6fd09..6509522 100644 --- sys/kern/subr_prf.c +++ sys/kern/subr_prf.c @@ -295,7 +295,7 @@ log(int level, const char *fmt, ...) va_list ap; va_start(ap, fmt); - (void)_vprintf(level, log_open ? TOLOG : TOCONS, fmt, ap); + (void)_vprintf(level, log_open ? TOLOG : TOCONS | TOLOG, fmt, ap); va_end(ap); msgbuftrigger = 1; ___ 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"
11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598
Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. Both of the following exist: /usr/src/sys/netinet/sctp.h /usr/include/netinet/sctp.h The first can be newer than the 2nd during buildworld. The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an updated /usr/src can/does end up using the second instead of the first, at least for the powerpc64-xtoolchain-gcc style of buildworld activity that I am trying. The recent addition of SCTP_MAX_CWND ends up with its definition missing because of this: during the build /usr/include/netinet/sctp.h ends up being the file included and the compile fails from the missing additional definition. Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the command line arguments should force the /usr/src/sys/netinet/sctp.h vintage file to be found. The 3 netinet/ relevant includes are shown below... > ... > #include > #include > #include > #include More than sctp.h might have such issues since there are 3 netinet/ include paths in /head/lib/libc/net/sctp_sys_calls.c . I have not checked for other .c files with similar issues for usage during buildworld. The problem details: /head/lib/libc/net/sctp_sys_calls.c -r279859 added: > case SCTP_MAX_CWND: > ((struct sctp_assoc_value *)arg)->assoc_id = id; > break; and head (20150325 r280598) contains it. But the SCTP_MAX_CWND reference blocks buildworld (for at least /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc (powerpc64-xtoolchain=gcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 -pipe > -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include > -I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE > -I/usr/src/lib/libc/../../contrib/gdtoa > -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 > -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd > -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime > -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN > -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING > -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /usr/src/lib/libc/net/sctp_sys_calls.c -o sctp_sys_calls.So > > /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info': > /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND' > undeclared (first use in this function) > case SCTP_MAX_CWND: ^ Looking to see where usage and definitions might be in /usr/src for -r280598 ... > # pwd > /usr/src > $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep > SCTP_MAX_CWND {} \; -print \) | more > case SCTP_MAX_CWND: > ./lib/libc/net/sctp_sys_calls.c > case SCTP_MAX_CWND: > case SCTP_MAX_CWND: > ./sys/netinet/sctp_usrreq.c > #define SCTP_MAX_CWND 0x0032 > ./sys/netinet/sctp.h And looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c for -r279859 shows: > #include > __FBSDID("$FreeBSD$"); > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include That there was no complaint about sctp.h being missing suggests that a was found but did not contain a SCTP_MAX_CWND definition: so a different one than the above find/grep reported. Using a find to report other sctp.h files shows: > # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h -print > \) | more > /usr/src/sys/netinet/sctp.h > /usr/include/netinet/sctp.h The diff of those shows the problem if the wrong file is found and used: > # diff /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h > 34c34 > < __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 15:50:16Z > tuexen $"); > --- > > __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 19:49:25Z > > tuexen $"); > 130a131 > > #define SCTP_MAX_CWND 0x0032 Context details: > make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc > WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \ > WITHOUT_LLDB= \ > WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \ > WITHOUT_BOOT= WITHOUT_LIB32= \ > buildworld buildkernel \ > KERNCONF=GENERIC64vtsc-NODEBUG > TARGET=powerpc TARGET_ARCH=powerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository
Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11
all set are in base. and I’m using 10.1-RELEASE-p8 BTW > 在 2015年3月26日,下午6:12,Mike Tancsa 写道: > > On 3/26/2015 2:44 AM, Wu ShuKun wrote: > >> OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 >> failed with Latest SSH: >> % ssh -V >> OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 > > Hi, > The latest is 1.0.1m, no? > > }# ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 > > What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or > in the base ? > > ---Mike > > -- > --- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, m...@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On 03/26/15 22:37, Adrian Chadd wrote: Is there a PR filed with this? No, do you want me to make one? --HPS ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On 03/26/15 22:37, Adrian Chadd wrote: Is there a PR filed with this? There is now: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198936 --HPS ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
Is there a PR filed with this? -a On 26 March 2015 at 14:00, Jakob Alvermark wrote: > On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote: >> Hi, >> >> >> Without the attached kernel patch(es), Xorg starts consuming alot of CPU >> and becomes very unresponsive and unusable. >> >> Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR >> over and over again with no apparent reason. It doesn't happen when using a >> simple window manager like blackbox. I was not able to use XFCE4 (9-stable >> userland) with 11-current kernel at all, after the latest DRM2 kernel >> updates. It worked fine before the update. >> >> I'm not sure what is causing it. Going through the new DRM2 code >> revealed that a mode sorting function did not take all parameters like >> interlaced or not into account, causing the mode list to be reshuffelled >> every time a new mode scan was done. Not sure if Xorg cares about this >> though. > > I got the same problem with XFCE4, Xorg at 100% CPU. > > Applied the patch and it works again. > > Jakob > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote: > Hi, > > > Without the attached kernel patch(es), Xorg starts consuming alot of CPU > and becomes very unresponsive and unusable. > > Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR > over and over again with no apparent reason. It doesn't happen when using a > simple window manager like blackbox. I was not able to use XFCE4 (9-stable > userland) with 11-current kernel at all, after the latest DRM2 kernel > updates. It worked fine before the update. > > I'm not sure what is causing it. Going through the new DRM2 code > revealed that a mode sorting function did not take all parameters like > interlaced or not into account, causing the mode list to be reshuffelled > every time a new mode scan was done. Not sure if Xorg cares about this > though. I got the same problem with XFCE4, Xorg at 100% CPU. Applied the patch and it works again. Jakob ___ 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: Mbuf leak in if_lagg.c
On 26.03.2015 22:42, Andrey V. Elsukov wrote: >> If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it. >> >> Can you look at this ? > > Hi, > > what you thing about this patch? > lp_detaching can be non zero in case of parent interface departure. > So I don't see the reason to call ETHER_BPF_MTAP() in this case. Now I see the reason - to capture all received packets before interface departure. New is attached. -- WBR, Andrey V. Elsukov Index: if_lagg.c === --- if_lagg.c (revision 280234) +++ if_lagg.c (working copy) @@ -1669,7 +1669,11 @@ lagg_input(struct ifnet *ifp, struct mbuf *m) ETHER_BPF_MTAP(scifp, m); - m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; + if (lp->lp_detaching != 0) { + m_freem(m); + m = NULL; + } else + m = lagg_proto_input(sc, lp, m); if (m != NULL) { if (scifp->if_flags & IFF_MONITOR) { signature.asc Description: OpenPGP digital signature
Re: Mbuf leak in if_lagg.c
On 19.03.2015 19:31, Alexandre Martins wrote: > Hi ! > > I found a leak of mbuf in the lagg driver : > > https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672 > > -=-=-=-=-=-=-=-=-=-=- > m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; > -=-=-=-=-=-=-=-=-=-=- > > If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it. > > Can you look at this ? Hi, what you thing about this patch? lp_detaching can be non zero in case of parent interface departure. So I don't see the reason to call ETHER_BPF_MTAP() in this case. -- WBR, Andrey V. Elsukov Index: if_lagg.c === --- if_lagg.c (revision 280234) +++ if_lagg.c (working copy) @@ -1661,7 +1661,8 @@ lagg_input(struct ifnet *ifp, struct mbuf *m) LAGG_RLOCK(sc, &tracker); if ((scifp->if_drv_flags & IFF_DRV_RUNNING) == 0 || (lp->lp_flags & LAGG_PORT_DISABLED) || - sc->sc_proto == LAGG_PROTO_NONE) { + sc->sc_proto == LAGG_PROTO_NONE || + lp->lp_detaching != 0) { LAGG_RUNLOCK(sc, &tracker); m_freem(m); return (NULL); @@ -1668,9 +1669,7 @@ lagg_input(struct ifnet *ifp, struct mbuf *m) } ETHER_BPF_MTAP(scifp, m); - - m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; - + m = lagg_proto_input(sc, lp, m); if (m != NULL) { if (scifp->if_flags & IFF_MONITOR) { m_freem(m); signature.asc Description: OpenPGP digital signature
Re: Mbuf leak in if_lagg.c
Hi! Please file a bug! https://bugs.freebsd.org/submit/ Thanks! -a On 19 March 2015 at 09:31, Alexandre Martins wrote: > Hi ! > > I found a leak of mbuf in the lagg driver : > > https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672 > > -=-=-=-=-=-=-=-=-=-=- > m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; > -=-=-=-=-=-=-=-=-=-=- > > If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it. > > Can you look at this ? > > Regards > > -- > Alexandre Martins > STORMSHIELD > ___ 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"
Mbuf leak in if_lagg.c
Hi ! I found a leak of mbuf in the lagg driver : https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672 -=-=-=-=-=-=-=-=-=-=- m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; -=-=-=-=-=-=-=-=-=-=- If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it. Can you look at this ? Regards -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11
greeting! ssh connection failed by using a new version SSH to and old one. Below is the symptoms which on a same network. Connection is Okay with old version SSH %ssh -V OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 %ssh -v 10.41.172.19 OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.4p1 FreeBSD-20100308 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host '10.41.172.19 (10.41.172.19)' can't be established. RSA key fingerprint is ab:81:83:79:6a:d8:29:23:a0:51:1d:e6:f0:aa:ce:d6. Are you sure you want to continue connecting (yes/no)? --- failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 % ssh -v 10.41.172.19 OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ed25519 type -1 debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5* compat 0x0c00 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 10.41.172.19 any ideas? ___ 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: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11
On 3/26/2015 2:44 AM, Wu ShuKun wrote: OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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"
Suspend sometimes hangs the whole system
Hello, Normally suspend/resume is working fine on my Lenovo Thinkpad T61. But sometimes, when I press the power button to suspend, the whole system hangs and does not suspend. In X11 the mouse cursor goes away and no mouse action is possible. The graphics screen is staying there and it does not switch to console as on a normal suspend. Also manually switching to a console screen is not possible. Even the ssh daemon does not respond when I try to login thhroug ssh from some other pc. Looks like sshd is already sleeping. The only way to get it back to life is a hard reset. How can I investigate this problem further? -- Mit besten Grüßen Jochen Fahrner ___ 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"