Re: panic when loading mlxen
That's odd since it doesn't use any of taskqgroup stuff. I take it you can't get a core? Also, why are you loading it in loader.conf (slower) as opposed to rc.conf? -M On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss wrote: > with latest stable (r328769) when I have > mlxen_load=“YES” > in my loader.conf it panics: > > KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 > f > KDB: current backend: ddb > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 >danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 > FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM > 5.0.1) > VT(vga): resolution 640x480 > CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz K8-class > CPU) > Origin="GenuineIntel" Id=0x106a5 Family=0x6 Model=0x1a Stepping=5 > > Features=0xbfebfbff > > Features2=0x9ce3bd > AMD Features=0x28100800 > AMD Features2=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID > TSC: P-state invariant, performance statistics > real memory = 25769803776 (24576 MB) > avail memory = 24931561472 (23776 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > ioapic1: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 10 > fault virtual address = 0x1818 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0x80ad427f > stack pointer = 0x28:0x822e3be0 > frame pointer = 0x28:0x822e3c30 > code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [ thread pid 0 tid 10 ] > Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq %r12,(%rdi) > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: suspend/resume on Skylake (Lenovo T460s) with FreeBSD11 stable
You need a graphics driver that supports suspend. That's only going to be i915. Right now suspend / resume doesn't work in drm-next-4.7 for anything newer than Broadwell. Your two choices for Skylake are either to debug the issue in drm-next or add suspend / resume to sc or VT. I'm assuming that if the latter were easy someone would already have done it. On Mon, Dec 19, 2016 at 13:37 Brandon Allbery wrote: > On Mon, Dec 19, 2016 at 10:09 AM, Andreas Nilsson > > wrote: > > > > > my Lenovo X1 yoga exhibits the same traits, it does suspend, but graphics > > > are corrupted after resume. Machine usually is reachable over the network > > > though. > > > > > > > Isn't that related to sc vs. vt? Various video cards, notably many NVidia > > based, don't recover from suspend. sc can't reinitialize them. vt can, and > > knows how to reinit some cards but needs to be taught how to reinit others. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allber...@gmail.com > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gdb broken on stable/11 and current?
It does, the path arguments are different. I've used kgdb7111 for the last year. On Thu, Dec 8, 2016 at 08:57 Slawa Olhovchenkov wrote: > On Thu, Dec 08, 2016 at 04:52:35PM +0000, K. Macy wrote: > > > > > kgdb7111 is what you use for kernel. It works fine for me. > > > > kgdb7111 don't find .debug under /usr/lib/debug/ > > gdb found it. > > > > > On Thu, Dec 8, 2016 at 08:29 Slawa Olhovchenkov wrote: > > > > > > > On Thu, Dec 08, 2016 at 04:01:04PM +, K. Macy wrote: > > > > > > > > > > > > > > > > > In tree gdb doesn't work for much of anything these days. It can't > even > > > > > > > > > consistently give a complete kernel backtrace. Jhb is graciously > > > > > > > > > maintaining gdb in ports. It will be installed as the awkwardly named > > > > > > > > > gdb7111 IIRC. > > > > > > > > > > > > > > > > 1. gdb7111 badly integrated w/ 11 and up (don't see kernel debug > > > > > > > > symbols) > > > > > > > > 2. all included in base systems can't be core dumped. > > > > > > > > > > > > > > > > > On Thu, Dec 8, 2016 at 06:53 Slawa Olhovchenkov > wrote: > > > > > > > > > > > > > > > > > > > % gdb ./edge_stat > > > > > > > > > > > > > > > > > > > > GNU gdb 6.1.1 [FreeBSD] > > > > > > > > > > > > > > > > > > > > Copyright 2004 Free Software Foundation, Inc. > > > > > > > > > > > > > > > > > > > > GDB is free software, covered by the GNU General Public License, > and > > > > you > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > welcome to change it and/or distribute copies of it under certain > > > > > > > > > > conditions. > > > > > > > > > > > > > > > > > > > > Type "show copying" to see the conditions. > > > > > > > > > > > > > > > > > > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > > details. > > > > > > > > > > > > > > > > > > > > This GDB was configured as "amd64-marcel-freebsd"... > > > > > > > > > > > > > > > > > > > > (gdb) break main > > > > > > > > > > > > > > > > > > > > Segmentation fault (core dumped) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > % gdb /usr/bin/gdb /tmp/gdb.13573.core > > > > > > > > > > > > > > > > > > > > GNU gdb 6.1.1 [FreeBSD] > > > > > > > > > > > > > > > > > > > > Copyright 2004 Free Software Foundation, Inc. > > > > > > > > > > > > > > > > > > > > GDB is free software, covered by the GNU General Public License, > and > > > > you > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > welcome to change it and/or distribute copies of it under certain > > > > > > > > > > conditions. > > > > > > > > > > > > > > > > > > > > Type "show copying" to see the conditions. > > > > > > > > > > > > > > > > > > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > > details. > > > > > > > > > > > > > > > > > > > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > > > > symbols > > > > > > > > > > found)... > > > > > > > > > > > > > > > > > > > > Core was generated by `gdb'. > > > > > > > > > > > > > > > > > > > > Program terminated with
Re: gdb broken on stable/11 and current?
kgdb7111 is what you use for kernel. It works fine for me. On Thu, Dec 8, 2016 at 08:29 Slawa Olhovchenkov wrote: > On Thu, Dec 08, 2016 at 04:01:04PM +0000, K. Macy wrote: > > > > > In tree gdb doesn't work for much of anything these days. It can't even > > > consistently give a complete kernel backtrace. Jhb is graciously > > > maintaining gdb in ports. It will be installed as the awkwardly named > > > gdb7111 IIRC. > > > > 1. gdb7111 badly integrated w/ 11 and up (don't see kernel debug > > symbols) > > 2. all included in base systems can't be core dumped. > > > > > On Thu, Dec 8, 2016 at 06:53 Slawa Olhovchenkov wrote: > > > > > > > % gdb ./edge_stat > > > > > > > > GNU gdb 6.1.1 [FreeBSD] > > > > > > > > Copyright 2004 Free Software Foundation, Inc. > > > > > > > > GDB is free software, covered by the GNU General Public License, and > you > > > > are > > > > > > > > welcome to change it and/or distribute copies of it under certain > > > > conditions. > > > > > > > > Type "show copying" to see the conditions. > > > > > > > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > > > > > > > This GDB was configured as "amd64-marcel-freebsd"... > > > > > > > > (gdb) break main > > > > > > > > Segmentation fault (core dumped) > > > > > > > > > > > > > > > > % gdb /usr/bin/gdb /tmp/gdb.13573.core > > > > > > > > GNU gdb 6.1.1 [FreeBSD] > > > > > > > > Copyright 2004 Free Software Foundation, Inc. > > > > > > > > GDB is free software, covered by the GNU General Public License, and > you > > > > are > > > > > > > > welcome to change it and/or distribute copies of it under certain > > > > conditions. > > > > > > > > Type "show copying" to see the conditions. > > > > > > > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > > > > > > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols > > > > found)... > > > > > > > > Core was generated by `gdb'. > > > > > > > > Program terminated with signal 11, Segmentation fault. > > > > > > > > Reading symbols from /lib/libm.so.5...(no debugging symbols > found)...done. > > > > > > > > Loaded symbols for /lib/libm.so.5 > > > > > > > > Reading symbols from /lib/libncursesw.so.8...(no debugging symbols > > > > found)...done. > > > > > > > > Loaded symbols for /lib/libncursesw.so.8 > > > > > > > > Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols > > > > found)...done. > > > > > > > > Loaded symbols for /usr/lib/libgnuregex.so.5 > > > > > > > > Reading symbols from /lib/libc.so.7...(no debugging symbols > found)...done. > > > > > > > > Loaded symbols for /lib/libc.so.7 > > > > > > > > Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols > > > > found)...done. > > > > > > > > Loaded symbols for /usr/lib/libthread_db.so > > > > > > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > > > > found)...done. > > > > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > > > > > #0 0x005da00b in cplus_demangle_v3_callback () > > > > > > > > (gdb) bt > > > > > > > > #0 0x005da00b in cplus_demangle_v3_callback () > > > > > > > > #1 0x005d9f9c in cplus_demangle_v3 () > > > > > > > > #2 0x005ca13c in cplus_demangle () > > > > > > > > #3 0x00487454 in class_name_from_physname () > > > > > > > > #4 0x0053a4f3 in dwarf2_read_section () > > > > > > > > #5 0x0053a0cc in dwarf2_read_section () > > > > > > > > #6 0x00539bd9 in dwarf2_read_section () > > > > > > > > #7 0x00537395 in dwarf2_read_section () > > > > > > > > #8 0x0
Re: gdb broken on stable/11 and current?
In tree gdb doesn't work for much of anything these days. It can't even consistently give a complete kernel backtrace. Jhb is graciously maintaining gdb in ports. It will be installed as the awkwardly named gdb7111 IIRC. On Thu, Dec 8, 2016 at 06:53 Slawa Olhovchenkov wrote: > % gdb ./edge_stat > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "amd64-marcel-freebsd"... > > (gdb) break main > > Segmentation fault (core dumped) > > > > % gdb /usr/bin/gdb /tmp/gdb.13573.core > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > found)... > > Core was generated by `gdb'. > > Program terminated with signal 11, Segmentation fault. > > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > > Loaded symbols for /lib/libm.so.5 > > Reading symbols from /lib/libncursesw.so.8...(no debugging symbols > found)...done. > > Loaded symbols for /lib/libncursesw.so.8 > > Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols > found)...done. > > Loaded symbols for /usr/lib/libgnuregex.so.5 > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > Loaded symbols for /lib/libc.so.7 > > Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols > found)...done. > > Loaded symbols for /usr/lib/libthread_db.so > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x005da00b in cplus_demangle_v3_callback () > > (gdb) bt > > #0 0x005da00b in cplus_demangle_v3_callback () > > #1 0x005d9f9c in cplus_demangle_v3 () > > #2 0x005ca13c in cplus_demangle () > > #3 0x00487454 in class_name_from_physname () > > #4 0x0053a4f3 in dwarf2_read_section () > > #5 0x0053a0cc in dwarf2_read_section () > > #6 0x00539bd9 in dwarf2_read_section () > > #7 0x00537395 in dwarf2_read_section () > > #8 0x00539c21 in dwarf2_read_section () > > #9 0x00539643 in dwarf2_read_section () > > #10 0x00538a6c in dwarf2_read_section () > > #11 0x005352fb in dwarf2_read_section () > > #12 0x00533bfd in dwarf2_read_section () > > #13 0x004cfc46 in psymtab_to_symtab () > > #14 0x004c9cfb in lookup_symbol_global () > > #15 0x00482273 in cp_lookup_symbol_namespace () > > #16 0x00482059 in cp_lookup_symbol_nonlocal () > > #17 0x00481f63 in cp_lookup_symbol_nonlocal () > > #18 0x004c9780 in lookup_symbol () > > #19 0x005035cf in find_imps () > > #20 0x00514df9 in decode_line_1 () > > #21 0x00514589 in decode_line_1 () > > #22 0x0046eff9 in _initialize_breakpoint () > > #23 0x0046f48b in _initialize_breakpoint () > > #24 0x004ab289 in catch_exceptions () > > #25 0x004ab368 in catch_exceptions_with_msg () > > #26 0x0046b169 in break_command () > > #27 0x004ab996 in execute_command () > > #28 0x00465293 in gdb_disable_readline () > > #29 0x00465182 in gdb_setup_readline () > > #30 0x005e266f in rl_callback_read_char () > > #31 0x00464c79 in gdb_setup_readline () > > #32 0x00465a46 in gdb_do_one_event () > > #33 0x004ab289 in catch_exceptions () > > #34 0x004ab42a in catch_errors () > > #35 0x00551168 in _initialize_tui_interp () > > #36 0x00448689 in gdb_main () > > #37 0x004ab289 in catch_exceptions () > > #38 0x004ab42a in catch_errors () > > #39 0x00448526 in gdb_main () > > #40 0x004ab289 in catch_exceptions () > > #41 0x004ab42a in catch_errors () > > #42 0x00447977 in gdb_main () > > #43 0x00447931 in main () > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for Compilers on FreeBSD 11
On Wed, Aug 31, 2016 at 3:55 PM, Erich Dollansky wrote: > Hi, > > On Wed, 31 Aug 2016 12:16:16 -0700 > "K. Macy" wrote: > >> On Wednesday, August 31, 2016, Mark Linimon >> wrote: >> >> > But for me an attraction has always been "you can build it out of >> > the box", even if I rarely do it (e.g. I am not working in the >> > kernel/driver area), >> > >> >> Can clang actually bootstrap from something like lcc? As far as I can >> tell you need a fairly advanced C++ compiler just to build that >> compiler in src >> - which already needs to be installed. It's not exactly bootstrapping >> from Bourne shell. So I'm not sure "it's self-hosting" is even true, >> not to mention that you needed a network connection to get src in the >> first place. Thus the whole argument strikes me as circular if not >> outright deceptive. >> > what do you want to say? > > CLang builds on FreeBSD after installing FreeBSD either binary or from > source. If the installation is older, it might be required to move up > the version ladder step by step. > > The only problem I see is the time it take to build it. As long it is > the choice a user has, it is part of the game. > > Or with your words, it is not a shell. The argument I've been given for including clang is that doing so makes the FreeBSD base somehow self-contained. But the fact is that FreeBSD can't be built on anything but FreeBSD with an existing modern C++ compiler. In order to actually bootstrap it with something less you'd need to start by bootstrapping gcc. Beyond core pieces like the kernel, libc, ls, and sh what constitutes an intrinsic part of "base" is highly subjective. Very few people today would consider the results of a buildworld a complete system. I asked JKH, a fellow former committer, about it and his take was: "[it] is probably a by-product of just inheriting the CSRG’s original topology and calling it gospel". The situation with the system compiler is definitely improving and some (but not all) of the build overhead is avoided by SYSTEM_CC checks. But since we've established that the end result of a trebled buildworld time (for me 47 minutes with vs 15 minutes without) is still incomplete it seems like a bit of a waste. In any event, the external toolchain support seems to work satisfactorily - allowing me to disconnect the otherwise redundant clang build from buildworld in my branches. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for Compilers on FreeBSD 11
On Wednesday, August 31, 2016, Mark Linimon wrote: > I'll demur just a bit on your points. > > On Mon, Aug 29, 2016 at 08:51:02PM -0700, K. Macy wrote: > > "we need a compiler to build the system" (a prebuilt package does that > > just fine), > > Well, yes, for a tier-1 machine; and one that is connected to the network. > > > I can't speak for the whole universe of users, but I think it's safe > > to say that most users are not power users who individually configure > > ports tailored to their needs. > > We've certainly tried to provide a migration path away from that, but I > don't think anyone has statistics about how far along we are. IMHO we > can't assume it's 100%, or maybe even 80%. > > > I think my experiences on Ubuntu [...] are illustrative. > > A number of years ago Ubuntu and FreeBSD had barely overlapping audiences: > end-users and developers. With all the improvements to pkg and tier-1 > packages I hope that is changing -- the goal of expanding the reach is > why I supported all the changes I saw being made. > > But for me an attraction has always been "you can build it out of the box", > even if I rarely do it (e.g. I am not working in the kernel/driver area), > > mcl > Can clang actually bootstrap from something like lcc? As far as I can tell you need a fairly advanced C++ compiler just to build that compiler in src - which already needs to be installed. It's not exactly bootstrapping from Bourne shell. So I'm not sure "it's self-hosting" is even true, not to mention that you needed a network connection to get src in the first place. Thus the whole argument strikes me as circular if not outright deceptive. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
On Tue, Aug 30, 2016 at 10:39 AM, Eric A. Borisch wrote:
> FWIW, in MacPorts, we patch clang such that it can find the (MacPorts
> provided) libomp headers and library. This lets -fopenmp "just work,"
> and configure scripts can do their job. The libomp headers and lib in
> dedicated sub-directories to minimize the impact of -fopenmp adding
> them to the include and link paths.
>
> It is a fairly minor patch, and shouldn't (tm) have any impact on
> clang executions without an openmp flag:
> https://trac.macports.org/browser/trunk/dports/lang/llvm-3.8/files/openmp-locations.patch
>
> To get a simple OpenMP test script to compile on FreeBSD, I currently
> need to pass (note I'm not the one using -lm):
>
> clang38 -fopenmp -o test test.c -L /usr/local/llvm38/lib -lm
>
> instead of (~ what configure will try)
>
> clang38 -fopenmp -o test test.c
>
> (11.0RC2 w/ llvm38 installed via pkg)
>
> I'd love to see base include llvm's OpenMP support, but failing that,
> the one from ports should be made to work as configure scripts expect.
>
> And who knows, if it is there, maybe some items in base will start to
> use it. We've got a chicken-and-egg problem right now.
Thanks for the patch. Johannes Dieterich hacked the llvm38 port in my
graphics branch and:
mmacy@armageddon [~|18:13|81] clang++ omp.cpp -fopenmp
mmacy@armageddon [~|18:13|81] cat omp.cpp
#include
#include
using namespace std;
int main(int argc, char** argv) {
#pragma omp parallel for default(shared)
for(int i = 0; i < 100; ++i){
#ifdef _OPENMP
cout << "WITH OPENMP " << i << endl;
#else
cout << "WITHOUT OPENMP " << i << endl;
#endif
}
return 0;
}
mmacy@armageddon [~|18:13|82] clang++38 omp.cpp -fopenmp
mmacy@armageddon [~|18:13|83] ./a.out| head -5
WITH OPENMP WITH OPENMP 84WITH OPENMP 92WITH OPENMP
44
WITH OPENMP WITH OPENMP 9352WITH OPENMP
76WITH OPENMP WITH OPENMP 0
WITH OPENMP
Fingers crossed that this can get propagated to master and the
defaults for openblas, FFTW, and others can be made more sensible.
-M
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for Compilers on FreeBSD 11
On Mon, Aug 29, 2016 at 4:46 PM, Erich Dollansky wrote: > Hi, > > Micheal continued: > > http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-OpenMP-Base > > I just wonder if not enabling an option in base because the option is > not required in base would make the documentation of the program > useless except it is documented. The problem here is now that e.b. I > look typically for information of a program at the program's site. I > do not think that they care there what FreeBSD makes out of the > program. > > With other words, it creates confusion. I also don't understand why I need a system compiler and ports compiler when the system compiler is a strict subset of the ports compiler. Spending half of my buildworld time compiling llvm and friends has always been a bit annoying, but now I find that it's not even complete. I'd just as soon install devel/llvm38 from ports and use the external toolchain support (that is if it worked for llvm38). The strongest reason I've heard for bundling a compiler in src is the instability of the C++ ABI (which is completely defeated when you knowingly make the base compiler inadequate for some purposes). The others are "we've always done it that way", "we need a compiler to build the system" (a prebuilt package does that just find), and the best "Solaris didn't include a compiler and look what happened to it" (last I looked the Linux kernel didn't come bundled with gcc and as far as I can tell the Linux community is doing just fine). OpenMP is not a new technology and some widely used ports like fftw and openblas can make use of it ... but don't on FreeBSD because that requires pulling in gcc (and in this case an old one). I can't speak for the whole universe of users, but I think it's safe to say that most users are not power users who individually configure ports tailored to their needs. I think my experiences on Ubuntu, where I'm definitely not a power user, are illustrative. I never compile *anything* that has a package in an ubuntu repo and I assume that the packages are configured when built to enable any performance options that don't potentially cause stability issues. Similarly, on FreeBSD most users are going to be using packages and they're going to assume that the packages are configured to "provide the best user experience". Consequently anyone using a package that could use OpenMP is going to legitimately just assume that "X" is slower on FreeBSD. And for all intents and purposes "X" _is_ slower. Similarly, -fopenmp automatically pulls in libgomp with gcc and -openmp pulls in libiomp with icc. Neither updating the makefile nor creating a wrapper around clang/clang++ to pass the library path is difficult. However, the need to do so is essentially a regression with respect to other platforms and thus can safely be labelled as being "broken". It gratuitously creates yet another small, but real hurdle for users. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
> I'm writing from my cellphone away from my computer, so take this with a > grain of salt: > > -L/usr/local/llvm38/lib You're missing the point. If your webserver crashes every other day, the fact that you can run a batch job to restart it doesn't make it OK. No software written to date assumes the need to find libomp. It will either configure itself to not use openmp or not build without additional tweaking. Requiring additional tweaking to build on FreeBSD or requiring users to install gcc is kind of underwhelming. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
On Sun, Aug 28, 2016 at 2:01 PM, K. Macy wrote: >>> >> >> With 11, one can even simply install devel/openmp which will only install >> the libopenmp bits from llvm, and after that, base cc can do openmp. > > This isn't really useful unless the clang in base knows where to find > libomp. Considering that even the devel/llvm ports aren't configured > properly for that I don't see -fopenmp working. Without patching > makefiles or configure. So although this is better than having to > installing a complete copy of the compiler for the sake of a single > library it's still forcing FreeBSD users to jump through extra hoops > that they don't have to with gcc or on other platforms. I just tried this on Ubuntu and it looks like even there clang doesn't invoke ld correctly to make -fopenmp work. Both icc and gcc do this automatically. Thus I wonder if anyone is actually using openmp in earnest with clang. mmacy@pandemonium:~$ clang++ -fopenmp omp.cpp /usr/bin/ld: cannot find -liomp5 clang-3.5: error: linker command failed with exit code 1 (use -v to see invocation) mmacy@pandemonium:~$ clang++-3.8 -fopenmp omp.cpp /usr/bin/ld: cannot find -lomp clang: error: linker command failed with exit code 1 (use -v to see invocation) mmacy@pandemonium:~$ g++ -fopenmp omp.cpp mmacy@pandemonium:~$ g++-4.9 -fopenmp omp.cpp mmacy@pandemonium:~$ -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
>> > > With 11, one can even simply install devel/openmp which will only install the > libopenmp bits from llvm, and after that, base cc can do openmp. This isn't really useful unless the clang in base knows where to find libomp. Considering that even the devel/llvm ports aren't configured properly for that I don't see -fopenmp working. Without patching makefiles or configure. So although this is better than having to installing a complete copy of the compiler for the sake of a single library it's still forcing FreeBSD users to jump through extra hoops that they don't have to with gcc or on other platforms. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
On Sunday, August 28, 2016, Brandon Allbery wrote: > On Sun, Aug 28, 2016 at 1:57 PM, K. Macy > wrote: > >> Can you point to other platforms where the default system compiler has >> disabled functionality? >> > > You have to install LLVM from elsewhere to get full functionality on OS X: > Apple only ships the parts that Xcode cares about. OTOH, this pretty much > only impacts things that want to use LLVM IR. (On the gripping hand, for > some people that is about as relevant as OpenMP.) > > There were some late SunOS 4 releases where you had (p)cc in the base, > with various tools that people expect missing, and had to install SunSoft C > to get a decent compiler and all the tools. (They removed almost all of it > from Solaris 2, of course.) > > Interesting. The primary OSX user doesn't use a compiler. The SunOS example strikes me as being the closest. And it's because they wanted to sell you extra software. Here it's the notion that there is a compiler for "base" and then ports are "everything else". Ultimately, from the user's perspective "base" will just be a particularly well integrated set of packages - including, rather idiosyncratically, a compiler that only has the features required by that package set. -M > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
On Sunday, August 28, 2016, Dimitry Andric wrote: > On 28 Aug 2016, at 02:10, K. Macy > > wrote: > > > >> The problem here is that Phoronix took a Beta version of FreeBSD 11. > >> Beta versions have a lot of debugging (malloc, invariants, witness) > >> options enabled which make it significantly slower than release > >> versions. This is even obviously when you run a Beta as a desktop. It > >> just feels much slower. > > > > > > I don't know what was going on in these particular tests, but in a > > more recent benchmarking run > > -https://www.phoronix.com/scan.php?page=article&item= > freebsd11-clang-gcc&num=1 > > - you're seeing the result of openmp being disabled in base. The clang > > maintainer for src refuses to include libomp as required for -fopenmp > > because nothing in base requires it. > > Come on, this is nonsense. I have indicated earlier that I would have > liked to import openmp into base, but this was shot down precisely for > that reason: nothing in base uses it. > > So for now, the solution is simply: install one of the llvm ports, and > use it. These have configuration setting to install every optional > component from the LLVM project. It's hardly nonsense. I didn't say that it couldn't be made to work by installing the right ports, with the right options, if you pass the right extra library paths (-fopenmp is sufficient on other platforms). I said that it is not present in base. Thus out of the box performance is what we see. Can you point to other platforms where the default system compiler has disabled functionality? I think the whole concept of "base" may be confusing things. Users don't care about what is base and what isn't. The simple fact is you install a compiler with missing functionality, requiring extra steps by the user that only make sense if you're a committer. -M > > -Dimitry > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmarks results for FreeBSD 11
> The problem here is that Phoronix took a Beta version of FreeBSD 11. > Beta versions have a lot of debugging (malloc, invariants, witness) > options enabled which make it significantly slower than release > versions. This is even obviously when you run a Beta as a desktop. It > just feels much slower. I don't know what was going on in these particular tests, but in a more recent benchmarking run -https://www.phoronix.com/scan.php?page=article&item=freebsd11-clang-gcc&num=1 - you're seeing the result of openmp being disabled in base. The clang maintainer for src refuses to include libomp as required for -fopenmp because nothing in base requires it. I certainly can't speak for the community as a whole - but based on my experience when discussing new features that adversely impact networking performance my impression is that out of the box performance is generally not a priority. -M ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: State of unionfs?
Everything I've been told is that unionfs has essentially never worked right. FreeBSD's VFS semantics and vnode life cycle make it very difficult to implement correctly. -M On Wed, May 18, 2016 at 4:26 PM, Johannes Totz wrote: > On 18/05/2016 10:27, Patrick M. Hausen wrote: >> Hi, all, >> >> we were looking for a way to get overlay/copy-on-write mounts for >> ZFS datasets to ease jail management. >> >> Google turned up this old thread: >> https://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009221.html >> >> So, clearly in September 2010 mount_unionfs(8) was not supported >> for ZFS datasets. >> >> A quick check on a current RELENG-10.3 system showed that this has >> changed .Union-mounting one dataset on top of another does indeed >> work at a superficial glance. >> >> Yet the manpage for mount_unionfs(8) still contains this disturbing >> note: >> >> BUGS >> THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) >> AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN >> RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. >> >> Is this still the case? Are there alternatives to our approach. >> >> What we would like to implement is e.g. a standard pre-populated /etc for >> each >> jail with only modified files being written to a separate per-jail dataset. >> Much like NanoBSD does when populating the /etc mfs at boot. >> >> While we can create a clone from a central snapshot for each jail, the >> problem with this way is that we cannot exchange the base snapshot later, >> e.g. after a major system update for the jail in question. Which is precisely >> the intention in the first place ;-) >> >> Thanks for any hints >> Patrick >> > > I've used unionfs with zfs for a while now. Seems ok. > But beware of nesting any mounts into either lower or upper layer. Files > created in there may not appear in the right place. They used to, but > that broke at some point. > > I'm now moving away from unionfs, and doing a simple zfs clone. When > it's time to upgrade, copy data files separately. Config files are > tracked with Mercurial. > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton wrote: > On 03/03/2012 13:03, K. Macy wrote: >> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote: >>> On 03/03/2012 08:53, K. Macy wrote: >>>> a) We as a members of the community are collectively responsible for >>>> the state of FreeBSD. Simply disabling features or removing >>>> functionality that doesn't work or doesn't work optimally and / or >>>> filing bug reports but not being able or willing to respond to >>>> feedback requests is in essence a form of neglect. Although we all >>>> have day to day obligations for which the use of FreeBSD is extremely >>>> impractical if not impossible ... any progress, any improvements, any >>>> advancements will only happen because *we* made it happen. >>> >>> Since we're reiterating key points, I'll do mine one more time. While I >>> sympathize with what you wrote above, if you continue to believe that >> >> *users* >> >>> have a responsibility to help you debug new features you're going >>> to be disappointed and frustrated. >> >> Users don't, community members do. > > You're drawing a distinction that I don't. > I'm drawing a distinction that you don't make or can't make? Like I said I expect a group of people whose existence as a distinct entity you are unaware of to be helpful. The initial conflict stemmed from confusion on my part that you belong to that group. However, as you've repeatedly made clear you don't, so I was wrong to have been critical of you. I apologize for the confusion. Cheers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote: > On 03/03/2012 08:53, K. Macy wrote: >> a) We as a members of the community are collectively responsible for >> the state of FreeBSD. Simply disabling features or removing >> functionality that doesn't work or doesn't work optimally and / or >> filing bug reports but not being able or willing to respond to >> feedback requests is in essence a form of neglect. Although we all >> have day to day obligations for which the use of FreeBSD is extremely >> impractical if not impossible ... any progress, any improvements, any >> advancements will only happen because *we* made it happen. > > Since we're reiterating key points, I'll do mine one more time. While I > sympathize with what you wrote above, if you continue to believe that *users* > have a responsibility to help you debug new features you're going > to be disappointed and frustrated. Users don't, community members do. So I guess I rest my case for you Doug. You're an end user at the end of the day who thinks he is a member of the community. As you've made apparent on other threads. In your mind Other People(TM) are responsible for FreeBSD's welfare for consuming your dogfood because you know the people who eat it. FreeBSD would still be at the UP stage or worse the 5.x stage if everyone thought the way you do. Individuals who fail to understand the distinction between simple user and community member and are confused by which role they play can only further contribute to the acrimony. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
> Less effort is required to get greater profit without having to mess > around with things because they fit the generic case as opposed to a > number of niche cases or provide OS features that a user may or may > not use. My initial venting of my frustrations at Doug appears to have turned an open-ended discussion of FreeBSD's merits as a desktop vs. a server OS. I don't have the inclination to read every response closely, but I think that it is generating more heat than light. I have three points that I would like to make before I attempt to transition this thread back to its initial purpose: a) We as a members of the community are collectively responsible for the state of FreeBSD. Simply disabling features or removing functionality that doesn't work or doesn't work optimally and / or filing bug reports but not being able or willing to respond to feedback requests is in essence a form of neglect. Although we all have day to day obligations for which the use of FreeBSD is extremely impractical if not impossible ... any progress, any improvements, any advancements will only happen because *we* made it happen. b) There are many features and many changes that are introduced in to FreeBSD which extend the potential user base which are of no obvious benefit to many users. Just because one doesn't need a feature and doesn't hear users crying out for it, doesn't mean that it isn't important. c) My grievance was in no way with Doug Barton or ports per se, but with his response as a representative instance of a behaviour which bothers me, and, taken over time, is detrimental to the whole. Back to the initial subject line: "flowtable usable or not" It is possible to re-structure the routing code to have a smaller cache footprint / shorter lookup time / and eliminate all locking in the packet transmit path (ip_output, ip_forward). However, it would take more time and effort than I have to do so as a recreational activity. The set of people able to fund such an effort is non-intersecting with the set of people who would benefit the most heavily from it. Hence, for the time being, for those who want to be able to approach anywhere near 1Mpps, much less 10 or 15 times that, whilst continuing to use the regular stack (i.e. not running netmap) we are left only with flowtable for bypassing the locking and compute overhead of per-packet route lookups. It is beyond debate that under some, if not many, circumstances flowtable was unusable and perhaps continues to be. Hence, any further reports of "it was broken so I turned it off, and now my life is better" should be left unsent. If you, the reader, are willing to contribute to the testing of changes, provide backtraces from cores etc. please follow up. Thank you for your support. Cheers, Kip -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Request for flowtable testers and actionable feedback RE: flowtable usable or not
I'm re-sending this portion of another mail as it will inevitably not be read by most readers by virtue of having been part of a long and digressive thread. subject line: "flowtable usable or not" It is possible to re-structure the routing code to have a smaller cache footprint / shorter lookup time / and eliminate all locking in the packet transmit path (ip_output, ip_forward). However, it would take more time and effort than I have to do so as a recreational activity. The set of people able to fund such an effort is non-intersecting with the set of people who would benefit the most heavily from it. Hence, for the time being, for those who want to be able to approach anywhere near 1Mpps, much less 10 or 15 times that, whilst continuing to use the regular stack (i.e. not running netmap) we are left only with flowtable for bypassing the locking and compute overhead of per-packet route lookups. It is beyond debate that under some, if not many, circumstances flowtable was unusable and perhaps continues to be. Hence, any further reports of "it was broken so I turned it off, and now my life is better" should be left unsent. If you, the reader, are willing to contribute to the testing of changes, provide backtraces from cores etc. please follow up. Thank you for your support. Cheers, Kip -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
> No, I already pointed out the distinction between "new, experimental > features;" and "essential components of the FreeBSD operating system." > It's Ok for you to disagree with that distinction, or with its > importance. But what you're suggesting is that if users don't help > developers debug "cool new feature X" then we won't have "cool new > feature X." By implication you're saying that if we don't continue to > develop cool new features then at some point down the road we wither and > die. What I have tried ever-so-delicately to avoid saying is that lack > of user help with debugging "cool new feature X" is generally a sign of > lack of user demand for "cool new feature X." Not all cool new ideas are > good ones. :) Considering there are firewall vendors and CDNs making consistent use of it because it dramatically increases the sustainable data rates it is a bit cavalier to say that there is a "lack of demand." It doesn't show up directly as a lack of demand when FreeBSD drastically underperforms linux in a high bandwidth environment. The solution is for the user to simply switch to linux how is a user to know (parodying Star Trek technobabble) "Darn it, if only FreeBSD provided an exponential phase inverter on the warp core in the network stack." All he or she will see is it is slow. Or another very concrete example is iX keeps losing sales because ZFS doesn't perform adequately. ZFS doesn't perform adequately largely because the VM system can't map and can't recycle pages fast enough because of locking limitations. It has nothing to do with the storage stack itself. However, most developers themselves are not familiar with the issues much less users. So if I were to make further locking changes I would initially inevitably break some things. Your response would be that it isn't something users want. You're absolutely right, because current users with higher performance demands DON'T USE FreeBSD. Now you may wish to cut hairs by saying well ... locking we need flowtable we don't. However, the gist of that would be that things that you don't understand, that don't solve anyone's immediate problems "user's don't want." For many prospective server class users the current performance profile is a bigger deterrent than the fact that Cairo took tons of hand-wringing to build and so I spent hours just getting a broken chat client to install and once I did OTR support didn't work. Taken collectively the "cool new feature X"s are every bit as important to FreeBSD as ports. > OTOH, if we don't fix the fundamental problems with ports, and other key > areas of the operating system, we're just not going to have users, > period. Given that most of the developers (like you) have stopped using > FreeBSD on a day-to-day basis, who can blame them? Not necessarily. Most big shops don't really use ports as is. Particularly appliance vendors don't care about how package management is handled. But yes, in principle we could end up with no desktop users. > Doug > > -- > > This .signature sanitized for your protection -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
> > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's no > way to run a railroad. You understand my point but then fail to or choose not to see how it applies to you when it creates problems for you personally. In essence my point was that "It was broken so I turned it off, end of story." does not constitute constructive feedback and does not contribute to the development of FreeBSD. It isn't your responsibility to help me debug my code just as it isn't my responsibility to contribute to the maintenance of ports by dealing with a port management that for me has been virtually unusable in coping with dependencies. I'm not eating the ports dog food because it is broken for me and you're not fully eating the sys dog food because it is broken for you are perfectly reasonable courses of action taken in isolation. However, our respective actions cumulatively don't contribute to the welfare of FreeBSD and my response was simply voicing frustration with such conduct. If you do not see the parallels between the two then there really isn't anything further to discuss about how we engage with the community. -Kip > > > Doug > > -- > > This .signature sanitized for your protection -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
> Apparently you've missed all the times that I've given that exact advice. :) > > But your analogy is severely flawed. Flowtable was an experimental > feature that theoretically might have increased performance for some > work flows, but turned out to be fatally flawed. The ports system is an > essential part of the FreeBSD operating *system*, depended on by > virtually 100% of FreeBSD users. Certainly fatally flawed without any user support. Just as many new features have been. > Users don't have any obligation to help us debug new/experimental features. Correct. However, I'm not sure the analogy is flawed. I am, to some degree, guilty of the same sin. I now run Ubuntu and have never had a single problem keeping my package system up date, in stark contrast to my experiences of slow and nightmarishly error-ridden port updates. I know there are users who have operated without such problems. It is entirely possible that they're simply smarter than I am. I similarly feel no compunction to use a FreeBSD feature (the ports system) that I can't rely on. Cheers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
> Yes, that was part of it. On the web and db systems we had what I can > only describe as "general wackiness" with systems suddenly becoming > unreachable, etc. This was with a moderately complex network setup with > a combination of different VLANs, multiple interfaces, etc. The FreeBSD > routers would just plain panic on a semi-regular interval. Removing > flowtable made all this go away, and we've been quite stable since then. > I understand the switch. Uptime is important in any production network. However, it seems like it may have been too easy to turn it off because no one has made any effort to help me debug the issues. By analogy your guidance for ports usability problems would be to install Ubuntu. Cheers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
Inviato da iPad Il giorno 01/mar/2012, alle ore 03:01, Steve Wills ha scritto: > > The failure I experienced was with web servers running 8.0 behind a F5 > load balancer in an HA setup. Whenever the failover happened, the web > servers would continue sending to the wrong MAC address, despite the > arp table updating. Disabling flowtable via the sysctl solved the > problem. Maybe Doug's failure was similar, maybe not, but I thought > I'd throw my $0.02 in. > Thanks. I just committed a change recently for 8 - HEAD to address that. I would like to know if it solves the problem. > Steve > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (FreeBSD) > > iQEcBAEBAgAGBQJPTtiJAAoJEPXPYrMgexuhp8EIAKGGtZzcxgQ4zVO5SKy1jAOH > DXLRLYfdm8NJB9hYEvtUa9/nltAE35zQMp7FU4AlZ2L2ol/J7W9aODiN0gw9AFEr > dxBYyQliDKvVwLgah9a5PaXNM3kpx9ZvZGM3lBQGQbZaEV+ERwjBXkfIqjEB4Ei5 > bBd7841jQm22s1xJOuJTdMGrpnY1DMUPdPCFOAtyQmTAhWpoELgtQBvP9kGYNKv2 > 3NAPnjFuooe9fdze9VSO8TWFJSb82DVbRsz6JiR0998oHXPApCh4I5y1rNcg2qA/ > 1x2EdFlivXpgjC4nKUgFjhohmdGv20FrLfex4eOq6dSMF0Baje86PJcc8EZ1DK0= > =NUft > -END PGP SIGNATURE- > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
. > > I tried it, on both FreeBSD routers, web systems, and database > servers; all on 8.2+. It still causes massive instability. Disabling > the sysctl, and/or removing it from the kernel solved the problems. Routing I can believe, but I'm wondering how close attention you paid to the workload. There are CDN networks with high uptimes and shipping firewall products that use flowtable, so your mention of web systems forces makes me ask for specifics. Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: h_ertt cc_vegas loader.conf interaction on stable/8
On Tue, Sep 20, 2011 at 6:27 AM, Jason Hellenthal wrote:
>
> On stable/8 as of the date of this message when attempting the following
> configuration the sysctl MIB net.inet.tcp.cc.algorithm is not available
> for /etc/sysctl.conf to tune for whatever reason.
What (I think) you're in essence asking is for the kernel to
dynamically load cc algorithms when you set the sysctl for the default
to one that has not yet been loaded. Below is the sysctl handler,
you'll see that it only lets you set it to an algorithm that has
already been loaded. Yes it would be possible to dynamically load the
way system does with ifconfig, but I don't know how many people would
feel that it was the effort of adding the code to iterate through all
the modules in a path looking for one that provided the name that had
been set.
Cheers
/*
* Sysctl handler to show and change the default CC algorithm.
*/
static int
cc_default_algo(SYSCTL_HANDLER_ARGS)
{
char default_cc[TCP_CA_NAME_MAX];
struct cc_algo *funcs;
int err, found;
err = found = 0;
if (req->newptr == NULL) {
/* Just print the current default. */
CC_LIST_RLOCK();
strlcpy(default_cc, CC_DEFAULT()->name, TCP_CA_NAME_MAX);
CC_LIST_RUNLOCK();
err = sysctl_handle_string(oidp, default_cc, 1, req);
} else {
/* Find algo with specified name and set it to default. */
CC_LIST_RLOCK();
STAILQ_FOREACH(funcs, &cc_list, entries) {
if (strncmp((char *)req->newptr, funcs->name,
TCP_CA_NAME_MAX) == 0) {
found = 1;
V_default_cc_ptr = funcs;
}
}
CC_LIST_RUNLOCK();
if (!found)
err = ESRCH;
}
return (err);
}
> /boot/loader.conf:
> h_ertt_load="YES"
> cc_vegas_load="YES"
>
> /etc/sysctl.conf:
> net.inet.tcp.cc.algorithm=vegas
>
>
> After boot the system still has the congestion algo set to 'newreno'
>
> To get around this I had to load the above two modules at rc.local stage
> of the boot and also tune the sysctl via this method.
>
>
> Has anyone else seen this behavior with other congestion algo's ?
>
> Can any developer advise what is controlling this ?
>
>
> Thanks in advance.
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_8 does not build with CPUTYPE=core2
The system compiler probably pre-dates cpu specific support. Try installing a newer one from ports. On Sat, May 14, 2011 at 12:14 AM, Dominic Fandrey wrote: > env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe > -march=core2 -DHAVE_CONFIG_H > -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c > make-roken.c > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: > error: bad value (core2) for -march= switch > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: > error: bad value (core2) for -mtune= switch > make-roken.c:1: error: bad value (core2) for -march= switch > make-roken.c:1: error: bad value (core2) for -mtune= switch > distcc[44991] ERROR: compile make-roken.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > distcc[44988] ERROR: compile > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c > on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > # make -VCPUTYPE > nocona > # make -VCFLAGS > -O2 -pipe -march=nocona > > CPUTYPE is set with CPUTYPE?=core2. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
On Thu, Apr 14, 2011 at 10:18 PM, Jack Vogel wrote:
> So, what do you have in mind as the real problem then?
The problem was the one that you provided the solution to. I was
simply observing that auto-tuning of mbuf jumbo cluster limits is in
need of improvement.
Kip
>
> Jack
>
>
> On Thu, Apr 14, 2011 at 11:55 AM, K. Macy wrote:
>
>> That isn't guaranteed to work if he is KVA limited.
>>
>> On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel wrote:
>> > If you get this message its only for one reason, you don't have enough
>> mbufs
>> > to
>> > fill your rings. You must do one of two things, either reduce the number
>> of
>> > queues,
>> > or increase the relevant mbuf pool.
>> >
>> > Increase the 9K mbuf cluster pool.
>> >
>> > Jack
>> >
>> >
>> > On Thu, Apr 14, 2011 at 6:05 AM, Leon Meßner
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> i tried setting the mtu on one of my ixgbe(4) intel NICs to support
>> >> jumbo frames. This is on a box with RELENG_8 from today.
>> >>
>> >> # ifconfig ix0 mtu 9198
>> >>
>> >> I then get the following error:
>> >>
>> >> # tail -n 1 /var/log/messages
>> >> Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>> >>
>> >> I already tried the following patch because of Jack Vogel's advice given
>> >> in the following thread on -stable in Oct. last year, which still
>> >> produces the same error message and leaves the box unpingable:
>> >>
>> >>
>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>> >>
>> >> # cat ~/patches/ixgbe.num_queues_to_4.patch
>> >> --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
>> >> +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
>> >> @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
>> >> * number of cpus. Each queue is a pair
>> >> * of RX and TX rings with a msix vector
>> >> */
>> >> -static int ixgbe_num_queues = 0;
>> >> +static int ixgbe_num_queues = 4;
>> >> TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>> >>
>> >> /*
>> >>
>> >> ___
>> >> freebsd-stable@freebsd.org mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> >> To unsubscribe, send any mail to "
>> freebsd-stable-unsubscr...@freebsd.org"
>> >>
>> > ___
>> > freebsd-stable@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
>> "
>> >
>>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
On Thu, Apr 14, 2011 at 9:44 PM, Leon Meßner
wrote:
> On Thu, Apr 14, 2011 at 08:55:17PM +0200, K. Macy wrote:
>> That isn't guaranteed to work if he is KVA limited.
>>
>> On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel wrote:
>> > If you get this message its only for one reason, you don't have enough
>> > mbufs
>> > to
>> > fill your rings. You must do one of two things, either reduce the number of
>> > queues,
>> > or increase the relevant mbuf pool.
>> >
>> > Increase the 9K mbuf cluster pool.
>
> I did set it to twice the default, and now it works and netstat -m
> shows:
>
> 8192/391/8583/12800 9k jumbo clusters in use (current/cache/total/max)
>
> Whats a reasonable amount to set kern.ipc.nmbjumbo9 to and is there
> any
> form of auto-tuning (i have absolutely no load on this machine and
> mbufs
> are higher than default pool size).
The auto-tuning for jumbo clusters works poorly at best. It isn't load
consuming them, it is the preallocation to large receive queues.
>
> Thanks to all,
> Leon
>
>> > On Thu, Apr 14, 2011 at 6:05 AM, Leon Meßner
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> i tried setting the mtu on one of my ixgbe(4) intel NICs to support
>> >> jumbo frames. This is on a box with RELENG_8 from today.
>> >>
>> >> # ifconfig ix0 mtu 9198
>> >>
>> >> I then get the following error:
>> >>
>> >> # tail -n 1 /var/log/messages
>> >> Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>> >>
>> >> I already tried the following patch because of Jack Vogel's advice given
>> >> in the following thread on -stable in Oct. last year, which still
>> >> produces the same error message and leaves the box unpingable:
>> >>
>> >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>> >>
>> >> # cat ~/patches/ixgbe.num_queues_to_4.patch
>> >> --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
>> >> +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
>> >> @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
>> >> * number of cpus. Each queue is a pair
>> >> * of RX and TX rings with a msix vector
>> >> */
>> >> -static int ixgbe_num_queues = 0;
>> >> +static int ixgbe_num_queues = 4;
>> >> TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>> >>
>> >> /*
>> >>
>> >> ___
>> >> freebsd-stable@freebsd.org mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>> >>
>> > ___
>> > freebsd-stable@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>> >
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
That isn't guaranteed to work if he is KVA limited.
On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel wrote:
> If you get this message its only for one reason, you don't have enough mbufs
> to
> fill your rings. You must do one of two things, either reduce the number of
> queues,
> or increase the relevant mbuf pool.
>
> Increase the 9K mbuf cluster pool.
>
> Jack
>
>
> On Thu, Apr 14, 2011 at 6:05 AM, Leon Meßner
> wrote:
>
>> Hi,
>>
>> i tried setting the mtu on one of my ixgbe(4) intel NICs to support
>> jumbo frames. This is on a box with RELENG_8 from today.
>>
>> # ifconfig ix0 mtu 9198
>>
>> I then get the following error:
>>
>> # tail -n 1 /var/log/messages
>> Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>>
>> I already tried the following patch because of Jack Vogel's advice given
>> in the following thread on -stable in Oct. last year, which still
>> produces the same error message and leaves the box unpingable:
>>
>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>>
>> # cat ~/patches/ixgbe.num_queues_to_4.patch
>> --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
>> +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
>> @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
>> * number of cpus. Each queue is a pair
>> * of RX and TX rings with a msix vector
>> */
>> -static int ixgbe_num_queues = 0;
>> +static int ixgbe_num_queues = 4;
>> TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>>
>> /*
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
Also, how much memory do you have and what architecture?
On Thu, Apr 14, 2011 at 4:14 PM, Nikolay Denev wrote:
> On Apr 14, 2011, at 2:05 PM, Leon Meßner wrote:
>
>> Hi,
>>
>> i tried setting the mtu on one of my ixgbe(4) intel NICs to support
>> jumbo frames. This is on a box with RELENG_8 from today.
>>
>> # ifconfig ix0 mtu 9198
>>
>> I then get the following error:
>>
>> # tail -n 1 /var/log/messages
>> Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>>
>> I already tried the following patch because of Jack Vogel's advice given
>> in the following thread on -stable in Oct. last year, which still
>> produces the same error message and leaves the box unpingable:
>>
>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>>
>> # cat ~/patches/ixgbe.num_queues_to_4.patch
>> --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
>> +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
>> @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
>> * number of cpus. Each queue is a pair
>> * of RX and TX rings with a msix vector
>> */
>> -static int ixgbe_num_queues = 0;
>> +static int ixgbe_num_queues = 4;
>> TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>>
>> /*
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
> Hi,
>
> Have you tried increasing the following sysctls ? :
>
> kern.ipc.nmbjumbo16
> kern.ipc.nmbjumbo9
> kern.ipc.nmbclusters
>
> Regards,
> Nikolay
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
That should be plenty, but how large are your receive queues?
\Kip
On Thu, Apr 14, 2011 at 4:18 PM, Leon Meßner
wrote:
> On Thu, Apr 14, 2011 at 03:44:23PM +0200, K. Macy wrote:
>> How many 9k jumbo clusters are available?
>
> Does this output suffice as information ?
>
> # netstat -m
> 8194/1031/9225 mbufs in use (current/cache/total)
> 8192/518/8710/25600 mbuf clusters in use (current/cache/total/max)
> 8192/512 mbuf+clusters out of packet secondary zone in use
> (current/cache)
> 0/5/5/12800 4k (page size) jumbo clusters in use
> (current/cache/total/max)
> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
> 18432K/1313K/19746K bytes allocated to network (current/cache/total)
> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> 0/0/0 sfbufs in use (current/peak/max)
> 0 requests for sfbufs denied
> 0 requests for sfbufs delayed
> 0 requests for I/O initiated by sendfile
> 0 calls to protocol drain routines
>
>> On Thu, Apr 14, 2011 at 3:05 PM, Leon Meßner
>> wrote:
>> > Hi,
>> >
>> > i tried setting the mtu on one of my ixgbe(4) intel NICs to support
>> > jumbo frames. This is on a box with RELENG_8 from today.
>> >
>> > # ifconfig ix0 mtu 9198
>> >
>> > I then get the following error:
>> >
>> > # tail -n 1 /var/log/messages
>> > Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>> >
>> > I already tried the following patch because of Jack Vogel's advice given
>> > in the following thread on -stable in Oct. last year, which still
>> > produces the same error message and leaves the box unpingable:
>> >
>> > http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>> >
>> > # cat ~/patches/ixgbe.num_queues_to_4.patch
>> > --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
>> > +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
>> > @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
>> > * number of cpus. Each queue is a pair
>> > * of RX and TX rings with a msix vector
>> > */
>> > -static int ixgbe_num_queues = 0;
>> > +static int ixgbe_num_queues = 4;
>> > TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>> >
>> > /*
>> >
>> > ___
>> > freebsd-stable@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>> >
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ixgbe(4) and "Could not setup receive structures"
How many 9k jumbo clusters are available?
On Thu, Apr 14, 2011 at 3:05 PM, Leon Meßner
wrote:
> Hi,
>
> i tried setting the mtu on one of my ixgbe(4) intel NICs to support
> jumbo frames. This is on a box with RELENG_8 from today.
>
> # ifconfig ix0 mtu 9198
>
> I then get the following error:
>
> # tail -n 1 /var/log/messages
> Apr 14 12:48:43 siloneu kernel: ix0: Could not setup receive structures
>
> I already tried the following patch because of Jack Vogel's advice given
> in the following thread on -stable in Oct. last year, which still
> produces the same error message and leaves the box unpingable:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html
>
> # cat ~/patches/ixgbe.num_queues_to_4.patch
> --- /root/.vimbackup/ixgbe.c~ 2011-04-12 22:14:27.0 +
> +++ sys/dev/ixgbe/ixgbe.c 2011-04-12 22:14:27.0 +
> @@ -273,7 +273,7 @@ TUNABLE_INT("hw.ixgbe.hdr_split", &ixgbe
> * number of cpus. Each queue is a pair
> * of RX and TX rings with a msix vector
> */
> -static int ixgbe_num_queues = 0;
> +static int ixgbe_num_queues = 4;
> TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues);
>
> /*
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS on top of GELI
> Ok, lets assume we have a dedicated ZIL on a single non-redundant > disk. This disk dies. How do you remove the dedicated ZIL from the > pool or replace it with a new one? Solaris ZFS documentation indicates > that this is possible for dedicated L2ARC - you can remove a dedicated > l2arc from a pool at any time you wish and should some IO fail on the > l2arc, the system will gracefully continue to run, reverting said IO > to be processed by the actual default built-in ZIL on the disks of the > pool. However the capability to remove dedicated ZIL or gracefully > handle the death of a non-redundant dedicated ZIL vdev does not > currently exist in Solaris/OpenSolaris at all. Ahh - you're describing an implementation flaw as opposed to a design flaw. Your initial statement could be interpreted as meaning that the ZIL is required for file system consistency. I hope they fix that. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS on top of GELI
>> >> If performance is an issue, you may want to consider carving off a partition >> on that SSD, geli-fying it, and using it as a ZIL device. You'll probably >> see a marked performance improvement with such a setup. > > That is true, but using a single device for a dedicated ZIL is a huge > no-no, considering it's an intent log, it's used to reconstruct the > pool in case of a power failure for example, should such an event > occur at the same time as a ZIL provider dies, you lose the entire > pool because there is no way to recover it, so if ZIL gets put > "elsewhere", that elsewhere really should be a mirror and sadly I > don't see myself affording to use 2 SSDs for my setup :) > This is false. The ZIL is used for journalling synchronous writes. If your ZIL is lost you will lose the data that was written to the ZIL, but not yet written to the file system proper. Barring disk corruption, the file system is always consistent. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Quggaa locking hard.
What is the simplest way to reproduce this? Although flowtable is not expected
to help your use case, it should not cripple it.
-Kip
On Dec 4, 2009, at 6:56 AM, Mike Tancsa wrote:
> At 10:46 PM 12/3/2009, Zaphod Beeblebrox wrote:
>> I'm still investigating this, but my quagga is locking hard on FreeBSD 8.0
>> and not locking hard on 7.2. It seems (at this early point in the
>> investigation) that both bgpd and zebra are wedging and zebra is listed as
>> being in the "RUN" state.
>>
>> curiously, the load is also 4.0 (exactly the number of cores in the machine)
>> even though the machine also reads 100% idle.
>
>
> I think I am seeing something similar on a test box. I was loading up the
> box with 200k routes to do testing with. Kernel is default, save for a few
> unused drivers removed. If I take out
> optionsFLOWTABLE # per-cpu routing cache
> from the kernel, load avg is back to normal. This issue only seems to have
> come up in the past week or so as the previous kernel from ~8 days ago was OK.
>
> last pid: 6229; load averages: 2.00, 2.00, 2.00up
> 1+17:33:02 09:39:31
> 141 processes: 7 running, 106 sleeping, 28 waiting
> CPU: 0.0% user, 0.0% nice, 22.2% system, 0.0% interrupt, 77.8% idle
> Mem: 98M Active, 2233M Inact, 187M Wired, 36K Cache, 112M Buf, 979M Free
> Swap: 8192M Total, 8192M Free
>
> PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
> 22 root 76- 0K 8K CPU33 41.5H 100.00% flowcleaner
> 11 root 171 ki31 0K32K CPU22 41.5H 100.00% {idle: cpu2}
> 11 root 171 ki31 0K32K CPU11 41.5H 100.00% {idle: cpu1}
> 11 root 171 ki31 0K32K RUN 0 41.4H 100.00% {idle: cpu0}
> 869 root 40 64860K 64488K select 0 4:12 0.00% bgpd
> 11 root 171 ki31 0K32K RUN 3 2:09 0.00% {idle: cpu3}
> 20 root 44- 0K 8K syncer 0 1:00 0.00% syncer
> 12 root -32- 0K 224K WAIT1 0:47 0.00% {swi4: clock}
>0 root -680 0K80K - 2 0:03 0.00% {fw0_taskq}
> 1230 root 760 3348K 1160K ttyin 2 0:02 0.00% getty
> 863 root 960 24640K 24232K RUN 2 0:02 0.00% zebra
> 12 root -32- 0K 224K WAIT2 0:01 0.00% {swi4: clock}
> 14 root -16- 0K 8K - 0 0:01 0.00% yarrow
>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
>
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications,m...@sentex.net
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Quggaa locking hard.
If you have a large number of routes then you will want to disable the
flowtable. The default maximum number of cacheable flows is fairly
small, raising it can help on the low-end, but fundamentally its an
optimization for systems that have fewer than a few thousand
simultaneous peers - the common case.
I do have longer term plans for moving to lock-free L3 and L2 so that
applications with large numbers of prefixes will also no longer be
hampered by high locking overhead.
-Kip
On Fri, Dec 4, 2009 at 6:56 AM, Mike Tancsa wrote:
> At 10:46 PM 12/3/2009, Zaphod Beeblebrox wrote:
>>
>> I'm still investigating this, but my quagga is locking hard on FreeBSD 8.0
>> and not locking hard on 7.2. It seems (at this early point in the
>> investigation) that both bgpd and zebra are wedging and zebra is listed as
>> being in the "RUN" state.
>>
>> curiously, the load is also 4.0 (exactly the number of cores in the
>> machine)
>> even though the machine also reads 100% idle.
>
>
> I think I am seeing something similar on a test box. I was loading up the
> box with 200k routes to do testing with. Kernel is default, save for a few
> unused drivers removed. If I take out
> options FLOWTABLE # per-cpu routing cache
> from the kernel, load avg is back to normal. This issue only seems to have
> come up in the past week or so as the previous kernel from ~8 days ago was
> OK.
>
> last pid: 6229; load averages: 2.00, 2.00, 2.00 up
> 1+17:33:02 09:39:31
> 141 processes: 7 running, 106 sleeping, 28 waiting
> CPU: 0.0% user, 0.0% nice, 22.2% system, 0.0% interrupt, 77.8% idle
> Mem: 98M Active, 2233M Inact, 187M Wired, 36K Cache, 112M Buf, 979M Free
> Swap: 8192M Total, 8192M Free
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 22 root 76 - 0K 8K CPU3 3 41.5H 100.00% flowcleaner
> 11 root 171 ki31 0K 32K CPU2 2 41.5H 100.00% {idle: cpu2}
> 11 root 171 ki31 0K 32K CPU1 1 41.5H 100.00% {idle: cpu1}
> 11 root 171 ki31 0K 32K RUN 0 41.4H 100.00% {idle: cpu0}
> 869 root 4 0 64860K 64488K select 0 4:12 0.00% bgpd
> 11 root 171 ki31 0K 32K RUN 3 2:09 0.00% {idle: cpu3}
> 20 root 44 - 0K 8K syncer 0 1:00 0.00% syncer
> 12 root -32 - 0K 224K WAIT 1 0:47 0.00% {swi4: clock}
> 0 root -68 0 0K 80K - 2 0:03 0.00% {fw0_taskq}
> 1230 root 76 0 3348K 1160K ttyin 2 0:02 0.00% getty
> 863 root 96 0 24640K 24232K RUN 2 0:02 0.00% zebra
> 12 root -32 - 0K 224K WAIT 2 0:01 0.00% {swi4: clock}
> 14 root -16 - 0K 8K - 0 0:01 0.00% yarrow
>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
>
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, m...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Not to mention that SIGVTALRM is already used by
the thread library (although I would hope that
_thread_sys_sigaction is smart enough to handle
that case). I've stepped through the GDB
code on both 4.18 and 5.1. On 5.1 I found the
following in i386fbsd-nat.c:
void
child_resume (ptid_t ptid, int step, enum
target_signal signal)
{
pid_t pid = ptid_get_pid (ptid);
int request = PT_STEP;
if (pid == -1)
/* Resume all threads. This only gets used in the
non-threaded
case, where "resume all threads" and "resume
inferior_ptid" are
the same. */
pid = ptid_get_pid (inferior_ptid);
if (!step)
{
unsigned int eflags;
/* Workaround for a bug in FreeBSD. Make sure
that the trace
flag is off when doing a continue. There is
a code path
through the kernel which leaves the flag set
when it should
have been cleared. If a process has a signal
pending (such
as SIGALRM) and we do a PT_STEP, the process
never really has
a chance to run because the kernel needs to
notify the
debugger that a signal is being sent.
Therefore, the process
never goes through the kernel's trap()
function which would
normally clear it. */
eflags = read_register (PS_REGNUM);
if (eflags & 0x0100)
write_register (PS_REGNUM, eflags & ~0x0100);
request = PT_CONTINUE;
}
It is pretty clear that:
a) this does not deal with the case of step or next
b) this does not work in the case of continue often
times because step will be set to 1
and hence, this code does _not_ work around the bug.
This appears to be less of a GDB bug and more of a
kernel bug in ptrace.
-Kip
--- Donald Gillies <[EMAIL PROTECTED]> wrote:
> I think this bug may be associated only with the
> SIGALRM signal. When I
> convert my code to use SIGVTALRM, the problem goes
> away. Unfortunately,
> SIGVTALRM does not do exactly
> what I am looking for !!
>
> # gdb 5.10
> # $FreeBSD: src/COPYRIGHT,v 1.4 1999/09/05 21:33:47
> obrien Exp $
> # @(#)COPYRIGHT 8.2 (Berkeley) 3/21/94
>
>
>
__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
