Re: [PATCH] Recent libm additions

> > Well, actually, the functions in polevll.c should have been copied > into ld80/e_powl.c, and polevall.c should never have been committed. > Unfortunately, the code was not reviewed for correctness. That is not correct. Please stop repeating it. Bruce Evans and John Baldwin were both looped

Re: rust broken?

On Thu, Jun 7, 2018 at 11:26 PM, Greg wrote: > On 06/07, Matthew Macy wrote: >> >> On Thu, Jun 7, 2018 at 10:33 Michael Butler >> wrote: >> >>> Ah - I'll re-enable that to see if it makes a difference .. >>> >> >> >> It's not a question of enabling. It doesn't explicitly use the 11 symbols. >>

Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

> > I wrote up a couple more paragraphs about why I think it happens and > what we'd need to do to import more of that sense over into src. But > it was way longer than it needs to be. We get a lot more man-hours in > ports/ acting as conduits for the "outside patches -> svn" pipeline > because

Re: ifa_ifwithnet failed ???

please update to r334253 On Sat, May 26, 2018 at 11:36 PM, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sun, 27 May 2018 03:17:07 + > "Pieper, Jeffrey E" schrieb: > >> I'm seeing this spam dmesg

Re: ifa_ifwithnet failed ???

wrote: > > > From: kmacy...@gmail.com [kmacy...@gmail.com] on behalf of K. Macy > [km...@freebsd.org] > Sent: Saturday, May 26, 2018 8:20 PM > To: Pieper, Jeffrey E > Cc: freebsd-current ‎[freebsd-current@freebsd.org]‎ > Subject: Re: ifa_ifwithnet failed ??? > > On

Re: ifa_ifwithnet failed ???

On Sat, May 26, 2018 at 8:17 PM, Pieper, Jeffrey E wrote: > I'm seeing this spam dmesg continuously on a build from this afternoon > (r334252): > > May 27 03:06:03 u0855 kernel: ifa_ifwithnet failed > May 27 03:06:03 u0855 syslogd: last message repeated 11 times > May

Re: SVN - r334189 breaks build

Fix going in in about 10 On Thu, May 24, 2018 at 3:45 PM, Michael Butler wrote: > On a GENERIC box .. > > --- bridgestp.o --- > /usr/src/sys/net/bridgestp.c:2046:2: error: no member named 'cstqe_next' > in 'struct ifnet::(anonymous at

Re: [RFC] Deprecation and removal of the drm2 driver

Why are you running i386 on that? On Tue, May 22, 2018 at 4:26 PM, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote: >> > >> > >> > it makes me giggle that people still think non-amd64 is "

Re: [RFC] Deprecation and removal of the drm2 driver

> I am concerned about just shoving it out to ports, as that makes > it rot even faster. > > I am still very concerned that our in base i9xx code is like 4 > years old and everyone is told to go to kmod-next from ports > as well. > > No, I do not have a solution, but I have not tried hard to find

Re: [RFC] Deprecation and removal of the drm2 driver

> > > it makes me giggle that people still think non-amd64 is "legacy". > > i386 is alive and well - new chips are being fabbed based on the 586 > design with pci-e slots; not to mention things like the Talos and > AmigaOne for PowerPC. DRM2 doesn't support anything later than mid-Haswell. The

Re: [RFC] Deprecation and removal of the drm2 driver

> > I just ask. > Or why not include drm-next to base svn repo and add some > option to make.conf to swith drm2/dem-next ? Even if it's not being built on amd64 we're still responsible for keeping it building on !amd64 so long as it's in base. This makes changing APIs and universe runs more

Re: [RFC] Deprecation and removal of the drm2 driver

On Mon, May 21, 2018 at 10:07 AM, Steve Kargl wrote: > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: >> On Sun, 20 May 2018 21:10:28 +0200 >> Oliver Pinter wrote: >> >> > > One of the reasons for the deprecation and

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

