On Mon, Aug 13, 2018 at 09:53:22PM -0400, Michael Butler wrote:
> non-SMP builds apparently don't define some required structures ..
Thanks, this should be fixed by r337751.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
non-SMP builds apparently don't define some required structures ..
--- kernel ---
linking kernel
ld: error: undefined symbol: cpu_info
>>> referenced by ucode.c
>>> ucode.o:(ucode_load_ap)
ld: error: undefined symbol: cpu_apic_ids
>>> referenced by u
On Fri, Oct 20, 2017 at 3:52 PM, Michael Butler
wrote:
> If SMP is not defined, as it isn't on my last remaining i386 platform, the
> build fails with:
>
> Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o
> --- kern_mutex.o ---
> /usr/src/sys/kern/kern_mutex.c:313:3: erro
If SMP is not defined, as it isn't on my last remaining i386 platform,
the build fails with:
Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o
--- kern_mutex.o ---
/usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of
function '_mtx_lock_spin' is invalid i
Building on an i386 without SMP after SVN r322588 yields this breakage:
Building /usr/obj/usr/src/sys/SARAH/intr_machdep.o
--- intr_machdep.o ---
/usr/src/sys/x86/x86/intr_machdep.c:78:23: warning: variable
'interrupt_sorted' is not needed and will not be emitted
[-Wunneede
Colin Percival wrote:
>On 05/28/17 13:16, Rick Macklem wrote:
>> cperciva@ is running a highly parallelized buuildworld and he sees better
>> slightly better elapsed times and much lower system CPU for SCHED_ULE.
>>
>> As such, I suspect it is the single threaded, processes mostly sleeping
>> wait
On 05/28/17 13:16, Rick Macklem wrote:
> cperciva@ is running a highly parallelized buuildworld and he sees better
> slightly better elapsed times and much lower system CPU for SCHED_ULE.
>
> As such, I suspect it is the single threaded, processes mostly sleeping
> waiting
> for I/O case that is
On 28/05/2017 01:20, Rick Macklem wrote:
> - with the "obvious change" mentioned in r312426's commit message, using
>(flags & SW_TYPE_MASK) == SWT_RELINQUISH instead of (flag & SWT_RELINQUISH)
>121minutes
Rick,
can I see how exactly
ses are the same single threaded kernel build, same hardware, etc. The
only
changes are recent vs 1yr old head kernel and what is noted.)
- 1yr old kernel, SMP, SCHED_ULE 94minutes
- 1yr old kernel, no SMP, SCHED_ULE 111minutes
- recent kernel, SMP, SCHED_4BSD
On 28/05/2017 01:20, Rick Macklem wrote:
> After poking at this some more, it appears that r312426 is the main cause of
> this degradation.
Rick,
thank you for the investigation!
A quick question before a longer reply: what network driver do you use in your
test setup? Is it ixl by a chance?
--
the last post, I got rid of most of the degradation by disabling
>SMP.
>
>- same kernel build running recent kernel with SCHED_4BSD 104minutes
>
After poking at this some more, it appears that r312426 is the main cause of
this degradation.
Doing SMP enabled test runs using SCHED_ULE
to something simple, the MPI master process on a SMP
system with N processers would fork N+1 processes where each process
is essentially independent and cpu-bound. N-1 of the processes would
be pinned to N-1 cpus and run with nearly 100% cpu usage. The N and
N+1 processes would be pinned to a single
the degradation by disabling
SMP.
- same kernel build running recent kernel with SCHED_4BSD 104minutes
I have now found I can get rid of almost all of the degradation by building the
recent kernel with
options SCHED_4BSD
instead of
options SCHED_ULE
The 1yr old kernel was built with SCHED_ULE
rrent@freebsd.org
Subject: Re: NFS client performance degradation when SMP enabled
What type of network interface do you have? The Intel 1G (em and igb) were
switched over to the "iflib" framework a few months ago and that could be the
cause.
___
What type of network interface do you have? The Intel 1G (em and igb) were
switched over to the "iflib" framework a few months ago and that could be
the cause.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebs
degradation go away by disabling SMP on the
client.
Here's some elapsed times for kernel builds with everything the same except for
which kernel and SMP enabled/disabled (amd64 client machine).
1 year old kernel, SMP enabled - 100minutes
recent kernel, SMP disabled- 113minutes
recent k
On 08/02/16 05:06, Mateusz Guzik wrote:
> On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote:
>> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
>> reference to mtx_delay causes compilation of kern_mutex.c to fail
>> because KDTRACE_HOOKS m
On Mon, Aug 01, 2016 at 09:49:03PM -0400, Michael Butler wrote:
> In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
> reference to mtx_delay causes compilation of kern_mutex.c to fail
> because KDTRACE_HOOKS may be,
>
Indeed, fixed in r303655.
Thanks f
In the non-SMP case, ADAPTIVE_MUTEXES is not defined and a subsequent
reference to mtx_delay causes compilation of kern_mutex.c to fail
because KDTRACE_HOOKS may be,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
ose boot (before and
after).
Thank you!
On 04/04/2016 19:31, Andriy Gapon wrote:
>
>
> I've just committed new code for detecting SMP (processor and cache) topology
> on
> x86 systems. Please be aware.
>
> If you get any panics or crashes that look like they might be
I've just committed new code for detecting SMP (processor and cache) topology on
x86 systems. Please be aware.
If you get any panics or crashes that look like they might be caused by this
change please send a copy of a report to me.
Another thing to watch is kern.sched.topology_spec.
P
If a custom kernel configuration file removes the SMP option, the kernel
build fails on the implicit declaration of lapic_read_icr_lo on (or
about) line 525 in local_apic.c. It refers to a static function whose
definition is removed when SMP is undefined,
imb
Evening,
I have a Soekris 6501 running i386 11-CURRENT that I had seen panic at
boot when updating this weekend. It'll panic right after the "SMP: AP
CPU #1 Launched" and go into a long loop of __mtx_lock_spin_flags,
i8254_get_timecount, binuptime, _mtx_lock_spin_cookie.
processor is running. To have more interrupts available we
>>> need to start SMP earlier when building a monotolith kernel and not
>>> loading drivers as modules. The driver in question is a network driver
>>> and because it cannot be started after SI_SUB_ROOT_CONF due
re is a limitiation on the number of interrupt vectors available when
> >> > only a single processor is running. To have more interrupts available we
> >> > need to start SMP earlier when building a monotolith kernel and not
> >> > loading drivers as modules
y a single processor is running. To have more interrupts available we
>> > need to start SMP earlier when building a monotolith kernel and not
>> > loading drivers as modules. The driver in question is a network driver
>> > and because it cannot be started after SI_
On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote:
> On 1/5/15 8:18 AM, Hans Petter Selasky wrote:
> > Hi,
> >
> > There is a limitiation on the number of interrupt vectors available when
> > only a single processor is running. To have more interrupts availab
On Tue, Jan 06, 2015 at 09:37:30AM -0500, John Baldwin wrote:
> On 1/5/15 8:18 AM, Hans Petter Selasky wrote:
> > Hi,
> >
> > There is a limitiation on the number of interrupt vectors available when
> > only a single processor is running. To have more interrupts availab
On 01/06/15 15:37, John Baldwin wrote:
We need a lot more work before this is ready. This is one of the goals
of the multipass new-bus stuff. In particular, we have to enumerate
enough devices to bring event timer hardware up so that timer interrupts
work so that tsleep() will actually sleep.
On 1/5/15 8:18 AM, Hans Petter Selasky wrote:
> Hi,
>
> There is a limitiation on the number of interrupt vectors available when
> only a single processor is running. To have more interrupts available we
> need to start SMP earlier when building a monotolith kernel and not
>
interrupt vectors available when
>>> only a single processor is running. To have more interrupts available we
>>> need to start SMP earlier when building a monotolith kernel and not
>>> loading drivers as modules. The driver in question is a network driver
>>> and be
On 01/05/15 14:43, Konstantin Belousov wrote:
On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote:
Hi,
There is a limitiation on the number of interrupt vectors available when
only a single processor is running. To have more interrupts available we
need to start SMP earlier
On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote:
> Hi,
>
> There is a limitiation on the number of interrupt vectors available when
> only a single processor is running. To have more interrupts available we
> need to start SMP earlier when building a monoto
Hi,
There is a limitiation on the number of interrupt vectors available when
only a single processor is running. To have more interrupts available we
need to start SMP earlier when building a monotolith kernel and not
loading drivers as modules. The driver in question is a network driver
and
e but booting from the installed system stops at SMP.
>
> Disabling smp or doing
> #set hint.lapic.[1-3].disabled=1
> makes it boot.
>
> Anyway has any clue what this might be?
>
>
> --
> --
> Johannes Lundberg
> Project leader and lead developer of Mirama OS (pre
Hi
Installing current on a MacBook Air 2013 model from USB memstick (special
build) works fine but booting from the installed system stops at SMP.
Disabling smp or doing
#set hint.lapic.[1-3].disabled=1
makes it boot.
Anyway has any clue what this might be?
--
--
Johannes Lundberg
Project
use debug registers.
Another is that ddb only loads the debug registers for the watchpoint
into the CPU which is executing ddb code, not setting up non-current
processors.
Not touching the first problem for now, I want to fix the second issue,
since as is, hardware watchpoints are useless on SMP
; Another is that ddb only loads the debug registers for the watchpoint
> into the CPU which is executing ddb code, not setting up non-current
> processors.
>
> Not touching the first problem for now, I want to fix the second issue,
> since as is, hardware watchpoints are useless on S
which is executing ddb code, not setting up non-current
processors.
Not touching the first problem for now, I want to fix the second issue,
since as is, hardware watchpoints are useless on SMP. Patch below makes
the stopped processors to load the debug registers after resuming from
the stop handler
Am 03/07/13 16:48, schrieb Gleb Smirnoff:
> On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote:
> O> There is work going on to move the OpenBSD pf(1) towards a more SMP
> O> friendly entity - this reduces CPU load and should raise throughput.
> O>
> O> Are
On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote:
O> There is work going on to move the OpenBSD pf(1) towards a more SMP
O> friendly entity - this reduces CPU load and should raise throughput.
O>
O> Are there any plans for FreeBSD "native" packet filter IPFW2 t
There is work going on to move the OpenBSD pf(1) towards a more SMP
friendly entity - this reduces CPU load and should raise throughput.
Are there any plans for FreeBSD "native" packet filter IPFW2 to gain the
same? Or, to ask it differently, IS ipfw(1), the freeBSD native
packetfilte
Hi,
From: mbsd
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Wed, 20 Jun 2012 22:31:44 +0300
Message-ID: <1340220704.2098.8.camel@localhost>
> Hi developers.
>
> I want help you with your acpi work. I have thinkpad t61.
> Could you write a small to do. Step by step, how
Hi developers.
I want help you with your acpi work. I have thinkpad t61.
Could you write a small to do. Step by step, how tests your patches?
Which information is important for send.
On Wed, 2012-05-16 at 11:31 +0900, Mitsuru IWASAKI wrote:
> Hi,
>
> > First of all, thank you very much for your
Hi,
> > +1. I've really liked to use more than one CPU on my netbook for a while :).
>
> A basic suspend test worked on my netbook. I'll have to see about
> some edgecases I've run into in the past where UP wouldn't resume if
> the system had been sitting for an extensive period of time, etc.
On Fri, May 11, 2012 at 2:01 PM, Garrett Cooper wrote:
> On Fri, May 11, 2012 at 12:56 PM, Adrian Chadd wrote:
>> Thanks so very much for this!
>>
>> I'll try it on my thinkpad T60 this weekend and report back. It
>> unfortunately is running 9.0-RELEASE though - if I have issues, I'll
>> try 9-st
Hi,
> First of all, thank you very much for your work! I wanted to do it
> for very long time but I had no time to actually implement it. :-)
Welcome! I also wanted to do this for very long time but I had no
time and test machines ;)
Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-05-15 03:30:02 -0400, Peter Jeremy wrote:
> I wrote:
>>> Thank you for that. Since I was in the process of upgrading my
>>> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your
>>> RELENG_8 patch on top of r235229.
>>>
>>> Unfortunat
I wrote:
>> Thank you for that. Since I was in the process of upgrading my
>> netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8
>> patch on top of r235229.
>>
>> Unfortunately, the result hasn't been a complete success.
On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI wrote:
>
gt; to have correct suspend/resume method.
>>> http://www.nvidia.com/object/freebsd_archive.html
>>>
>>> Have you try it?
>>
>> Yes, it is running the propietary driver. Everything was done
>> with it loaded. Do you want me to try without the nvidia
somehow explain why
I can resume while working with ttyv1 having X working on ttvy9
(remember, in that case I had to vidcontrol -s 9 < /dev/console to get
my screen back online). I'm just guessing.
Could it be that
Hmmm, it doesn't seem related with my SMP/i38
running the propietary driver. Everything was done with it
> loaded. Do you want me to try without the nvidia binary driver?
Yes, if it doesn't bother you.
Hmmm, it doesn't seem related with my SMP/i386 sleep patches.
Could you try also Uni-processer kernel (w/o SMP and apic from c
Enviat des del meu iTotxo
El 13/05/2012, a les 16:40, Mitsuru IWASAKI va
escriure:
> Hi, Thanks for your report.
>
> From: Gustau Pérez i Querol
> Subject: Re: [CFT] SMP/i386 suspend/resume
> Date: Sun, 13 May 2012 09:57:33 +0200
> Message-ID: <4faf696d.3060...@entel.up
Hi,
From: David Wolfskill
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Sun, 13 May 2012 07:03:02 -0700
Message-ID: <20120513140302.gi13...@albert.catwhisker.org>
> On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote:
> >
> > OK, we need some more inve
Hi, Thanks for your report.
From: Gustau Pérez i Querol
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Sun, 13 May 2012 09:57:33 +0200
Message-ID: <4faf696d.3060...@entel.upc.edu>
> Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit:
> > Hi
> >
> > I've be
On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote:
>
> OK, we need some more investigation on RELENG_8 SMP.
> I think Core 2 Duo can run amd64, would like to confirm
> this problem can be reproduced only on i386 or not.
> Could you try same thing on amd64?
Hi, Thanks for you report.
From: David Wolfskill
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Fri, 11 May 2012 13:22:57 +
Message-ID: <20120511132257.ga96...@freefall.freebsd.org>
> On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote:
> > Hi
> >
>
Hi, Thanks for your report.
From: Peter Jeremy
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Fri, 11 May 2012 21:20:05 +1000
Message-ID: <2012052005.ga87...@server.rulingia.com>
> On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI wrote:
> >I've been working on suspend
Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit:
Hi
I've been working on suspend/resume for SMP/i386 for a week
and created patches against CURRENT, RELENG_9 and RELENG_8
available at:
http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff
http://people.freebs
On Fri, May 11, 2012 at 12:56 PM, Adrian Chadd wrote:
> Thanks so very much for this!
>
> I'll try it on my thinkpad T60 this weekend and report back. It
> unfortunately is running 9.0-RELEASE though - if I have issues, I'll
> try 9-stable on another T60 next week and similarly report back.
+1. I
Thanks so very much for this!
I'll try it on my thinkpad T60 this weekend and report back. It
unfortunately is running 9.0-RELEASE though - if I have issues, I'll
try 9-stable on another T60 next week and similarly report back.
Adrian
___
freebsd-curr
On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote:
> Hi
>
> I've been working on suspend/resume for SMP/i386 for a week
> and created patches against CURRENT, RELENG_9 and RELENG_8
> available at:
>
> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-sus
On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote:
> Hi
>
> I've been working on suspend/resume for SMP/i386 for a week
> and created patches against CURRENT, RELENG_9 and RELENG_8
> available at:
>
> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-sus
On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote:
> Hi
>
> I've been working on suspend/resume for SMP/i386 for a week
> and created patches against CURRENT, RELENG_9 and RELENG_8
> available at:
>
> http://people.freebsd.org/~iwasaki/acpi/i386-SMP-sus
On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI wrote:
>I've been working on suspend/resume for SMP/i386 for a week
>and created patches against CURRENT, RELENG_9 and RELENG_8
>available at:
Thank you for that. Since I was in the process of upgrading my
netbook (Acer Aspire One
Hi
I've been working on suspend/resume for SMP/i386 for a week
and created patches against CURRENT, RELENG_9 and RELENG_8
available at:
http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff
http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511
Hi,
I've included a fix into our ath/hal driver which enforces serialised
register access on AR5416 and later PCI NICs when running on an SMP
system.
This is needed to fix a system hang issue that occurs with multiple
CPUs doing register IO to/from these devices. I don't have a
g a lot of fscking. My FreeBSD 8 based VM, on
the other hand, was quite happy.
After some trial and error, I determined that using the TSC as a timecounter
with the VM in SMP mode was the root cause. If I switch the VM to one vCPU
and run with the TSC, the buildworld runs fine. If I leave it with
reported,
and the filesystem ended up requiring a lot of fscking. My FreeBSD 8
based VM, on the other hand, was quite happy.
After some trial and error, I determined that using the TSC as a
timecounter with the VM in SMP mode was the root cause. If I switch the
VM to one vCPU and run with
On Friday, July 29, 2011 6:08:30 am Andriy Gapon wrote:
>
> This is to account for the recent changes in x86 SMP code:
> http://people.freebsd.org/~avg/hlt_cpus-doc.diff
> Please review. Thank you!
Looks good to me.
--
John Baldwin
___
This is to account for the recent changes in x86 SMP code:
http://people.freebsd.org/~avg/hlt_cpus-doc.diff
Please review. Thank you!
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
On Sat, Jul 16, 2011 at 10:42:22PM -0700, Doug Barton wrote:
> On 07/15/2011 01:40, Marius Strobl wrote:
>
> > The generated config.h and platform.h for sparc64 are these:
> > http://people.freebsd.org/~marius/bind96_config.h
> > http://people.freebsd.org/~marius/bind96_platform.h
>
> Marius,
>
On 07/15/2011 01:40, Marius Strobl wrote:
> The generated config.h and platform.h for sparc64 are these:
> http://people.freebsd.org/~marius/bind96_config.h
> http://people.freebsd.org/~marius/bind96_platform.h
Marius,
Thanks again for all your help on this. During the work to upgrade to
BIND 9.
On Thu, Jul 14, 2011 at 05:31:49PM -0700, Doug Barton wrote:
> On 07/14/2011 16:21, Marius Strobl wrote:
> > On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote:
> >> 2011/7/11 KOT MATPOCKuH :
> Oops, sorry, I forgot to revert the previous patch when test-compiling.
> Please re-
On 07/14/2011 16:21, Marius Strobl wrote:
> On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote:
>> 2011/7/11 KOT MATPOCKuH :
Oops, sorry, I forgot to revert the previous patch when test-compiling.
Please re-fetch sparc64_isc_atomic.h.diff2 and try again.
>>> I started named fro
On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote:
> 2011/7/11 KOT MATPOCKuH :
> >> Oops, sorry, I forgot to revert the previous patch when test-compiling.
> >> Please re-fetch sparc64_isc_atomic.h.diff2 and try again.
> > I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 M
2011/7/11 KOT MATPOCKuH :
>> Oops, sorry, I forgot to revert the previous patch when test-compiling.
>> Please re-fetch sparc64_isc_atomic.h.diff2 and try again.
> I started named from ports (dns/bind96) at Sat Jul 9 10:08:41 MSD,
> and it worked properly till Sun Jul 10 22:25:41 MSD.
> At 22:25:4
2011/7/8 Marius Strobl :
> In order to have a result which can be compared with the base BIND.
> Whether bind98 works or works without the ISC atomic operations says
> nothing about the bind96 port or the base version.
Okey...
> Oops, sorry, I forgot to revert the previous patch when test-compili
On Fri, Jul 08, 2011 at 11:17:20PM +0400, KOT MATPOCKuH wrote:
> 2011/7/8 Marius Strobl :
>
> > Please try the following:
> > a) Instead of the base BIND use the dns/bind96 port. The native build
> > ? of the latter defaults to not using the ISC atomic implementation
> > ? on sparc64 (and arm) and
2011/7/8 Marius Strobl :
> Please try the following:
> a) Instead of the base BIND use the dns/bind96 port. The native build
> of the latter defaults to not using the ISC atomic implementation
> on sparc64 (and arm) and should properly enable the alternative. I
> can at least start named fro
On Fri, Jul 08, 2011 at 03:47:08PM +0400, KOT MATPOCKuH wrote:
> 2011/7/7 Marius Strobl :
> > That's not the patch I was referring to. I did a second one which just
> > entirely disables the use of atomic operations on sparc64:
> > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff
>
2011/7/7 Marius Strobl :
> That's not the patch I was referring to. I did a second one which just
> entirely disables the use of atomic operations on sparc64:
> http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff
Omg. I'm sorry.
I applied this patch and restarted named, but named cras
On Thu, Jul 07, 2011 at 03:44:32PM +0400, KOT MATPOCKuH wrote:
> 2011/7/7 Marius Strobl :
> > On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote:
> >> I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3,
> >> but problem is still exists:
> >> 07-Jul-2011 13:24:22.765 gene
2011/7/7 Marius Strobl :
> On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote:
>> I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3,
>> but problem is still exists:
>> 07-Jul-2011 13:24:22.765 general:
>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622
On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote:
> I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3,
> but problem is still exists:
> 07-Jul-2011 13:24:22.765 general:
> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622:
> REQUIRE(prev > 0) failed
>
I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3,
but problem is still exists:
07-Jul-2011 13:24:22.765 general:
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622:
REQUIRE(prev > 0) failed
07-Jul-2011 13:24:22.781 general: exiting (due to assertion failure)
How c
On Wed, Jul 06, 2011 at 11:55:15AM +0200, Marius Strobl wrote:
> On Tue, Jul 05, 2011 at 05:55:09PM -0700, Doug Barton wrote:
> > On 06/28/2011 08:58, Marius Strobl wrote:
> > >Uhm, we once fixed a problem in the MD atomic implementation which
> > >still seems to present in the ISC copy. Could you
On Tue, Jul 05, 2011 at 05:55:09PM -0700, Doug Barton wrote:
> On 06/28/2011 08:58, Marius Strobl wrote:
> >Uhm, we once fixed a problem in the MD atomic implementation which
> >still seems to present in the ISC copy. Could you please test whether
> >the following patch makes a difference?
> >http:
On 06/28/2011 08:58, Marius Strobl wrote:
Uhm, we once fixed a problem in the MD atomic implementation which
still seems to present in the ISC copy. Could you please test whether
the following patch makes a difference?
http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff
I haven't seen a
On 06/29/2011 06:41, Marius Strobl wrote:
On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote:
2011/6/29 KOT MATPOCKuH:
I'm got a problem with named on FreeBSD-CURRENT/sparc64.
Up to 5 times a day it crashes with these messages:
27-Jun-2011 03:42:14.384 general:
/usr/src/lib/bind/dns/
On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote:
> 2011/6/29 KOT MATPOCKuH :
> >>> I'm got a problem with named on FreeBSD-CURRENT/sparc64.
> >>> Up to 5 times a day it crashes with these messages:
> >>> 27-Jun-2011 03:42:14.384 general:
> >>> /usr/src/lib/bind/dns/../../../contrib/bi
2011/6/29 KOT MATPOCKuH :
>>> I'm got a problem with named on FreeBSD-CURRENT/sparc64.
>>> Up to 5 times a day it crashes with these messages:
>>> 27-Jun-2011 03:42:14.384 general:
>>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614:
>>> REQUIRE(prev > 0) failed
>>> 27-Jun-2011 03
2011/6/28 Marius Strobl :
>> I'm got a problem with named on FreeBSD-CURRENT/sparc64.
>> Up to 5 times a day it crashes with these messages:
>> 27-Jun-2011 03:42:14.384 general:
>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614:
>> REQUIRE(prev > 0) failed
>> 27-Jun-2011 03:42:1
d9/lib/dns/rbtdb.c:1614:
> REQUIRE(prev > 0) failed
> 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure)
>
> The problem is still in latest system's bind:
> # named -v
> BIND 9.6.-ESV-R4-P1
>
> This problem exists only on SMP sparc64 system. On my an
(due to assertion failure)
The problem is still in latest system's bind:
# named -v
BIND 9.6.-ESV-R4-P1
This problem exists only on SMP sparc64 system. On my another sparc64,
with 1 processor, I does not have this problem.
I found a some similar problems on alpha and IA64, which was related
to
On Thu, Mar 11, 2010 at 09:04:40AM -0800, David Wolfskill wrote:
> My build machine (dmesg attached) is a dual CPU, single-core box; my
> laptop is a single CPU, single-core box. I track head on each daily;
> while the build machine has been locking up during the transition to
> multi-user mode si
M) CPU 3.60GHz (3614.54-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf41 Stepping = 1
Features=0xbfebfbff
Features2=0x659d
AMD Features=0x2010
TSC: P-state invariant
real memory = 2147483648 (2048 MB)
avail memory = 2086187008 (1989 MB)
ACPI APIC Table:
FreeBSD/SMP: Multipr
On Sat, Feb 20, 2010 at 4:19 PM, Attilio Rao wrote:
> 2010/1/27 Brandon Gooch :
>> The machine, a Dell Optiplex 755, has been locking up recently. The
>> situation usually occurs while using VirtualBox (running a 64-bit
>> Windows 7 instance) and doing anything else in another xterm (such as
>> re
2010/2/28 Andrew Brampton :
> Hello,
>
> When many interrupts are firing on my amd64 SMP machine, and a panic
> occurs, dump will fail with the error "Attempt to write outside dump
> device boundaries". This problem has been discussed before[1][2], and
> I even fill
Hello,
When many interrupts are firing on my amd64 SMP machine, and a panic
occurs, dump will fail with the error "Attempt to write outside dump
device boundaries". This problem has been discussed before[1][2], and
I even filled a PR about it last year[3].
>From what I understand th
1 - 100 of 1021 matches
Mail list logo
