Hi,
I just proceeded a full upgrade from FreeBSD 9.1-RELEASE to the latest
9-STABLE snapshot using tarball sets.
I done it this way :
tar xpf src.txz -C /
tar xf base.txz -C /usr/src
mergemaster -p
mergemaster -FUi
tar cpf etc.tar -C / etc
tar xpf base.tar -C /
tar xpf etc.tar -C /
tar xpf
On Mon, Dec 03, 2012 at 03:11:21PM +, Karl Pielorz wrote:
>
> Hi,
>
> I have two SuperMicro E31220L based systems - both had identical
> /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of
> 2012/12/03).
>
> Now I've noticed of them compla
Hi,
I have two SuperMicro E31220L based systems - both had identical
/etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of
2012/12/03).
Now I've noticed of them complains at boot time that a bunch of OID's are
missing - and sure enough:
"
sysctl ker
On Thu, Nov 22, 2012 at 03:19:53PM +, Ed Schouten wrote:
> Author: ed
> Date: Thu Nov 22 15:19:53 2012
> New Revision: 243405
> URL: http://svnweb.freebsd.org/changeset/base/243405
> Log:
> MFC r229848:
> Add aligned_alloc(3).
> The C11 folks reinvented the wheel by introducing an
On 12 July 2012 18:52, Chris Rees wrote:
> On 9 July 2012 02:49, David Xu wrote:
>> On 2012/07/08 18:21, Chris Rees wrote:
>>>
>>> Hi all / David,
>>>
>>> doxygen has been failing for a while now on -CURRENT and apparently
>>> -STABLE too.
On Tue, Aug 7, 2012 at 4:37 PM, Ryan Stone wrote:
> On Tue, Aug 7, 2012 at 7:16 PM, Sean Bruno wrote:
>> I have no idea the significance, or danger. When compiling on stable/9
>> I have always seen the following WARNINGS. Can we silence/fix these?
>> Or is it su
On Tue, Aug 7, 2012 at 7:16 PM, Sean Bruno wrote:
> I have no idea the significance, or danger. When compiling on stable/9
> I have always seen the following WARNINGS. Can we silence/fix these?
> Or is it supposed to be that way? :-)
>
> WARNING: hwpmc_soft.c: enum pmc_eve
Not sure what to make of this error:
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
my kernel is compiling, but I seem to fail at understanding something?
Sean
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/
I have no idea the significance, or danger. When compiling on stable/9
I have always seen the following WARNINGS. Can we silence/fix these?
Or is it supposed to be that way? :-)
WARNING: hwpmc_soft.c: enum pmc_event has too many values: 1531 > 1023
WARNING: kern_pmc.c: enum pmc_event has
ote:
> >>>> The xhci code in 8-stable works, but it's not mentioned in the NOTES
> >>>> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
> >>>> hooked up in sys/modules/usb/Makefile, and that's how I've been using
>
On 07/19/2012 03:29, Hans Petter Selasky wrote:
> On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
>> On 07/19/2012 02:17, Hans Petter Selasky wrote:
>>> On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
>>>> The xhci code in 8-stable works, but it's not m
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
> On 07/19/2012 02:17, Hans Petter Selasky wrote:
> > On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
> >> The xhci code in 8-stable works, but it's not mentioned in the NOTES
> >> files in sys/conf, sys/i
On 07/19/2012 02:17, Hans Petter Selasky wrote:
> On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
>> The xhci code in 8-stable works, but it's not mentioned in the NOTES
>> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
>> hooked up in sys/module
On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
> The xhci code in 8-stable works, but it's not mentioned in the NOTES
> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
> hooked up in sys/modules/usb/Makefile, and that's how I've been using it
>
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
On 9 July 2012 02:49, David Xu wrote:
> On 2012/07/08 18:21, Chris Rees wrote:
>>
>> Hi all / David,
>>
>> doxygen has been failing for a while now on -CURRENT and apparently
>> -STABLE too. The current fix is disabling one of the tests in the
>> build, bu
On 2012/07/08 18:21, Chris Rees wrote:
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing code [2], and it looks as though it'
On 31 May 2012 07:55, John Baldwin wrote:
> On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote:
>> Hi,
>>
>> I've re-run the test with powerd and sleep state stuff disabled - lo
>> and behold, UDP tests are now up around 240-250MBit, what I'd expect
>> for this 2 stream 11n device.
>>
>> So
On 05/31/12 01:02, Adrian Chadd wrote:
I've re-run the test with powerd and sleep state stuff disabled - lo
and behold, UDP tests are now up around 240-250MBit, what I'd expect
for this 2 stream 11n device.
So why is it that I lose roughly 80MBit of throughput with powerd and
C2/C3 enabled, when
On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote:
> Hi,
>
> I've re-run the test with powerd and sleep state stuff disabled - lo
> and behold, UDP tests are now up around 240-250MBit, what I'd expect
> for this 2 stream 11n device.
>
> So why is it that I lose roughly 80MBit of throughput
Ryan Stone wrote:
> On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote:
> > In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC.
>
> KTR_SCHED comes with a performance hit. Besides, with the DTrace
> sched provider that I committed this month (and MFC'ed yesterday) you
> c
Hi,
That's cool and one of the things I'm using this to investigate.
However, I'm still seeing weird TSC behaviour, which I'd like to
finish trying to root cause before moving onto bigger and weirder
things.
I'm not sure how feasible it'd be to "make" KTR work with power saving
modes enabled on
On Thu, May 31, 2012 at 8:48 AM, Ryan Stone wrote:
> KTR_SCHED comes with a performance hit. Besides, with the DTrace
> sched provider that I committed this month (and MFC'ed yesterday) you
> can collect schedgraph data with a D script.
I suppose it would have been helpful to provide a link to t
on 31/05/2012 15:48 Ryan Stone said the following:
> On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote:
>> In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC.
>
> KTR_SCHED comes with a performance hit.
Yep, I realize that. But I hope that it is not too huge for typical u
On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote:
> In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC.
KTR_SCHED comes with a performance hit. Besides, with the DTrace
sched provider that I committed this month (and MFC'ed yesterday) you
can collect schedgraph data with
Sorry to hijack this thread, but just recently I've stumbled upon this Linux
tool:
http://lwn.net/Articles/353295/
perf sched latency seems to be particularly convenient and useful. The idea to
track time between a point when a thread is waken up and a point when the thread
actually run was qui
Hi,
Here's a trace with powerd/sleep states disabled, but I haven't set
machdep.idle=spin. I'll try it with that in a sec.
http://people.freebsd.org/~adrian/ath/ktr-notaskq-1.out.gz
The entries are still out of whack in places, but it doesn't look like
it's necessarily due to out of sync TSCs..
Hi,
I've re-run the test with powerd and sleep state stuff disabled - lo
and behold, UDP tests are now up around 240-250MBit, what I'd expect
for this 2 stream 11n device.
So why is it that I lose roughly 80MBit of throughput with powerd and
C2/C3 enabled, when there's plenty of CPU going around?
ever ath_start() is called, it just schedules a
> taskqueue entry to run.
>
> However, performance is worse. :-)
>
> Here's a schedgraph trace.
>
> http://people.freebsd.org/~adrian/ath/ktr.4-ath-iperf-using-taskqueue-for-
tx.ktr.gz
>
> I've thrown this through s
chedules a
> taskqueue entry to run.
>
> However, performance is worse. :-)
>
> Here's a schedgraph trace.
>
> http://people.freebsd.org/~adrian/ath/ktr.4-ath-iperf-using-taskqueue-for-tx.ktr.gz
>
> I've thrown this through schedgraph.py on stable/9 and I've f
.. also, if you take a look at the ktr output, the CPU timers between
CPU 0 and CPU 1 are slightly different. schedgraph complains quite
loudly. :-)
Is that acceptable/possible?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.
performance is worse. :-)
Here's a schedgraph trace.
http://people.freebsd.org/~adrian/ath/ktr.4-ath-iperf-using-taskqueue-for-tx.ktr.gz
I've thrown this through schedgraph.py on stable/9 and I've found some
rather annoying behaviour. It seems that the ath0 taskqueue stays in
the &qu
On Mon, 09 Jan 2012 19:56:47 -0600, Hiroki Sato wrote:
This is an expected behavior. ACCEPT_RTADV is disabled by default on
9.X.
Thanks for clarifying. I'll make sure I update our documentation at work
regarding how exactly to get ACCEPT_RTADV working so this is clarified.
Regards,
Mark Felder wrote
in :
fe> On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato
fe> wrote:
fe>
fe> > re0 seems to have ACCEPT_RTADV. What is the problem?
fe>
fe> That's because I haven't rebooted
fe>
fe> Let's start fresh.
fe>
fe> The normal ipv6 configuration anyone would use:
fe>
fe> -ipv6_a
On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato wrote:
re0 seems to have ACCEPT_RTADV. What is the problem?
That's because I haven't rebooted
Let's start fresh.
The normal ipv6 configuration anyone would use:
-ipv6_activate_all_interfaces="YES" in rc.conf
-NO mention of net.inet6.ip6
Mark Felder wrote
in :
fe> On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato
fe> wrote:
fe>
fe> > It is an unexpected behavior and the flag should be set on all
fe> > interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and
fe> > the result of "ifconfig -a"?
fe>
fe> Back at work
On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato wrote:
It is an unexpected behavior and the flag should be set on all
interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and
the result of "ifconfig -a"?
Back at work so I have access to the machine again:
rc.conf:
hostname="
Mark Felder wrote
in <891fe25c-1560-479f-b855-1713c1c7a...@email.android.com>:
fe> Hiroki Sato wrote:
fe> >
fe> > Is it correct that ACCEPT_RTADV option was enabled on the vboxnet0
fe> > and not on re0, even after setting net.inet6.ip6.accept_rtadv to 1 at
fe> > boot time and ipv6_activate_all
Hiroki Sato wrote:
>
> Is it correct that ACCEPT_RTADV option was enabled on the vboxnet0
> and not on re0, even after setting net.inet6.ip6.accept_rtadv to 1 at
> boot time and ipv6_activate_all_interfaces="YES"?
>
>-- Hiroki
Yes, that is the behavior I witnessed.
_
Mark Felder wrote
in :
fe> I figured I would end up putting that in rc.conf as a temporary fix,
fe> but maybe that's just the long term solution. It seems so odd to me
fe> that the sysctl change doesn't automatically cause the ACCEPT_RTADV
fe> option to show up for re0, but it does for vboxnet0
Looping in hrs@ because he's the author of those changes.
On 01/06/2012 11:35, Mark Felder wrote:
> On Fri, 06 Jan 2012 12:49:45 -0600, Sergey Kandaurov
> wrote:
>
>>
>> You mean ipv6_activate_all_interfaces="YES" ?
>>
> Yes... Unfortunately that's what I get for typing it manually and being
> d
On Fri, 06 Jan 2012 12:49:45 -0600, Sergey Kandaurov
wrote:
You mean ipv6_activate_all_interfaces="YES" ?
Yes... Unfortunately that's what I get for typing it manually and being
distracted at the time. :-)
What is in your rc.conf? Do you have "inet6 accept_rtadv" keyword in it?
IIRC it
> Currently I'm running:
>
> 12:11:15 tech304:~ > uname -a
> FreeBSD tech304.office.supranet.net 9.0-STABLE FreeBSD 9.0-STABLE #2
> r229703M: Fri Jan 6 11:01:58 CST 2012
> r...@tech304.office.supranet.net:/usr/obj/tank/svn/sys/GENERIC amd64
>
> and my ipv6 is not
eeBSD tech304.office.supranet.net 9.0-STABLE FreeBSD 9.0-STABLE #2
r229703M: Fri Jan 6 11:01:58 CST 2012
r...@tech304.office.supranet.net:/usr/obj/tank/svn/sys/GENERIC amd64
and my ipv6 is not working. In rc.conf I have
ipv6_enable_all_interfaces="YES" which sets the link local an
IC).. This has the distinct disadvantage that I cannot,
through my module, call a device_detach() on the devices I support, and
afterward expect being probed for them. A BUS_PROBE_SPECIFIC, according
to wording in sys/sys/bus.h, inform the OS that "Only I can use this
device".
I assum
On Monday, May 23, 2011 3:08:05 pm Andrew Boyer wrote:
>
> On May 23, 2011, at 10:32 AM, John Baldwin wrote:
>
> > On Monday, May 23, 2011 10:13:41 am Philip Soeberg wrote:
> >> I would also expect the ixgbe.c driver to do a quick resource_disabled()
> >> in it's attach() function, so that we ca
On Monday, May 23, 2011 1:22:50 pm Philip Soeberg wrote:
> On 23-05-2011 16:32, John Baldwin wrote:
> >> I assume this (transcanding from FreeBSD 7.0-STABLE through to FreeBSD
> >> 9-CURRENT) is in error? I would expect sys/dev/ixgbe/ixgbe.c's probe()
> >> f
On May 23, 2011, at 10:32 AM, John Baldwin wrote:
> On Monday, May 23, 2011 10:13:41 am Philip Soeberg wrote:
>> I would also expect the ixgbe.c driver to do a quick resource_disabled()
>> in it's attach() function, so that we can disable specific adapters
>> through kenv hint.ix.0.disabled=1..
On 23-05-2011 16:32, John Baldwin wrote:
I assume this (transcanding from FreeBSD 7.0-STABLE through to FreeBSD
9-CURRENT) is in error? I would expect sys/dev/ixgbe/ixgbe.c's probe()
function to return BUS_PROBE_DEFAULT, which is the "Base OS default
driver"..
Yes, that is tru
; afterward expect being probed for them. A BUS_PROBE_SPECIFIC, according
> to wording in sys/sys/bus.h, inform the OS that "Only I can use this
> device".
>
> I assume this (transcanding from FreeBSD 7.0-STABLE through to FreeBSD
> 9-CURRENT) is in error?
he OS that "Only I can use this
device".
I assume this (transcanding from FreeBSD 7.0-STABLE through to FreeBSD
9-CURRENT) is in error? I would expect sys/dev/ixgbe/ixgbe.c's probe()
function to return BUS_PROBE_DEFAULT, which is the "Base OS default
driver"..
If th
On Fri, Feb 25, 2011 at 11:25:00PM -0800, Tim Kientzle wrote:
> On Feb 25, 2011, at 3:46 PM, Steven Hartland wrote:
>
> > While I can understand some may want its not something we use on any of
> > our machines, and I suspect that's the case for many others.
> >
> > Given adding it means the kern
On Feb 25, 2011, at 3:46 PM, Steven Hartland wrote:
> While I can understand some may want its not something we use on any of
> our machines, and I suspect that's the case for many others.
>
> Given adding it means the kernel will be doing extra work and hence a
> drop in performance...
Does any
While I can understand some may want its not something we use on any of
our machines, and I suspect that's the case for many others.
Given adding it means the kernel will be doing extra work and hence a
drop in performance for a feature most will never use, I'm guessing here,
I would say just lea
Actually, GENERIC is there to provide the most features for the most
uses. A large percentage of users don't config new kernels, and FreeBSD
has not elected the approach Digital Unix (aka "DUH") took about
installs which required a reconfig as one of the last steps of an
installation.
I can't
I promise to enable UFS quotas in GENERIC in one week unless anybody
objects
now.
Huh? I thought GENERIC was supposed to include everything you needed to
boot, not every possible feature that someone might desire?
But requests to include things required to boot get rejected and
nonessential
On Tue, Feb 22, 2011 at 01:06:38PM -0500, Ben Kaduk wrote:
> [replying to the MFC that triggered the connection]
>
> On Tue, Feb 22, 2011 at 12:38 PM, Bruce Cran wrote:
> > Author: brucec
> > Date: Tue Feb 22 17:38:43 2011
> > New Revision: 218953
> > URL: http://svn.freebsd.org/changeset/base/21
[replying to the MFC that triggered the connection]
On Tue, Feb 22, 2011 at 12:38 PM, Bruce Cran wrote:
> Author: brucec
> Date: Tue Feb 22 17:38:43 2011
> New Revision: 218953
> URL: http://svn.freebsd.org/changeset/base/218953
>
> Log:
> MFC r218840:
>
> Remove the quotas option from the Star
e8c
from /var/run/dmesg.boot
Copyright (c) 1992-2010 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 8.1-STAB
On Wed, August 11, 2010 7:31 am, Andrew Heybey wrote:
> On Aug 11, 2010, at 6:47 AM, Dan Langille wrote:
>
>> I am encountering a situation similar to one reported by Andrew Heybey
>> at
>> http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
>>
>> This morning I found this in
On Aug 11, 2010, at 6:47 AM, Dan Langille wrote:
> I am encountering a situation similar to one reported by Andrew Heybey
> at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
>
> This morning I found this in my /var/log/messages:
>
> Aug 11 01:59:48 kraken kernel: MCA:
dmesg.boot
Copyright (c) 1992-2010 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 8.1-STABLE #0: Sun Jul 25 19
Hi All,
This is related to a post I made the other day in freebsd-fs, which didn't
get any replies (I'm a bit desperate as I need to replace a failing drive
on the system - hence need to attach a spare - so apologies for the kind of
cross-post)...
I'm running 7.3-STABLE on a
d from a different slice.
After getting the 7.x machine set up, I effectively cloned it to
be the starting-point for the 8.x machine. I then booted from a
recent
stable/7, updated sources to stable/8, then:
* cd /usr/src
* make buildworld
* make kernel # I'm using GENERIC for 8.x; I had u
On Thu, Feb 11, 2010 at 7:13 AM, John Baldwin wrote:
> On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote:
> > On 10 February 2010 19:35, Andriy Gapon wrote:
> > > on 10/02/2010 20:26 Ivan Voras said the following:
> > >> On 10 February 2010 19:10, Andriy Gapon wrote:
> > >>> on 10/02/20
On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote:
> On 10 February 2010 19:35, Andriy Gapon wrote:
> > on 10/02/2010 20:26 Ivan Voras said the following:
> >> On 10 February 2010 19:10, Andriy Gapon wrote:
> >>> on 10/02/2010 20:03 Ivan Voras said the following:
> When you say "very
On 10 February 2010 19:35, Andriy Gapon wrote:
> on 10/02/2010 20:26 Ivan Voras said the following:
>> On 10 February 2010 19:10, Andriy Gapon wrote:
>>> on 10/02/2010 20:03 Ivan Voras said the following:
When you say "very unique" is it in the "it is not Linux or Windows"
sense or do w
on 10/02/2010 20:26 Ivan Voras said the following:
> On 10 February 2010 19:10, Andriy Gapon wrote:
>> on 10/02/2010 20:03 Ivan Voras said the following:
>>> When you say "very unique" is it in the "it is not Linux or Windows"
>>> sense or do we do something nonstandard?
>> The former - neither Li
On 10 February 2010 19:26, Ivan Voras wrote:
> On 10 February 2010 19:10, Andriy Gapon wrote:
>> on 10/02/2010 20:03 Ivan Voras said the following:
>>> When you say "very unique" is it in the "it is not Linux or Windows"
>>> sense or do we do something nonstandard?
>>
>> The former - neither Linu
On 10 February 2010 19:10, Andriy Gapon wrote:
> on 10/02/2010 20:03 Ivan Voras said the following:
>> When you say "very unique" is it in the "it is not Linux or Windows"
>> sense or do we do something nonstandard?
>
> The former - neither Linux, Windows or OpenSolaris seem to have what we have.
on 10/02/2010 20:03 Ivan Voras said the following:
> When you say "very unique" is it in the "it is not Linux or Windows"
> sense or do we do something nonstandard?
The former - neither Linux, Windows or OpenSolaris seem to have what we have.
So we might be the first testers for certain processor
On 10 February 2010 18:13, Andriy Gapon wrote:
> on 10/02/2010 19:05 Ivan Voras said the following:
>> On 02/10/10 17:05, Andriy Gapon wrote:
>>> Wild guess - try disabling superpages in the guests.
>>
>> It looks like your guess is perfectly correct :) The guest has been
>> doing buildworlds for
on 10/02/2010 19:05 Ivan Voras said the following:
> On 02/10/10 17:05, Andriy Gapon wrote:
>> on 10/02/2010 17:36 Ivan Voras said the following:
>>> It looks like I've stumbled upon a bug in vSphere 4 (recent update) with
>>> FreeBSD/amd64 8.0/8-stable (but not 7.
on 10/02/2010 17:36 Ivan Voras said the following:
> It looks like I've stumbled upon a bug in vSphere 4 (recent update) with
> FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this
> combination, everything works fine until a moderate load is started - a
> bui
On Wed, 10 Feb 2010, Ivan Voras wrote:
It looks like I've stumbled upon a bug in vSphere 4 (recent update)
with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In
this combination, everything works fine until a moderate load is
started - a buildworld is enough. About
Yuri wrote:
> After upgrading sources (RELENG_8) I get the errors below.
>
> Yuri
>
> --- error log ---
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq
> -fi
After upgrading sources (RELENG_8) I get the errors below.
Yuri
--- error log ---
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param i
On Thu, Dec 10, 2009 at 8:50 AM, Bernd Walter wrote:
> On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote:
> > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote:
> > > It's not clear to me if this might be a problem with the superpages
> > > implementation, or if squid d
On Thu, 10 Dec 2009, Nate Eldredge wrote:
What about using posix_spawn(3)? This is implemented in terms of vfork(),
so you'll gain the same performance advantages, but it avoids many of
vfork's pitfalls. Also, since it's a POSIX standard function, you needn't
worry that it will go away or c
On Thursday 10 December 2009 9:50:52 am Bernd Walter wrote:
> On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote:
> > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote:
> > > It's not clear to me if this might be a problem with the superpages
> > > implementation, or if s
Depending upon the IPC method being used, the fork() may be followed
with calls to socket() and connect(), which may take a while.
The main process will stall if you have a busy proxy and there's some
temporary shortage of something which makes connect() take longer than
usual, the main process wi
ations, yet:
> BUGS
> This system call will be eliminated when proper system sharing mechanisms
> are implemented. Users should not depend on the memory sharing semantics
> of vfork() as it will, in that case, be made synonymous to fork(2).
>
FYI, this comment has
On Thu, 10 Dec 2009, Linda Messerschmidt wrote:
Also...
On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote:
I use fork myself, because it is easier sometimes, but people writing
big programms such as squid should know better.
If squid doesn't use vfork they likely have a reason.
Actually t
Also...
On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote:
> I use fork myself, because it is easier sometimes, but people writing
> big programms such as squid should know better.
> If squid doesn't use vfork they likely have a reason.
Actually they are probably going to switch to vfork(). T
On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote:
> I obviously don't have enough clue about this to understand those details.
> Hope that someone can enlighten me.
I think what he is saying is that they are aware that the current
situation is not ideal.
vfork() is suggested as a workaround,
On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote:
> On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote:
> > It's not clear to me if this might be a problem with the superpages
> > implementation, or if squid does something particularly horrible to
> > its memory when it
On Wed, Dec 9, 2009 at 9:07 AM, John Baldwin wrote:
> There is lower hanging fruit in other areas
> in the VM that will probably be worked on first.
OK, as long as somebody who knows more than me knows whats going on,
that's good enough for me. :)
Thanks!
On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote:
> It's not clear to me if this might be a problem with the superpages
> implementation, or if squid does something particularly horrible to
> its memory when it forks to cause this, but I wanted to ask about it
> on the list in cas
on 07/12/2009 17:20 Mel Flynn said the following:
> b) vfork is encouraged for memory intensive applications, yet:
> BUGS
> This system call will be eliminated when proper system sharing mechanisms
> are implemented. Users should not depend on the memory sharing semantics
> of vfork
On Thursday 26 November 2009 18:11:10 Linda Messerschmidt wrote:
> I did not mean to suggest that we were asking for help solving a
> problem with squid rotation. I provided that information as
> background to discuss what we observed as a potential misbehavior in
> the new VM superpages feature,
On Fri, 27 Nov 2009, Adrian Chadd wrote:
> There's a bunch of other random crap that may be going on relating to
> the helper processes (eg rewriters, auth, etc) which may also be
> restarted.
OK.
> Anyway. The thread is about superpage demotion and copying, not what
> Squid is or isn't doing in
There's a bunch of other random crap that may be going on relating to
the helper processes (eg rewriters, auth, etc) which may also be
restarted.
Anyway. The thread is about superpage demotion and copying, not what
Squid is or isn't doing in her configuration. :)
Adrian
2009/11/27 Daniel O'Con
On Fri, 27 Nov 2009, krad wrote:
> Im sure you will get a lot of lovely answers to this but best keep
> things simple. WHy not just syslog it of to another server and
> offload all the compression to that box. You could even back it with
> zfs nad do on the fly gzip compression at the file system l
;s like it's trying to recover
> and convert things back (promotions), but it's having a lot of trouble
> (p_failures).
>
> It's not clear to me if this might be a problem with the superpages
> implementation, or if squid does something particularly horrible to
>
I think I was not clear with my message, I apologize.
I did not mean to suggest that we were asking for help solving a
problem with squid rotation. I provided that information as
background to discuss what we observed as a potential misbehavior in
the new VM superpages feature, in the hope that i
Hi Linda,
vfork() should mitigate this -- i suggest replacing.
respectfully,
=jt
On Thu, Nov 26, 2009 at 10:47, Linda Messerschmidt
wrote:
> On Thu, Nov 26, 2009 at 10:34 AM, Ryan Stone wrote:
>> Is squid multithreaded?
>
> No, it isn't:
>
> PID USERNAME THR PRI NICE SIZE RES STATE C
Dag-Erling Smørgrav writes:
> Linda Messerschmidt writes:
> > Unfortunately, we have to rotate the logs of this process once per
> > day. When we do, it fork()s and exec()s about 16-20 child processes
> > as helpers.
> s/fork/vfork/ and you should be fine.
...and you should look into replacing
Linda Messerschmidt writes:
> Unfortunately, we have to rotate the logs of this process once per
> day. When we do, it fork()s and exec()s about 16-20 child processes
> as helpers.
s/fork/vfork/ and you should be fine.
DES
--
Dag-Erling Smørgrav - d...@des.no
__
On Thu, Nov 26, 2009 at 10:34 AM, Ryan Stone wrote:
> Is squid multithreaded?
No, it isn't:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
75086 squid 1 40 12571M 12584M kqread 6 31:31 0.68% squid
Thanks!
___
1 - 100 of 1371 matches
Mail list logo
