Re: Do we have a CPUTYPE=native and/or generic stability problem?
On Sat, Nov 3, 2012 at 5:24 PM, Alexander Leidinger alexan...@leidinger.net wrote: Hi, while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. The r239708 world runs stable since I installed it (build with CPUTYPE=native). The r242511 world (no CPUTYPE set) doesn't run stable (not only the watchdogd segfault I reported in another mail some minutes ago, but also some other kind of reboot every X minutes I haven't investigated yet). Does someone run -current on a similar system on a similar revision and can comment about the stability? Not sure if your hitting the same bug, that was found in PR 112997. When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for a patch to bsd.cpu.mk. Does your system compile correctly, if you specify the CPUTYPE? Scot ___ 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: weird network problems on current since 10/28/2012
On 2012-11-04 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote: i have problem connecting to freebsd box on local network since last sunday. the last kernel that works: FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012 anything after that, sometimes i can connect, other times just hangs. any network connection hangs = pop httpd ssh etc etc. anyone have any ideas ? i can checkout different sources and see if i can locate the changes that cause this. Please do! ... Here is what I found doing : setenv CVSROOT /usr/home/ncvs cvs co -DOctober 28, 2012 12:14:38 PDT sys A kernel from that time works fine. doing: cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later the following files were changed: sys/netinet/tcp_input.c sys/netinet/tcp_timer.c sys/netinet/tcp_var.h Building a kernel from these new files is when the problem starts. So, your problems seem to have been introduced by this commit by Andre: http://svn.freebsd.org/changeset/base/242266 Increase the initial CWND to 10 segments as defined in IETF TCPM draft-ietf-tcpm-initcwnd-05. It explains why the increased initial window improves the overall performance of many web services without risking congestion collapse. As long as it remains a draft it is placed under a sysctl marking it as experimental: net.inet.tcp.experimental.initcwnd10 = 1 When it becomes an official RFC soon the sysctl will be changed to the RFC number and moved to net.inet.tcp. This implementation differs from the RFC draft in that it is a bit more conservative in the case of packet loss on SYN or SYN|ACK because we haven't reduced the default RTO to 1 second yet. Also the restart window isn't yet increased as allowed. Both will be adjusted with upcoming changes. Is is enabled by default. In Linux it is enabled since kernel 3.0. After the commit, there was a small discussion thread on svn-src-head@ about the possible problems with the approach. Maybe you are experiencing those? As the commit message says, you should be able to turn the feature off using: sysctl net.inet.tcp.experimental.initcwnd10=0 Can you please try that, and see if the problems go away? ___ 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: weird network problems on current since 10/28/2012
On 04.11.2012 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote: i have problem connecting to freebsd box on local network since last sunday. the last kernel that works: FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012 anything after that, sometimes i can connect, other times just hangs. any network connection hangs = pop httpd ssh etc etc. anyone have any ideas ? i can checkout different sources and see if i can locate the changes that cause this. Please do! adrian OK Here is what I found doing : setenv CVSROOT /usr/home/ncvs cvs co -DOctober 28, 2012 12:14:38 PDT sys A kernel from that time works fine. doing: cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later the following files were changed: sys/netinet/tcp_input.c sys/netinet/tcp_timer.c sys/netinet/tcp_var.h Building a kernel from these new files is when the problem starts. Can you please provide one or more tcpdump from a failing kernel? Also please enable sysctl net.inet.tcp.logdebug=1 and capture LOG_DEBUG output from syslogd. That may give some important information as well. -- Andre ___ 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: weird network problems on current since 10/28/2012
Could this be same problem - PR/173309 ? -- Regards, Alexander Yerenkow ___ 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: SU+J on 9.1-RC2 ISO
Hi all.
The point is:
There is completely no way to take a snapshot of SU+J partition
unless modify one's kernel.
Whether some issue still exist or not,
how about enabling snapshoting SU+J partition
through sysctl variable?
Would you mind to see patch attached?
1. Taking a snapshot of SU+J partition is controlled through sysctl variable.
2. Default to disable.
One who want to enable it should set the variable manually.
3. The default value in bsdinstall(8) may be left as is.
--
HATANO Tomomi.--- src/sys/ufs/ffs/ffs_snapshot.c.orig 2012-11-04 11:01:58.0 +0900
+++ src/sys/ufs/ffs/ffs_snapshot.c 2012-11-04 11:13:32.0 +0900
@@ -182,8 +182,10 @@
*/
int dopersistence = 0;
-#ifdef DEBUG
#include sys/sysctl.h
+int snapsuj = 0;
+SYSCTL_INT(_debug, OID_AUTO, snapsuj, CTLFLAG_RW, snapsuj, 0, );
+#ifdef DEBUG
SYSCTL_INT(_debug, OID_AUTO, dopersistence, CTLFLAG_RW, dopersistence, 0, );
static int snapdebug = 0;
SYSCTL_INT(_debug, OID_AUTO, snapdebug, CTLFLAG_RW, snapdebug, 0, );
@@ -230,7 +232,7 @@
* At the moment, journaled soft updates cannot support
* taking snapshots.
*/
- if (MOUNTEDSUJ(mp)) {
+ if (MOUNTEDSUJ(mp) (snapsuj == 0)) {
vfs_mount_error(mp, %s: Snapshots are not yet supported when
running with journaled soft updates, fs-fs_fsmnt);
return (EOPNOTSUPP);
___
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: weird network problems on current since 10/28/2012
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote: On 2012-11-04 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote: i have problem connecting to freebsd box on local network since last sunday. the last kernel that works: FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012 anything after that, sometimes i can connect, other times just hangs. any network connection hangs = pop httpd ssh etc etc. anyone have any ideas ? i can checkout different sources and see if i can locate the changes that cause this. Please do! ... Here is what I found doing : setenv CVSROOT /usr/home/ncvs cvs co -DOctober 28, 2012 12:14:38 PDT sys A kernel from that time works fine. doing: cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later the following files were changed: sys/netinet/tcp_input.c sys/netinet/tcp_timer.c sys/netinet/tcp_var.h Building a kernel from these new files is when the problem starts. So, your problems seem to have been introduced by this commit by Andre: http://svn.freebsd.org/changeset/base/242266 Increase the initial CWND to 10 segments as defined in IETF TCPM draft-ietf-tcpm-initcwnd-05. It explains why the increased initial window improves the overall performance of many web services without risking congestion collapse. As long as it remains a draft it is placed under a sysctl marking it as experimental: net.inet.tcp.experimental.initcwnd10 = 1 When it becomes an official RFC soon the sysctl will be changed to the RFC number and moved to net.inet.tcp. This implementation differs from the RFC draft in that it is a bit more conservative in the case of packet loss on SYN or SYN|ACK because we haven't reduced the default RTO to 1 second yet. Also the restart window isn't yet increased as allowed. Both will be adjusted with upcoming changes. Is is enabled by default. In Linux it is enabled since kernel 3.0. After the commit, there was a small discussion thread on svn-src-head@ about the possible problems with the approach. Maybe you are experiencing those? As the commit message says, you should be able to turn the feature off using: sysctl net.inet.tcp.experimental.initcwnd10=0 Can you please try that, and see if the problems go away? FWIW this did not make the problem go away here. thanks -kim -- ___ 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: November 5th is Clang-Day
On Saturday, 3 November 2012 23:47:54 Jan Beich wrote: David Naylor naylor.b.da...@gmail.com writes: There are two issues here: 1) wine compiled with clang, and 2) wine (compiled with gcc) running on clang compiled base. Regarding 1), according to the wiki [1], wine does have stack alignment issues and some wine programs do not run when compiled with clang [2][3] and other bugs with clang cause freezing within wine [4][5]. The impression I get is that, using the work-a-round of stack realignment, wine does work to some extent when compiled by clang. Took me some time but now I can confirm that clang-built wine-1.5.16 works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32). Regarding 2) (which I believe Jan was referring to), when I have a gcc built world and just replace lib32 with clang built libraries I have winecfg and regedit launching but displaying black screens. Switching back to gcc built lib32 I get a working winecfg and regedit. This, to me, indicates a clang error somewhere. My experience varies between clang-built and gcc-built wine. # clang, quick crash # gcc, black rectangle So, why not switch stack alignment in wine (upstream)? This would make /stable/9 wine package continue to work on /head. Here's my wine package built with and without the patch. # sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz # sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. regards signature.asc Description: This is a digitally signed message part.
[solved]: r2421600 amd64 /var/db/pkg
On Sat, 3 Nov 2012, Garrett Cooper wrote: On Sat, Nov 3, 2012 at 6:15 PM, Darrel levi...@iglou.com wrote: ... Yes, the existing man 8 pkg does not seem to match all of the facts. What you probably ran into is the common chicken and egg problem where if pkgng is upgraded ports, it blows up when it tries to deinstall the package, or similarly, when portmaster is upgraded, it doesn't halt the upgrade and restart it properly. It's most likely still a problem; I'm going to doublecheck to make sure that's the case and file PRs if it is. Thanks, Garrett. For my current problem I am simply going to delete the errant portmaster-3.14 from /var/db/pkg and then run 'portmaster -a -f -D' with the hope that portmaster-3.14_7 can fix things. If not I will try reinstalling, the are only a few things installed- freeradius, postgresql, and about a dozen others. Darrel___ 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: November 5th is Clang-Day
On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: On Saturday, 3 November 2012 23:47:54 Jan Beich wrote: David Naylor naylor.b.da...@gmail.com writes: There are two issues here: 1) wine compiled with clang, and 2) wine (compiled with gcc) running on clang compiled base. Regarding 1), according to the wiki [1], wine does have stack alignment issues and some wine programs do not run when compiled with clang [2][3] and other bugs with clang cause freezing within wine [4][5]. The impression I get is that, using the work-a-round of stack realignment, wine does work to some extent when compiled by clang. Took me some time but now I can confirm that clang-built wine-1.5.16 works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32). Regarding 2) (which I believe Jan was referring to), when I have a gcc built world and just replace lib32 with clang built libraries I have winecfg and regedit launching but displaying black screens. Switching back to gcc built lib32 I get a working winecfg and regedit. This, to me, indicates a clang error somewhere. My experience varies between clang-built and gcc-built wine. # clang, quick crash # gcc, black rectangle So, why not switch stack alignment in wine (upstream)? This would make /stable/9 wine package continue to work on /head. Here's my wine package built with and without the patch. # sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz # sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. I tried to gather the evidence for the case, but apparent submitter of the bug stopped replying to the requests. pgp5HBA7jVYvc.pgp Description: PGP signature
Re: Do we have a CPUTYPE=native and/or generic stability problem?
Le dimanche 4 novembre 2012, Scot Hetzel a écrit : When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. This comes regularly in the lists. Try setting the correct CPUTYPE for your CPU, and if you want to use native somewhere, add -march=native to your CFLAGS. There's another option to use so that *.mk don't add another -march with your CPUTYPE automatically. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: weird network problems on current since 10/28/2012
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar wrote:
At 03:29 PM 11/3/2012, Adrian Chadd wrote:
On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote:
i have problem connecting to freebsd box on local network since last sunday.
the last kernel that works:
FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012
anything after that, sometimes i can connect, other times just hangs.
any network connection hangs = pop httpd ssh etc etc.
anyone have any ideas ?
i can checkout different sources and see if i can locate the changes that cause
this.
Please do!
...
Here is what I found doing :
setenv CVSROOT /usr/home/ncvs
cvs co -DOctober 28, 2012 12:14:38 PDT sys
A kernel from that time works fine.
doing:
cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later
the following files were changed:
sys/netinet/tcp_input.c
sys/netinet/tcp_timer.c
sys/netinet/tcp_var.h
Building a kernel from these new files is when the problem starts.
So, your problems seem to have been introduced by this commit by Andre:
http://svn.freebsd.org/changeset/base/242266
Increase the initial CWND to 10 segments as defined in IETF TCPM
draft-ietf-tcpm-initcwnd-05. It explains why the increased initial
window improves the overall performance of many web services without
risking congestion collapse.
As long as it remains a draft it is placed under a sysctl marking it
as experimental:
net.inet.tcp.experimental.initcwnd10 = 1
When it becomes an official RFC soon the sysctl will be changed to
the RFC number and moved to net.inet.tcp.
This implementation differs from the RFC draft in that it is a bit
more conservative in the case of packet loss on SYN or SYN|ACK because
we haven't reduced the default RTO to 1 second yet. Also the restart
window isn't yet increased as allowed. Both will be adjusted with
upcoming changes.
Is is enabled by default. In Linux it is enabled since kernel 3.0.
After the commit, there was a small discussion thread on svn-src-head@
about the possible problems with the approach. Maybe you are
experiencing those?
As the commit message says, you should be able to turn the feature off
using:
sysctl net.inet.tcp.experimental.initcwnd10=0
Can you please try that, and see if the problems go away?
FWIW this did not make the problem go away on 2 machines.
Yes, this very much looks like the same problem as in PR/173309.
Please try the attached patch. It fixes the connection hang issue.
There may be a second issue I debugging currently base on the feedback
from Fabian Keil.
--
Andre
Index: tcp_input.c
===
--- tcp_input.c (revision 242494)
+++ tcp_input.c (working copy)
@@ -2650,10 +2652,12 @@
SOCKBUF_LOCK(so-so_snd);
if (acked so-so_snd.sb_cc) {
+ tp-snd_wnd -= so-so_snd.sb_cc;
sbdrop_locked(so-so_snd, (int)so-so_snd.sb_cc);
ourfinisacked = 1;
} else {
sbdrop_locked(so-so_snd, acked);
+ tp-snd_wnd -= acked;
ourfinisacked = 0;
}
/* NB: sowwakeup_locked() does an implicit unlock. */
___
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: weird network problems on current since 10/28/2012
At 03:21 AM 11/4/2012, Dimitry Andric wrote: On 2012-11-04 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote: i have problem connecting to freebsd box on local network since last sunday. the last kernel that works: FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012 anything after that, sometimes i can connect, other times just hangs. any network connection hangs = pop httpd ssh etc etc. anyone have any ideas ? i can checkout different sources and see if i can locate the changes that cause this. Please do! ... Here is what I found doing : setenv CVSROOT /usr/home/ncvs cvs co -DOctober 28, 2012 12:14:38 PDT sys A kernel from that time works fine. doing: cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later the following files were changed: sys/netinet/tcp_input.c sys/netinet/tcp_timer.c sys/netinet/tcp_var.h Building a kernel from these new files is when the problem starts. So, your problems seem to have been introduced by this commit by Andre: http://svn.freebsd.org/changeset/base/242266 Increase the initial CWND to 10 segments as defined in IETF TCPM draft-ietf-tcpm-initcwnd-05. It explains why the increased initial window improves the overall performance of many web services without risking congestion collapse. As long as it remains a draft it is placed under a sysctl marking it as experimental: net.inet.tcp.experimental.initcwnd10 = 1 When it becomes an official RFC soon the sysctl will be changed to the RFC number and moved to net.inet.tcp. This implementation differs from the RFC draft in that it is a bit more conservative in the case of packet loss on SYN or SYN|ACK because we haven't reduced the default RTO to 1 second yet. Also the restart window isn't yet increased as allowed. Both will be adjusted with upcoming changes. Is is enabled by default. In Linux it is enabled since kernel 3.0. After the commit, there was a small discussion thread on svn-src-head@ about the possible problems with the approach. Maybe you are experiencing those? As the commit message says, you should be able to turn the feature off using: sysctl net.inet.tcp.experimental.initcwnd10=0 Can you please try that, and see if the problems go away? I read the commit log and tried that. It didn't change. I will try the patch from Andre and enable the debug log. Manfred || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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: November 5th is Clang-Day
On 2012-11-04 14:18, Konstantin Belousov wrote: On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: ... I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. So we really must use 4 byte stack alignment on i386 by default? I have attached a diff to llvm for this, but I would like to verify that it is really correct. Apparently Darwin, Linux and Solaris all use 16 byte alignment. The Sys V ABI seems to say only: The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary. Index: contrib/llvm/lib/Target/X86/X86Subtarget.cpp === --- contrib/llvm/lib/Target/X86/X86Subtarget.cpp (revision 242480) +++ contrib/llvm/lib/Target/X86/X86Subtarget.cpp (working copy) @@ -416,12 +416,12 @@ X86Subtarget::X86Subtarget(const std::string TT, assert((!In64BitMode || HasX86_64) 64-bit code requested on a subtarget that doesn't support it!); - // Stack alignment is 16 bytes on Darwin, FreeBSD, Linux and Solaris (both - // 32 and 64 bit) and for all 64-bit targets. + // Stack alignment is 16 bytes on Darwin, Linux and Solaris (both 32 and 64 + // bit) and for all 64-bit targets. if (StackAlignOverride) -stackAlignment = StackAlignOverride; - else if (isTargetDarwin() || isTargetFreeBSD() || isTargetLinux() || - isTargetSolaris() || In64BitMode) + stackAlignment = StackAlignOverride; + else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || + In64BitMode) stackAlignment = 16; } ___ 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: November 5th is Clang-Day
On Sun, Nov 04, 2012 at 03:29:42PM +0100, Dimitry Andric wrote: On 2012-11-04 14:18, Konstantin Belousov wrote: On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: ... I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. So we really must use 4 byte stack alignment on i386 by default? I have attached a diff to llvm for this, but I would like to verify that it is really correct. Apparently Darwin, Linux and Solaris all use 16 byte alignment. No, this is a misunderstanding. We must provide libraries that tolerate the 4-byte aligned stack. Also, to be compatible with broken compilers (both older versions of gcc and some versions of clang) we must provide the libraries which preserve the %esp mod 0x10 across the functions entry/leave points. The crt ensures that the stack is 16-byte aligned on entry to main. The Sys V ABI seems to say only: The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary. Right, this is ABI which some binaries follow. There are some other binaries, generated by arguably broken compilers, which require 16-byte alignment. The system shall support both. Index: contrib/llvm/lib/Target/X86/X86Subtarget.cpp === --- contrib/llvm/lib/Target/X86/X86Subtarget.cpp (revision 242480) +++ contrib/llvm/lib/Target/X86/X86Subtarget.cpp (working copy) @@ -416,12 +416,12 @@ X86Subtarget::X86Subtarget(const std::string TT, assert((!In64BitMode || HasX86_64) 64-bit code requested on a subtarget that doesn't support it!); - // Stack alignment is 16 bytes on Darwin, FreeBSD, Linux and Solaris (both - // 32 and 64 bit) and for all 64-bit targets. + // Stack alignment is 16 bytes on Darwin, Linux and Solaris (both 32 and 64 + // bit) and for all 64-bit targets. if (StackAlignOverride) -stackAlignment = StackAlignOverride; - else if (isTargetDarwin() || isTargetFreeBSD() || isTargetLinux() || - isTargetSolaris() || In64BitMode) + stackAlignment = StackAlignOverride; + else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || + In64BitMode) stackAlignment = 16; } pgpT25Yuwri50.pgp Description: PGP signature
Re: weird network problems on current since 10/28/2012
At 05:57 AM 11/4/2012, you wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar wrote:
At 03:29 PM 11/3/2012, Adrian Chadd wrote:
On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote:
i have problem connecting to freebsd box on local network since last
sunday.
the last kernel that works:
FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012
anything after that, sometimes i can connect, other times just hangs.
any network connection hangs = pop httpd ssh etc etc.
anyone have any ideas ?
i can checkout different sources and see if i can locate the changes that
cause
this.
Please do!
...
Here is what I found doing :
setenv CVSROOT /usr/home/ncvs
cvs co -DOctober 28, 2012 12:14:38 PDT sys
A kernel from that time works fine.
doing:
cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later
the following files were changed:
sys/netinet/tcp_input.c
sys/netinet/tcp_timer.c
sys/netinet/tcp_var.h
Building a kernel from these new files is when the problem starts.
So, your problems seem to have been introduced by this commit by Andre:
http://svn.freebsd.org/changeset/base/242266
Increase the initial CWND to 10 segments as defined in IETF TCPM
draft-ietf-tcpm-initcwnd-05. It explains why the increased initial
window improves the overall performance of many web services without
risking congestion collapse.
As long as it remains a draft it is placed under a sysctl marking it
as experimental:
net.inet.tcp.experimental.initcwnd10 = 1
When it becomes an official RFC soon the sysctl will be changed to
the RFC number and moved to net.inet.tcp.
This implementation differs from the RFC draft in that it is a bit
more conservative in the case of packet loss on SYN or SYN|ACK because
we haven't reduced the default RTO to 1 second yet. Also the restart
window isn't yet increased as allowed. Both will be adjusted with
upcoming changes.
Is is enabled by default. In Linux it is enabled since kernel 3.0.
After the commit, there was a small discussion thread on svn-src-head@
about the possible problems with the approach. Maybe you are
experiencing those?
As the commit message says, you should be able to turn the feature off
using:
sysctl net.inet.tcp.experimental.initcwnd10=0
Can you please try that, and see if the problems go away?
FWIW this did not make the problem go away on 2 machines.
Yes, this very much looks like the same problem as in PR/173309.
Please try the attached patch. It fixes the connection hang issue.
There may be a second issue I debugging currently base on the feedback
from Fabian Keil.
--
Andre
Index: tcp_input.c
===
--- tcp_input.c (revision 242494)
+++ tcp_input.c (working copy)
@@ -2650,10 +2652,12 @@
SOCKBUF_LOCK(so-so_snd);
if (acked so-so_snd.sb_cc) {
+ tp-snd_wnd -= so-so_snd.sb_cc;
sbdrop_locked(so-so_snd, (int)so-so_snd.sb_cc);
ourfinisacked = 1;
} else {
sbdrop_locked(so-so_snd, acked);
+ tp-snd_wnd -= acked;
ourfinisacked = 0;
}
/* NB: sowwakeup_locked() does an implicit unlock. */
This patch improves the connection issue, not hanging on trying to connect (ssh
pop)
It still seems that it is taking longer to connect though. But in the end the
connection goes through.
I can capture a tcpdump and put it at http://pozo.com/tcpdump/tpdump.txt if
that will help.
I'll let it run for about 1/2 hour.
Manfred
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
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: [solved]: r2421600 amd64 /var/db/pkg
On 11/4/2012 5:06 AM, Darrel wrote: On Sat, 3 Nov 2012, Garrett Cooper wrote: On Sat, Nov 3, 2012 at 6:15 PM, Darrel levi...@iglou.com wrote: ... Yes, the existing man 8 pkg does not seem to match all of the facts. What you probably ran into is the common chicken and egg problem where if pkgng is upgraded ports, it blows up when it tries to deinstall the package, or similarly, when portmaster is upgraded, it doesn't halt the upgrade and restart it properly. It's most likely still a problem; I'm going to doublecheck to make sure that's the case and file PRs if it is. Thanks, Garrett. For my current problem I am simply going to delete the errant portmaster-3.14 from /var/db/pkg and then run 'portmaster -a -f -D' with the hope that portmaster-3.14_7 can fix things. If not I will try reinstalling, the are only a few things installed- freeradius, postgresql, and about a dozen others. This is overkill. You either have a pkg_install database or a pkgng database. Determining which will save you time. After you run pkg2ng, pkg_info will no longer work. It will complain about corrupted packages, since all the data is gone, but portmaster has stored additional information there, which confuses pkg_info. Check the output of 'pkg info'. If it lists all your packages, you are done. Nothing more to do. If not, run pkg2ng. Also, you can see any packages that have not converted with: find /var/db/pkg -name +CONTENTS If nothing comes up, they are already all converted. Bryan ___ 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: November 5th is Clang-Day
On 11/04/12 08:29, Dimitry Andric wrote: On 2012-11-04 14:18, Konstantin Belousov wrote: On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: ... I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. So we really must use 4 byte stack alignment on i386 by default? I have attached a diff to llvm for this, but I would like to verify that it is really correct. Apparently Darwin, Linux and Solaris all use 16 byte alignment. The Sys V ABI seems to say only: The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary. This is an ugly business. The stack is really 4 bytes aligned on Linux and Solaris too, but GCC decided to unilaterally change the ABI a few years ago (also on FreeBSD). You can find a chunk of the sordid story of this in a number of GCC bugs marked WONTFIX (e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496). To pacify the people who were yelling about it, they added some __attribute__(()) foo and compiler flags to change what it uses for specific programs and add magic to realign the stack at boundaries. So much water has passed under the bridge at this point as to reach flood stage, so I think the correct solution here is to add the same __attribute__(()) and flags to clang rather than changing the default alignment back to 4. Changing it only on FreeBSD is especially wrong. -Nathan ___ 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: [solved]: r2421600 amd64 /var/db/pkg
What you probably ran into is the common chicken and egg problem where if pkgng is upgraded ports, it blows up when it tries to deinstall the package, or similarly, when portmaster is upgraded, it doesn't halt the upgrade and restart it properly. It's most likely still a problem; I'm going to doublecheck to make sure that's the case and file PRs if it is. Thanks, Garrett. For my current problem I am simply going to delete the errant portmaster-3.14 from /var/db/pkg and then run 'portmaster -a -f -D' with the hope that portmaster-3.14_7 can fix things. If not I will try reinstalling, the are only a few things installed- freeradius, postgresql, and about a dozen others. This is overkill. You either have a pkg_install database or a pkgng database. Determining which will save you time. After you run pkg2ng, pkg_info will no longer work. It will complain about corrupted packages, since all the data is gone, but portmaster has stored additional information there, which confuses pkg_info. Check the output of 'pkg info'. If it lists all your packages, you are done. Nothing more to do. If not, run pkg2ng. Also, you can see any packages that have not converted with: find /var/db/pkg -name +CONTENTS If nothing comes up, they are already all converted. Thanks, Bryan. Actually my fbsd10 machine already has portmaster reinstalling, which seems to be running alright. It has less than two dozen packages on it. I am looking at a fbsd9.1 machine right now, and it seems like a strange case considering your advice. If I run 'pkg info' or 'pkg_info' then all of the packages are listed. If I run 'find /var/db/pkg -name +CONTENTS' then all of the packages are found. Yet on that machine in /etc/make.conf exists 'WITH_PKGNG=yes' and I ran pkg2ng on the 15th of October. Darrel ___ 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
[head tinderbox] failure on mips64/mips
TB --- 2012-11-04 19:40:55 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-04 19:40:55 - 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 --- 2012-11-04 19:40:55 - starting HEAD tinderbox run for mips64/mips TB --- 2012-11-04 19:40:55 - cleaning the object tree TB --- 2012-11-04 19:40:55 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-04 19:40:55 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-11-04 19:40:55 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:41:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:41:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:41:54 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:42:24 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:42:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:42:24 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:43:24 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:43:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:43:24 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:44:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:44:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:44:54 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:46:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:46:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:46:54 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:46:54 - 2.78 user 4.02 system 359.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full ___ 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
[head tinderbox] failure on powerpc/powerpc
TB --- 2012-11-04 19:46:54 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-04 19:46:54 - 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 --- 2012-11-04 19:46:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-11-04 19:46:54 - cleaning the object tree TB --- 2012-11-04 19:46:54 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-04 19:46:54 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2012-11-04 19:46:54 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:48:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:48:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:48:02 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:48:32 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:48:32 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:48:32 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:49:32 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:49:32 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:49:32 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:51:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:51:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:51:02 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:53:02 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:53:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:53:02 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:53:02 - 2.84 user 3.88 system 367.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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: kernel module parallel build?
On 22.10.2012 15:28, John Baldwin wrote: On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote: What's keeping kernel modules from building in parallel with make -j8? They don't for you? They do for me either via 'make buildkernel' or the old method. They do, but only partially. Within a module the files are built in parallel. However the module directories seem to be serialized. I'm a Makefile noob though. -- Andre ___ 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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-11-04 19:53:02 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-04 19:53:02 - 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 --- 2012-11-04 19:53:02 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-11-04 19:53:02 - cleaning the object tree TB --- 2012-11-04 19:53:02 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-04 19:53:02 - cd /tinderbox/HEAD/powerpc64/powerpc TB --- 2012-11-04 19:53:02 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:53:46 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:53:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:53:46 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:54:16 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:54:16 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:54:16 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:55:16 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:55:16 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:55:16 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:56:46 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:56:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:56:46 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:58:46 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:58:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:58:46 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:58:46 - 3.01 user 3.77 system 343.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-11-04 19:58:46 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-04 19:58:46 - 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 --- 2012-11-04 19:58:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-11-04 19:58:46 - cleaning the object tree TB --- 2012-11-04 19:58:46 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-04 19:58:46 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-11-04 19:58:46 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:59:14 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:59:14 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:59:14 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:59:44 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:59:44 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:59:44 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 20:00:44 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:00:44 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:00:44 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 20:02:14 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:02:14 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:02:14 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 20:04:14 - /usr/local/bin/svn update /src TB --- 2012-11-04 20:04:14 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 20:04:14 - ERROR: unable to check out the source tree TB --- 2012-11-04 20:04:14 - 2.79 user 3.84 system 327.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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
[head tinderbox] failure on mips/mips
TB --- 2012-11-04 19:35:19 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-04 19:35:19 - 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 --- 2012-11-04 19:35:19 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-04 19:35:19 - cleaning the object tree TB --- 2012-11-04 19:35:19 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-04 19:35:19 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-04 19:35:19 - /usr/local/bin/svn cleanup /src TB --- 2012-11-04 19:35:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:35:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:35:54 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-04 19:36:24 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:36:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:36:24 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-04 19:37:24 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:37:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:37:24 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-04 19:38:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:38:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:38:54 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-04 19:40:54 - /usr/local/bin/svn update /src TB --- 2012-11-04 19:40:54 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-04 19:40:54 - ERROR: unable to check out the source tree TB --- 2012-11-04 19:40:54 - 2.95 user 3.45 system 335.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ 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: weird network problems on current since 10/28/2012
On 04.11.12 14:57, Andre Oppermann wrote: On 04.11.2012 13:11, Kim Culhan wrote: On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote: On 2012-11-04 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote: i have problem connecting to freebsd box on local network since last sunday. the last kernel that works: FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012 anything after that, sometimes i can connect, other times just hangs. any network connection hangs = pop httpd ssh etc etc. anyone have any ideas ? i can checkout different sources and see if i can locate the changes that cause this. Please do! ... Here is what I found doing : setenv CVSROOT /usr/home/ncvs cvs co -DOctober 28, 2012 12:14:38 PDT sys A kernel from that time works fine. doing: cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour later the following files were changed: sys/netinet/tcp_input.c sys/netinet/tcp_timer.c sys/netinet/tcp_var.h Building a kernel from these new files is when the problem starts. So, your problems seem to have been introduced by this commit by Andre: http://svn.freebsd.org/changeset/base/242266 Increase the initial CWND to 10 segments as defined in IETF TCPM draft-ietf-tcpm-initcwnd-05. It explains why the increased initial window improves the overall performance of many web services without risking congestion collapse. As long as it remains a draft it is placed under a sysctl marking it as experimental: net.inet.tcp.experimental.initcwnd10 = 1 When it becomes an official RFC soon the sysctl will be changed to the RFC number and moved to net.inet.tcp. This implementation differs from the RFC draft in that it is a bit more conservative in the case of packet loss on SYN or SYN|ACK because we haven't reduced the default RTO to 1 second yet. Also the restart window isn't yet increased as allowed. Both will be adjusted with upcoming changes. Is is enabled by default. In Linux it is enabled since kernel 3.0. After the commit, there was a small discussion thread on svn-src-head@ about the possible problems with the approach. Maybe you are experiencing those? As the commit message says, you should be able to turn the feature off using: sysctl net.inet.tcp.experimental.initcwnd10=0 Can you please try that, and see if the problems go away? FWIW this did not make the problem go away on 2 machines. Yes, this very much looks like the same problem as in PR/173309. Please try the attached patch. It fixes the connection hang issue. There may be a second issue I debugging currently base on the feedback from Fabian Keil. I jump into this thread since I have a similar network issue. My scenario: 'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive. The nfs drive on the server is an ufs fs. No zfs. Up to r242261 I can install the kernel (or world) in a fluent way to the nfs destination. From r242262 it doesn't work smooth. I have stalls, sometimes my patience is not enough and I kill the process. I tried 242266 with the above mentioned patch. No real success. How can I help/test? TIA, Andreas ___ 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
On Sat, 03 Nov 2012 15:47:39 -0700 Xin Li delp...@delphij.net wrote: -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? I verified at boot that the kernel was booting the right kernel: ---snip--- # strings /rpool/ROOT/r242511M/boot/kernel/kernel | tail [...] @(#)FreeBSD 10.0-CURRENT #10 r242511M: Sat Nov 3 17:49:09 CET 2012 FreeBSD 10.0-CURRENT #10 r242511M: Sat Nov 3 17:49:09 CET 2012 r...@andromeda.leidinger.net:/usr/obj/space/system/usr_src/sys/ANDROMEDA [...] ---snip--- Anything special you want me to investigate? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 04 Nov 2012 00:46:15 +0100 Dimitry Andric d...@freebsd.org wrote: On 2012-11-03 23:24, Alexander Leidinger wrote: while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. Hm, at first I thought you might be running out of RAM, but apparently that is not the case then. :) The machine has 12 MB RAM (no swap configured), after nearly a day uptime it looks like this: ---snip--- Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other ---snip--- I would not expect an internal compiler error when I run out of RAM. The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. What does gcc detect for this CPU with -march=native? You can do: gcc -march=native -v -c -x c /dev/null 21 | grep -- -march to see what it passes to the second stage. ---snip--- # gcc -march=native -v -c -x c /dev/null 21 | grep -- -march /usr/libexec/cc1 -quiet -v -D_LONGLONG /dev/null -march=core2 -mtune=generic -quiet -dumpbase null -auxbase null -version -o /tmp//cc7kc0JI.s ---snip--- Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: weird network problems on current since 10/28/2012
On 04.11.2012 21:15, Andreas Tobler wrote:
On 04.11.12 14:57, Andre Oppermann wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar wrote:
At 03:29 PM 11/3/2012, Adrian Chadd wrote:
After the commit, there was a small discussion thread on svn-src-head@
about the possible problems with the approach. Maybe you are
experiencing those?
As the commit message says, you should be able to turn the feature off
using:
sysctl net.inet.tcp.experimental.initcwnd10=0
Can you please try that, and see if the problems go away?
FWIW this did not make the problem go away on 2 machines.
Yes, this very much looks like the same problem as in PR/173309.
Please try the attached patch. It fixes the connection hang issue.
There may be a second issue I debugging currently base on the feedback
from Fabian Keil.
I jump into this thread since I have a similar network issue.
My scenario:
'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive.
The nfs drive on the server is an ufs fs. No zfs.
Up to r242261 I can install the kernel (or world) in a fluent way to the
nfs destination.
From r242262 it doesn't work smooth. I have stalls, sometimes my
patience is not enough and I kill the process.
I tried 242266 with the above mentioned patch. No real success.
How can I help/test?
Please try the attach patch instead of the above mentioned one.
--
Andre
Index: netinet/tcp_output.c
===
--- netinet/tcp_output.c(revision 242577)
+++ netinet/tcp_output.c(working copy)
@@ -228,7 +228,7 @@
tso = 0;
mtu = 0;
off = tp-snd_nxt - tp-snd_una;
- sendwin = min(tp-snd_wnd, tp-snd_cwnd);
+ sendwin = ulmax(ulmin(tp-snd_wnd - off, tp-snd_cwnd), 0);
flags = tcp_outflags[tp-t_state];
/*
@@ -249,7 +249,7 @@
(p = tcp_sack_output(tp, sack_bytes_rxmt))) {
long cwin;
- cwin = min(tp-snd_wnd, tp-snd_cwnd) - sack_bytes_rxmt;
+ cwin = ulmin(tp-snd_wnd - off, tp-snd_cwnd) - sack_bytes_rxmt;
if (cwin 0)
cwin = 0;
/* Do not retransmit SACK segments beyond snd_recover */
@@ -355,7 +355,7 @@
* sending new data, having retransmitted all the
* data possible in the scoreboard.
*/
- len = ((long)ulmin(so-so_snd.sb_cc, tp-snd_wnd)
+ len = ((long)ulmin(so-so_snd.sb_cc, tp-snd_wnd - off)
- off);
/*
* Don't remove this (len 0) check !
___
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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 4 Nov 2012 14:43:30 +0100 Olivier Smedts oliv...@gid0.org wrote: Le dimanche 4 novembre 2012, Scot Hetzel a écrit : When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. This comes regularly in the lists. This basically means we need to do something about it. Try setting the correct CPUTYPE for your CPU, and if you want to use native somewhere, add -march=native to your CFLAGS. There's another option to use so that *.mk don't add another -march with your CPUTYPE automatically. We either should bail out if someone uses native as CPUTYPE, or we should make it just work. Personally I don't have a preference for one or the other, important is that the user gets a behavior he can count on. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 4 Nov 2012 03:43:13 -0600 Scot Hetzel swhet...@gmail.com wrote: Not sure if your hitting the same bug, that was found in PR 112997. When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for a patch to bsd.cpu.mk. I try to get a look at it this week. Does your system compile correctly, if you specify the CPUTYPE? I haven't tried it yet. I will give it a try later. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: weird network problems on current since 10/28/2012
On 04.11.12 22:57, Andre Oppermann wrote: On 04.11.2012 21:15, Andreas Tobler wrote: On 04.11.12 14:57, Andre Oppermann wrote: On 04.11.2012 13:11, Kim Culhan wrote: On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote: On 2012-11-04 02:13, Manfred Antar wrote: At 03:29 PM 11/3/2012, Adrian Chadd wrote: After the commit, there was a small discussion thread on svn-src-head@ about the possible problems with the approach. Maybe you are experiencing those? As the commit message says, you should be able to turn the feature off using: sysctl net.inet.tcp.experimental.initcwnd10=0 Can you please try that, and see if the problems go away? FWIW this did not make the problem go away on 2 machines. Yes, this very much looks like the same problem as in PR/173309. Please try the attached patch. It fixes the connection hang issue. There may be a second issue I debugging currently base on the feedback from Fabian Keil. I jump into this thread since I have a similar network issue. My scenario: 'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive. The nfs drive on the server is an ufs fs. No zfs. Up to r242261 I can install the kernel (or world) in a fluent way to the nfs destination. From r242262 it doesn't work smooth. I have stalls, sometimes my patience is not enough and I kill the process. I tried 242266 with the above mentioned patch. No real success. How can I help/test? Please try the attach patch instead of the above mentioned one. Test run based on 242266. It starts much smoother. But it stalls later on. Continues, stalls for several seconds, cont. thx so far. Andreas 1391 0 D+ 0:00.00 install -o root -g wheel -m 555 crypto.ko /netboot/test_install procstat -kk 1391 PIDTID COMM TDNAME KSTACK 1391 100099 install -mi_switch+0x186 sleepq_timedwait+0x42 _sleep+0x1c9 clnt_vc_call+0x763 clnt_reconnect_call+0xfb newnfs_request+0xadb nfscl_request+0x72 nfsrpc_setattr+0x28f nfs_setattr+0x2b0 VOP_SETATTR_APV+0x31 setfmode+0x101 vn_chmod+0x8a sys_fchmod+0x8b amd64_syscall+0x55f Xfast_syscall+0xf7 ___ 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: weird network problems on current since 10/28/2012
At 01:57 PM 11/4/2012, you wrote:
On 04.11.2012 21:15, Andreas Tobler wrote:
On 04.11.12 14:57, Andre Oppermann wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar wrote:
At 03:29 PM 11/3/2012, Adrian Chadd wrote:
After the commit, there was a small discussion thread on svn-src-head@
about the possible problems with the approach. Maybe you are
experiencing those?
As the commit message says, you should be able to turn the feature off
using:
sysctl net.inet.tcp.experimental.initcwnd10=0
Can you please try that, and see if the problems go away?
FWIW this did not make the problem go away on 2 machines.
Yes, this very much looks like the same problem as in PR/173309.
Please try the attached patch. It fixes the connection hang issue.
There may be a second issue I debugging currently base on the feedback
from Fabian Keil.
I jump into this thread since I have a similar network issue.
My scenario:
'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive.
The nfs drive on the server is an ufs fs. No zfs.
Up to r242261 I can install the kernel (or world) in a fluent way to the
nfs destination.
From r242262 it doesn't work smooth. I have stalls, sometimes my
patience is not enough and I kill the process.
I tried 242266 with the above mentioned patch. No real success.
How can I help/test?
Please try the attach patch instead of the above mentioned one.
--
Andre
Index: netinet/tcp_output.c
===
--- netinet/tcp_output.c(revision 242577)
+++ netinet/tcp_output.c(working copy)
@@ -228,7 +228,7 @@
tso = 0;
mtu = 0;
off = tp-snd_nxt - tp-snd_una;
- sendwin = min(tp-snd_wnd, tp-snd_cwnd);
+ sendwin = ulmax(ulmin(tp-snd_wnd - off, tp-snd_cwnd), 0);
flags = tcp_outflags[tp-t_state];
/*
@@ -249,7 +249,7 @@
(p = tcp_sack_output(tp, sack_bytes_rxmt))) {
long cwin;
- cwin = min(tp-snd_wnd, tp-snd_cwnd) - sack_bytes_rxmt;
+ cwin = ulmin(tp-snd_wnd - off, tp-snd_cwnd) -
sack_bytes_rxmt;
if (cwin 0)
cwin = 0;
/* Do not retransmit SACK segments beyond snd_recover */
@@ -355,7 +355,7 @@
* sending new data, having retransmitted all the
* data possible in the scoreboard.
*/
- len = ((long)ulmin(so-so_snd.sb_cc, tp-snd_wnd)
+ len = ((long)ulmin(so-so_snd.sb_cc, tp-snd_wnd - off)
- off);
/*
* Don't remove this (len 0) check !
This doesn't seem to make a difference.
I have a ssh window thats been trying to connect for the past 5 minutes.
This is on a local network 192.168.0.4 ===SSH==
192.168.0.5
Also pop from the same machines endless trying to connect.
Hopefully this mail will get thru , otherwise i will need to reboot to old
kernel
Manfred
|| n...@pozo.com ||
|| Ph. (415) 681-6235 ||
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
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: ULE patch, call for testers
On 2012/11/03 02:26, Jeff Roberson wrote: I have a small patch to the ULE scheduler that makes a fairly large change to the way timeshare threads are handled. http://people.freebsd.org/~jeff/schedslice.diff Previously ULE used a fixed slice size for all timeshare threads. Now it scales the slice size down based on load. This should reduce latency for timeshare threads as load increases. It is important to note that this does not impact interactive threads. But when a thread transitions to interactive from timeshare it should see some improvement. This happens when something like Xorg chews up a lot of CPU. If anyone has perf tests they'd like to run please report back. I have done a handful of validation. Thanks, Jeff Another problem I remembered is that a thread on runqueue may be starved because ULE treats a sleeping thread and a thread waiting on runqueue differently. If a thread has slept for a while, after it is woken up, its priority is boosted, but for a thread on runqueue, its priority will never be boosted. In essential, they should be same becase both of them are waiting for cpu. If I am a thread, I'd like to wait on sleep queue rather than on runqueue, since in former case, I will get bonus, while in later case, I'll get nothing. Under heavy load, there are many runnable threads, this unfair can cause a very low priority thread on runqueue to be starved. 4BSD seems not suffer from this problem, because it also decay cpu time of thread on runqueue. I think ULE needs some anti-starvation code to give thread a shot if it is waiting on runqueue too long time. Regards, David Xu ___ 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
Dynamic Ticks/HZ
Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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: Dynamic Ticks/HZ
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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 Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. -- Davide ___ 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: Dynamic Ticks/HZ
Davide Italiano wrote: On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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 Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. I'm also using a one second refresh rate, the system is entirely idle and the interupt rate is almost entirely static at 1127, occasionally it will drop to 1119. From what I understand the timer is hz/ticks which became dynamic in 9.0, although that behaviour doesn't appear to be in HEAD anymore, at least on this hardware. Thanks, J ___ 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: Dynamic Ticks/HZ
On Nov 4, 2012 10:40 PM, Joe Holden li...@rewt.org.uk wrote: Davide Italiano wrote: On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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 Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. I'm also using a one second refresh rate, the system is entirely idle and the interupt rate is almost entirely static at 1127, occasionally it will drop to 1119. From what I understand the timer is hz/ticks which became dynamic in 9.0, although that behaviour doesn't appear to be in HEAD anymore, at least on this hardware. Thanks, J It should be available, AFAIK. As I can see from your previous post you get about 20 interrupts on cpu1. This number is about 1/100 of the value you get on a !tickless kernel. If you provide the required ktr infos, probably someone will take a look. ___ 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