Chalk another review fail up to shuffling patches between git and phab. Sorry for the inconvenience. -M On Wed, Apr 11, 2018 at 10:26 AM, K. Macy <km...@freebsd.org> wrote: > Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line. > -M > > On Wed, Apr 11, 2018 at

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line. -M On Wed, Apr 11, 2018 at 10:24 AM, K. Macy <km...@freebsd.org> wrote: > Sorry about that. It looks like my review must have been missing a line. > > @@ -4702,8 +4707,8 @@ iflib_regist

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

Sorry about that. It looks like my review must have been missing a line. @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx) _iflib_assert(sctx); - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); - + CTX_LOCK_INIT(ctx); + STATE_LOCK_INIT(ctx,

Re: Is there possible run a MacOS X binary

> > > A MachO activator is indeed not useful without an OSX install. But let's be honest, Mach IPC is a loadable kernel module requiring no real kernel changes. It's not upstreamable because of a general poor understanding of IPC by noisy commentators and a religious aversion to a technology

Re: Lenovo X1 Carbon or T460s

On Monday, November 14, 2016, Lars Engels <lars.eng...@0x20.net> wrote: > On Sun, Nov 13, 2016 at 01:56:45PM -0800, K. Macy wrote: > > On Saturday, November 12, 2016, Mark Heily <m...@heily.com > <javascript:;>> wrote: > > > > > On Fri, Nov 11, 2016 at

Re: Lenovo X1 Carbon or T460s

On Saturday, November 12, 2016, Mark Heily wrote: > On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman > wrote: > > > > > In regard to video, have you installed and are you using vaapi? > > > > vaapi appears to be preinstalled, however when I run

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

On Monday, August 29, 2016, Volodymyr Kostyrko wrote: > Matthew Macy wrote: > >> It looks like there is something broken with the devel/llvm38 port or >> external toolchain support has regressed: >> >> >> This works: >> make XCC=/usr/local/bin/clang37

Re: Hardware rendered Wayland client up and running

On Saturday, August 13, 2016, Adrian Chadd wrote: > w! > > ok, what has to be committed to -head? O.o For the range of hardware supported by 3.8 just evdev and his drm kevent patch. For anything newer (e.g. Cherryview) everything in my patch queue that we've been

lengthy sdhci timeouts on KBL-Y tester

I have a KBL-Y "Software Development Platform" for purposes of getting the i915 KMS working on that system on FreeBSD. I've just installed 11 BETA4. sdhci timeouts add several minutes to boot time. The dmesg output follows: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980,

Re: iwm load panic

On Thursday, August 4, 2016, Christian Schwarz wrote: > Any idea which revision/commit introduced this regression? > > (I want to test iwm + freebsd-base-graphics on my laptop tonight and > hence avoid crashers like this one in advance.) > > @mmacy: is the revision in the

Re: iwm load panic

wrote: > On 08/04/16 09:56, K. Macy wrote: >> >> #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at > > > Hi, > > Looks like a NULL pointer, queue=NULL > > --HPS ___ freebsd-current@freebsd.org mailing list

iwm load panic

I get this panic periodically at iwm load time: (kgdb) p ic->ic_tq value has been optimized out (kgdb) down #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554 554 TQ_LOCK(queue); (kgdb) bt #0 __curthread () at

Re: [PATCH] randomized delay in locking primitives, take 2

On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? The adaptive spinning path will never run on a uniprocessor. Except for potential

Re: ACPI errors when booting laptop

Have you checked for BIOS updates? The BIOS on recent Skylake laptops have been a running disaster. At least the Dell XPS laptops had ACPI errors be fixed by an update. -M On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods wrote: > Hi everyone, > > I get the following ACPI errors

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

On Wednesday, July 6, 2016, Don Lewis wrote: > On 6 Jul, Matthew Macy wrote: > > As a first step towards managing linux user space in a chrooted > > /compat/linux, initially for i915 testing with intel gpu tools, later > > on to get widevine and steam to work I'm trying to

Re: panic with tcp timers

On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy wrote: > You guys should really look at Samy Bahra's epoch based reclamation. I solved > a similar problem in drm/linuxkpi using it. The point being that this is a bug in the TCP life cycle handling _not_ in callouts. Churning

Latest freebsd installer memstick image fails to mountroot by default on Thinkpad e565

Just to clarify I'm talking about BSD install images, not my i915 tester. On Friday, June 3, 2016, Matthew Macy wrote: > > In order to boot USB reliably on recent laptop hardware (both my thinkpad > and XPS13 need this) you need to add the following to the installer images >

Re: repeatable panic on pageout with 945GM

It looks like it might be trying to remove mappings for a page that doesn't have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem release mmap. Compile the kernel and driver with -O0 and look at the page. It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.

Re: dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

It will be fixed in the next iflib update. On Thursday, May 26, 2016, Juan Ramón Molina Menor wrote: > Hi! > > In three different machines running HEAD I have this message in the very > first lines of the dmesg output: > > can't reuse a leaf (ixl_rx_miss_bufs)! > > I don’t

Re: pkg chroot issues?

On Sunday, May 22, 2016, Tim Kientzle wrote: > Crochet has some experimental hooks to install packages onto the system > being built, but this seems to be hitting problems due to limitations in > 'pkg -c'. In particular, it seems that pkg performs the chroot before it > does

Re: em(4) broken in HEAD?

Much to my chagrin, this too is my fault. Please apply the attached patch if it hasn't yet been committed to -CURRENT. On Fri, May 20, 2016 at 11:28 PM, Joel Dahl <j...@vnode.se> wrote: > On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote: >> I'm seeing watchdog resets on em(

Re: em(4) broken in HEAD?

I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two. > > > I don't use ipfw, aliases or anything other than stock networking. I > was unable to copy a large image off the VM without getting an > unending stream of watchdog resets which could only be fixed by a > reboot.

Re: em(4) broken in HEAD?

On Fri, May 20, 2016 at 11:33 AM, Johan Hendriks wrote: > H > > Op vrijdag 20 mei 2016 heeft Joel Dahl het volgende > geschreven: > >> On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote: >> > On Fri, 20 May 2016 13:55:50 +0200 >> > Joel Dahl

boot broken on VMWare somewhere between r300069 and r300176

I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just did an IFC to r300176 and boot will hang right ater printing out "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the shell as hanging in piperead. Diffing between those two revisions I don't see any obvious offenders

Re: i915kms broken at some commit between r296485 and r297692?

I think hps@ has a fix for this that uses a sequency of DELAY()s. The problem is that in freebsd, attach runs before the scheduler is running. Consequently, code using sleep primitives tends to hang because ticks never advance. The scheduler / threading starts much earlier on linux. -M On Tue,

Re: Intel i7-6700T aka Skylake Support

On Sat, Apr 30, 2016 at 4:45 PM, Pete Wright wrote: > I recently acquired a Lenovo M900 Tiny desktop system which comes with an > intel i7-6700T Skylate CPU and Intel HD 530 graphics processor. I am > successfully running 11-CURRENT via EFI but have three devices which I am

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >> > >> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >> >

Re: [CFT] packaging the base system with pkg(8)

On Tuesday, April 19, 2016, Adrian Chadd wrote: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. > > Because, honestly - fuck it, we've been behind for too long. We need >

Re: [CFT] packaging the base system with pkg(8)

On Tuesday, April 19, 2016, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of

Re: CURRENT slow and shaky network stability

Sorry meant inpcb and autocorrect "fixed" it. On Saturday, March 26, 2016, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote: > Am Fri, 25 Mar 2016 13:31:31 -0700 > "K. Macy" <km...@freebsd.org <javascript:;>> schrieb: > > > Does this p

Re: CURRENT slow and shaky network stability

Does this pre or postage input changes? On Friday, March 25, 2016, O. Hartmann wrote: > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD > 11.0-CURRENT #9 > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and > like

Re: Instant panic while trying run ports-mgmt/poudriere

Is this still happening? On Jul 15, 2015 1:41 PM, Pawel Pekala pa...@freebsd.org wrote: Hi John-Mark, On 2015-07-15 11:05 -0700, John-Mark Gurney j...@funkthat.com wrote: Please repost the entire panic message, and the back trace w/o X running... Also, if you could share the core and kernel

Re: GPF on Current kernel

) at subr_syscall.c:133 the td value. What would you suggest? This has become intermittent :( On 2015-07-06 00:42, K. Macy wrote: The value of the mutex in the stack trace indicates that it's a use after free. There are various memory debugging options (memguard, redzone) that may help track

Re: GPF on Current kernel

The value of the mutex in the stack trace indicates that it's a use after free. There are various memory debugging options (memguard, redzone) that may help track it down. -K On Jul 5, 2015 2:37 PM, Larry Rosenman l...@lerctr.org wrote: I've gotten a couple of these: borg.lerctr.org dumped

Re: Doing zero-copy stuff in drivers, or is vm_fault_quick_hold_pages() enough ?

On Mon, Mar 2, 2015 at 12:42 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, gonzo@ committed a fix (r278615) to the videocore driver for the raspberry pi. The fix involved doing an explicit wire of pages that were about to be passed down to the hardware to send to the videobuffer hardware.

Re: Doing zero-copy stuff in drivers, or is vm_fault_quick_hold_pages() enough ?

Right above vm_page_hold(): /* * Keep page from being freed by the page daemon * much of the same effect as wiring, except much lower * overhead and should be used only for *very* temporary * holding (wiring). */ What's the definition of very temporary holding ? What's the

Re: nagios vs w/uptime

I wonder if that implies that any non-normal exit from a program that has been xo'd will result in the loss of output that would not have been lost before the xo changes? That could lead to all kinds of subtle failures of existing scripts and apps. Well, so long as the app doesn't crash in

Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

Hi Hans, It mostly looks fine, but it's a large change and there are some places in the patch where it isn't clear that the right thing is being done by looking at the patch alone. Please give us some time to review. Thanks. -K On Wed, Nov 19, 2014 at 11:02 AM, Hans Petter Selasky

Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky h...@selasky.org wrote: On 11/19/14 21:46, K. Macy wrote: Hi Hans, It mostly looks fine, but it's a large change and there are some places in the patch where it isn't clear that the right thing is being done by looking at the patch alone

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky h...@selasky.org wrote: Hi Luigi, On 08/20/14 11:32, Luigi Rizzo wrote: On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org wrote:

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

- uint32_t - m_flowid_t is plain gratuitous. Now we need to include mbuf.h in more places just to get this definition. What's the advantage of this? style(9) isn't too fond of typedefs either. Also, drivers *do* need to know the width of the flowid. At least lagg(4) looks

Re: fast bcopy...

It's highly chipset and processor dependent what works best. Intel now has non-temporal loads and stores which work much better in some cases but provide little benefit in others. -Kip On Wed, May 2, 2012 at 11:52 PM, Steven Atreju snatr...@googlemail.com wrote: Luigi Rizzo wrote: 2.

Re: Some performance measurements on the FreeBSD network stack

mail that I received from you. The final part having been dedicated to the narrow potential ABI changes that were to make it in to the release. From: Bjoern A. Zeeb b...@freebsd.org Date: Mon, Sep 19, 2011 at 3:19 PM To: K. Macy km...@freebsd.org Cc: Robert Watson rwat...@freebsd.org, rysto32 ryst

Re: Some performance measurements on the FreeBSD network stack

On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote: From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time, if i remember well), but there was a large gain with multiple

Re: Some performance measurements on the FreeBSD network stack

On Tue, Apr 24, 2012 at 5:03 PM, K. Macy km...@freebsd.org wrote: On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote: From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time

Re: Some performance measurements on the FreeBSD network stack

On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote: From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time, if i

Re: pmap and mtx scalability problem

Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. -Kip On Tue, Apr 24, 2012 at 9:14 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine and see poor scalability of

Re: pmap and mtx scalability problem

Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote: Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. split locking to process-specific information and global information? use lock-free lists (i see

Re: pmap and mtx scalability problem

It's a bit dated at this point. Nonetheless, when gitorious is able to give something other than 503 to my search queries I'll post it. On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote: No. I developed a patch

Re: pmap and mtx scalability problem

You can try these. Your mileage *will* vary. https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_release_8_1_0_page_lock https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_page_lock On Tue, Apr 24, 2012 at 10:51 PM, K. Macy km...@freebsd.org wrote: It's a bit

Re: Some performance measurements on the FreeBSD network stack

Most of these issues are well known. Addressing the bottlenecks is simply time consuming due to the fact that any bugs introduced during development potentially impact many users. -Kip On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd adr...@freebsd.org wrote: Hi, This honestly sounds like it's

Re: Some performance measurements on the FreeBSD network stack

Comments inline below: On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote: On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote

Re: Some performance measurements on the FreeBSD network stack

This is indeed a big problem.  I'm working (rough edges remain) on changing the routing table locking to an rmlock (read-mostly) which This only helps if your flows aren't hitting the same rtentry. Otherwise you still convoy on the lock for the rtentry itself to increment and decrement the

Re: Some performance measurements on the FreeBSD network stack

On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo ri...@iet.unipi.it wrote: On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote: This is indeed a big problem. ?I'm working (rough edges remain) on changing the routing table locking to an rmlock (read-mostly) which This only helps if your

Re: Some performance measurements on the FreeBSD network stack

This only helps if your flows aren't hitting the same rtentry. Otherwise you still convoy on the lock for the rtentry itself to increment and decrement the rtentry's reference count. The rtentry lock isn't obtained anymore.  While the rmlock read lock is held on the rtable the relevant

Re: Some performance measurements on the FreeBSD network stack

Yes, but the lookup requires a lock?  Or is every entry replicated to every CPU?  So a number of concurrent CPU's sending to the same UDP destination would content on that lock? No. In the default case it's per CPU, thus no serialization is required. But yes, if your transmitting thread

Re: Some performance measurements on the FreeBSD network stack

On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann an...@freebsd.org wrote: On 19.04.2012 23:17, K. Macy wrote: This only helps if your flows aren't hitting the same rtentry. Otherwise you still convoy on the lock for the rtentry itself to increment and decrement the rtentry's reference count

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

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

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: fifo_listen: fchmod public/pickup: Invalid argument with postfix on today's current

On Sat, Feb 25, 2012 at 2:15 PM, Attilio Rao atti...@freebsd.org wrote: Il 25 febbraio 2012 07:15, Doug Barton do...@freebsd.org ha scritto: On 02/24/2012 21:00, Doug Barton wrote: I'm on today's -current (r232126) and I'm getting the error in the subject when trying to start postfix. I

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

Someone was seeing the same issue with the vmtools kmod. The only thing that might make sense is that the page lock array is defined as being a different size in your kmod as in the kernel itself so the lock corresponding to the page you're locking differs between the two files. Cheers On Fri,

Re: BETA3 core dump

You need to change the permissions. I'm getting a 403 from nginx. On Sat, Oct 1, 2011 at 12:20 PM, Volodymyr Kostyrko c.kw...@gmail.com wrote: Hi all. BETA3 dumps core on running heavy disk bound application. Built with clang and kernel is custom, but I can try to reproduce it on GENERIC if

Re: After r22561[78] some kmods do not build any more

This is a side effect of the syscall namespace disambiguation. I will send patches to the ports maintainers. Thanks On Sat, Sep 17, 2011 at 10:29 AM, Rainer Hurling rhur...@gwdg.de wrote: Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me trouble with at least to kmods

Re: 9.0-BETA2 do not support SpeedStep on E5420

On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon a...@freebsd.org wrote: on 15/09/2011 19:20 Arnaud Lacombe said the following: est0: failed to enable SpeedStep p4tcc0: CPU Frequency Thermal Control on cpu0 est1: failed to enable SpeedStep p4tcc1: CPU Frequency Thermal Control on cpu1 est2:

Re: 9.0-BETA2 do not support SpeedStep on E5420

I was just discussing this issues with some others - evidently est(9) works fine on both older and newer cpus. I see you're active on lkml - does the linux driver work correctly on this machine? i.e. do you know that it isn't disabled in the BIOS. Thanks On Thu, Sep 15, 2011 at 6:20 PM, Arnaud

Re: lock order reversal

When WITNESS support was added to lockmgr locks a number of longstanding LORs were exposed in the process. I can't comment on whether or not they'll be fixed or the warnings will some day be silenced. On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov m...@vadimdenisov.ru wrote: I install current on

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni giffu...@tutopia.com wrote: FWIW; Christopher Bergström and Pathscale delivered the EKOPath Compiler Suite, but no one followed up: (From the WantedPorts Wiki) https://github.com/pathscale/path64-suite There has been very low interest in

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

But the lack of response and non-shown interests shows a undeobtly signal that freeBSD seems to be dead for the HPC community and this could be also an indication for the lack of CUDA support by nVidia, Why performing efforts if no one cares? A great chance seems to have passed by ... I

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible

Re: fast/syscall-free gettimeofday ?

On Tue, Jun 14, 2011 at 6:08 PM, K. Macy km...@freebsd.org wrote: http://svnweb.freebsd.org/base/head/sys/sys/imgact.h kib added rudimentary support for this in January To clarify, this is just the kernel side of the shared page infrastructure, and is currently only hosting the the signal

Re: fast/syscall-free gettimeofday ?

http://svnweb.freebsd.org/base/head/sys/sys/imgact.h kib added rudimentary support for this in January On Tue, Jun 14, 2011 at 6:11 PM, Luigi Rizzo ri...@iet.unipi.it wrote: there were discussions at some point on an imprecise but fast implementations of gettimeofday() that would not require

Re: 9.0-CURRENT-201105-amd64 install kernel panic

This recent commit changed the way that the value for size being passed to m_getjcl is initialized. Not seeing any obvious bugs, and not having any additional context I would guess that that you're receiving an interrupt before adapter-rx_mbuf_sz is set. I trust jfv@ to look in to this shortly.

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

Please try 207949 Thanks, Kip On Tue, May 11, 2010 at 6:18 AM, David Wolfskill da...@catwhisker.org wrote: On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: Could you please try with 207902? ... I saved that environment (documented elsewhere ini the thread), then performed

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

On Tue, May 11, 2010 at 9:24 PM, David Wolfskill da...@catwhisker.org wrote: On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote: Please try 207949 ... The panic (this time) didn't show up until about 10 seconds after the login: prompt showed up on the serial console.  Here's what

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

Could you please try with 207902? Thanks, Kip On Mon, May 10, 2010 at 11:26 AM, David Wolfskill da...@catwhisker.org wrote: On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote: ... You don't happen to have a backtrace? Oops -- sorry; got caught up in getting ready to head in to

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

On Mon, May 10, 2010 at 2:32 PM, K. Macy km...@freebsd.org wrote: Could you please try with 207902? And if not, please get a coredump with a backtrace with symbols. Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman

Re: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while in kernel mode

Are you not able to dump core? Thanks, Kip On Mon, May 10, 2010 at 3:08 PM, David Wolfskill da...@catwhisker.org wrote: On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: Could you please try with 207902? ... First, thanks for the response. OK; I grabbed r207902 applied it (via

Re: Recent sys/vm/ changes and nvidia-driver

On Sat, May 8, 2010 at 2:20 PM, b. f. bf1...@googlemail.com wrote: On 05/08/10 13:36, Alan Cox wrote: Doug Barton wrote: On 05/05/10 11:56, Alan Cox wrote: I'm afraid that I would advise waiting a few days.  This round of changes are not yet complete. What performance differences, if any,

Re: Panic @r207433: System call fork returning with the following locks held

Sadly, it doesn't do it for me .. lockd start-up causes a panic on a sleeping thread. Do I need to do a buildworld as well as kernel? We're calling vm_pageout_flush with the page queue lock held in vm_object_page_collect_flush. I'll have a fix in soon. Thanks, Kip

Re: Panic @r207433: System call fork returning with the following locks held

On Fri, Apr 30, 2010 at 12:38 PM, K. Macy km...@freebsd.org wrote: Sadly, it doesn't do it for me .. lockd start-up causes a panic on a sleeping thread. Do I need to do a buildworld as well as kernel? We're calling vm_pageout_flush with the page queue lock held

  1   2   >