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 >

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

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 <s...@zxy.spb.ru> wrote: > On Thu, Dec 08, 2016 at 04:52:35PM +, K. Macy wrote: > > > > > kgdb7111 is what you use for kern

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 <s...@zxy.spb.ru> 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

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: >

Re: Benchmarks results for Compilers on FreeBSD 11

On Wed, Aug 31, 2016 at 3:55 PM, Erich Dollansky <erichsfreebsdl...@alogt.com> wrote: > Hi, > > On Wed, 31 Aug 2016 12:16:16 -0700 > "K. Macy" <km...@freebsd.org> wrote: > >> On Wednesday, August 31, 2016, Mark Linimon <lini...@lonesome.com> >

Re: Benchmarks results for Compilers on FreeBSD 11

On Wednesday, August 31, 2016, Mark Linimon <lini...@lonesome.com> 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 > > ju

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 >

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=FreeBSD-OpenMP-Base > > I just wonder if not enabling an option in base because the option is > not required in base would make the

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

Re: Benchmarks results for FreeBSD 11

On Sun, Aug 28, 2016 at 2:01 PM, K. Macy <km...@freebsd.org> 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 unles

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

Re: Benchmarks results for FreeBSD 11

On Sunday, August 28, 2016, Brandon Allbery <allber...@gmail.com> wrote: > On Sun, Aug 28, 2016 at 1:57 PM, K. Macy <km...@freebsd.org > <javascript:_e(%7B%7D,'cvml','km...@freebsd.org');>> wrote: > >> Can you point to other platforms where the defaul

Re: Benchmarks results for FreeBSD 11

On Sunday, August 28, 2016, Dimitry Andric <d...@freebsd.org> wrote: > On 28 Aug 2016, at 02:10, K. Macy <km...@freebsd.org <javascript:;>> > wrote: > > > >> The problem here is that Phoronix took a Beta version of FreeBSD 11. > >> Beta vers

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

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: >>

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

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

Re: flowtable usable or not

On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org 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

Re: flowtable usable or not

On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton do...@freebsd.org wrote: On 03/03/2012 13:03, K. Macy wrote: On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton do...@freebsd.org wrote: On 03/03/2012 08:53, K. Macy wrote: a) We as a members of the community are collectively responsible for the state

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

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

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

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

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.

Re: flowtable usable or not

Inviato da iPad Il giorno 01/mar/2012, alle ore 03:01, Steve Wills swi...@freebsd.org 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

Re: h_ertt cc_vegas loader.conf interaction on stable/8

On Tue, Sep 20, 2011 at 6:27 AM, Jason Hellenthal jh...@dataix.net 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

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 kamik...@bsdforen.de wrote: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H

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 l.mess...@physik.tu-berlin.de 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

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 l.mess...@physik.tu-berlin.de 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

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 nde...@gmail.com 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

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 jfvo...@gmail.com 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

Re: ixgbe(4) and Could not setup receive structures

On Thu, Apr 14, 2011 at 9:44 PM, Leon Meßner l.mess...@physik.tu-berlin.de 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 jfvo...@gmail.com wrote: If you get this message its only

Re: ixgbe(4) and Could not setup receive structures

On Thu, Apr 14, 2011 at 11:55 AM, K. Macy km...@freebsd.org wrote: That isn't guaranteed to work if he is KVA limited. On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel jfvo...@gmail.com wrote: If you get this message its only for one reason, you don't have enough mbufs to fill your rings. You

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,

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

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

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

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