>
> 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 in.
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.
>> Ru
>
> 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 t
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 continuously on a build from this afternoon
>> (r334252):
>>
>>
t; 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 Sat, May 26, 2018 at 8:17 PM,
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 27 03:06:03 u0855 kernel: .
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 /usr/src/sys/net/if_var.h:241:2)'; did
> you mean 'stqe_next'?
Why are you running i386 on that?
On Tue, May 22, 2018 at 4:26 PM, Steve Kargl
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 "legacy".
>> >
>> > i3
> 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
>
>
>
> 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 ch
>
> 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 burden
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 removal of the drm2 bits
>> > > is that they prevent us from autom
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 wrote:
> 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 wro
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 wrote:
> Sorry about that. It looks like my review must have been missing a line.
>
> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>
> _if
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, device_get_nameunit(c
>
>
>
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 perce
On Monday, November 14, 2016, Lars Engels wrote:
> On Sun, Nov 13, 2016 at 01:56:45PM -0800, K. Macy wrote:
> > On Saturday, November 12, 2016, Mark Heily > wrote:
> >
> > > On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman
> > > > wrote:
> > &
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 "vainfo" it is unable
> to find a driver.
>
> The un
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 XCXX=/usr/local/bin/clang++37
>> XCPP=/usr/l
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 talking about for at lea
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, 1983
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 current drm-next-4.6 br
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
https://lists.freebs
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 ./machi
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 i-cache displacement you're n
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 in my dmesg when booti
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 get apt to work.
> > I
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 the callout interface
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
> loader.conf:
>
> ker
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.
-M
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 remember seeing it bef
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 any network lookups.
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 wrote:
> On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote:
>> I'm seeing watchdog resets on em(4) in my VM
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. Fort
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 > wrote:
>> >
>> > > Hi,
>> > >
>> > > I've ju
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
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, Ma
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
> unable to fully util
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
>> > packages?! WHY?! What are reasons and goals
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
> more mature tools and knowl
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 enthusiasm the FreeBSD proje
Sorry meant inpcb and autocorrect "fixed" it.
On Saturday, March 26, 2016, O. Hartmann
wrote:
> Am Fri, 25 Mar 2016 13:31:31 -0700
> "K. Macy" > schrieb:
>
> > Does this pre or postage input changes?
>
> ???
>
> First of all, and the most vi
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 "glue": it
> is slow with X11, somet
Is this still happening?
On Jul 15, 2015 1:41 PM, "Pawel Pekala" wrote:
> Hi John-Mark,
>
> On 2015-07-15 11:05 -0700, John-Mark Gurney wrote:
> >Please repost the entire panic message, and the back trace w/o X
> >running... Also, if you could share the core and kernel w/ me (you can
> >email m
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 memo
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" wrote:
> I've gotten a couple of these:
>
> borg.lerctr.org dumped core - see /v
>> 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" ? Wh
On Mon, Mar 2, 2015 at 12:42 PM, Adrian Chadd 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.
>
> It turns o
>
> 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
On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky 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
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 wrote:
> Hi
>
>
>
>> - 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)
On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo wrote:
> On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky
> wrote:
>
> > Hi Luigi,
> >
> >
> > On 08/20/14 11:32, Luigi Rizzo wrote:
> >
> >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky
> >> wrote:
> >>
> >> Hi,
> >>>
> >>> A month has
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 wrote:
> Luigi Rizzo wrote:
>> 2. apparently, bcopy is not the f
some interest. This
the relevant part of the last 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
Date: Mon, Sep 19, 2011 at 3:19 PM
To: "K. Macy"
Cc: Robert Watson
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 wrote:
> It's a bit dated
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 wrote:
> On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
>
>> No. I develo
Slawa Olhovchenkov 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?
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 wrote:
> I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine
> and see poor
> scalability of pmap/mtx -- more th
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo 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 remem
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote:
> On Tue, Apr 24, 2012 at 4:16 PM, 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 pac
On Tue, Apr 24, 2012 at 4:16 PM, 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 remember well),
>>but there was a large gain with multiple concurrent proce
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 wrote:
> Hi,
>
> This honestly sounds like it's begging for an
> i
Comments inline below:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo 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 wrote:
>> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> >>
On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann 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
>>>&g
>
> 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 ma
>> 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 rele
On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo 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
&g
>> 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
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
>
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
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 t
> 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 ope
> 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 "c
>
> ... 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 r
> 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
> es
> 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
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
.
>
> 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. T
On Sat, Feb 25, 2012 at 2:15 PM, Attilio Rao wrote:
> Il 25 febbraio 2012 07:15, Doug Barton 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 recompiled 2.9, and then tried
>>>
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, Oc
You need to change the permissions. I'm getting a 403 from nginx.
On Sat, Oct 1, 2011 at 12:20 PM, Volodymyr Kostyrko 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 that
> matters.
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 wrote:
> Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me
> trouble with at least to kmods from ports. They
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 La
On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon wrote:
> on 15/09/2011 19:20 Arnaud Lacombe said the following:
>> est0: failed to enable SpeedStep
>> p4tcc0: on cpu0
>> est1: failed to enable SpeedStep
>> p4tcc1: on cpu1
>> est2: failed to enable SpeedStep
>> p4tcc2: on cpu2
>> est3: failed to e
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 wrote:
> I install current on last week
> I have s
> 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 ...
On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni 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 the FreeBSD p
On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd 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
> to bring
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 wrote:
> there were discussions at some point on an imprecise but
> fast implementations of gettimeofday() that would not require
> a system call (p
On Tue, Jun 14, 2011 at 6:08 PM, K. Macy 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 handling
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.
h
On Tue, May 11, 2010 at 9:24 PM, David Wolfskill 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 c
Please try 207949
Thanks,
Kip
On Tue, May 11, 2010 at 6:18 AM, David Wolfskill 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
&
Are you not able to dump core?
Thanks,
Kip
On Mon, May 10, 2010 at 3:08 PM, David Wolfskill 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 &
On Mon, May 10, 2010 at 2:32 PM, K. Macy 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/listinfo/free
Could you please try with 207902?
Thanks,
Kip
On Mon, May 10, 2010 at 11:26 AM, David Wolfskill 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 work:
>
> db> bt
>
On Sat, May 8, 2010 at 2:20 PM, b. f. 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
Hi Andrew,
Does FBSDID get expanded when checking out with csup?
You should see:
__FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
22:31:37Z kmacy $");
line 451 is part of a KASSERT on this version.
Cheers,
Kip
On Fri, Apr 30, 2010 at 4:12 PM, Andrew Reilly wrote:
> Hi all,
>
>
How much memory do you have? I haven't been checking code in without
testing it, but clearly my system behaves a bit differently.
Please try 207452.
Thanks,
Kip
On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar wrote:
> At 02:21 PM 4/30/2010, K. Macy wrote:
>>On Fri, Apr 30, 2010
1 - 100 of 112 matches
Mail list logo
