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/mail
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 ucode.
On Fri, Oct 20, 2017 at 3:52 PM, Michael Butler <i...@protected-networks.net>
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
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 in C99
[-Werror
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
[-Wunneeded-internal
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
>>
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
e 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_ULE94minutes
- 1yr old kernel, no SMP, SCHED_ULE 111minutes
- recent kernel, SMP, SCHED_4BSD 104mi
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 s
of 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
lem
Cc: freebsd-current@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 cou
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
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 kernel
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
verbose 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 c
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.
Please
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. An abbreviated
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
loading drivers as modules
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 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 available we
need to start SMP earlier
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 available we
need to start SMP earlier when
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 to PXE
support I see no other option than to move SI_SUB_SMP
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 because it cannot be started after SI_SUB_ROOT_CONF due
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 to PXE
support I see no other option than to move SI_SUB_SMP earlier.
Suggested patch
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
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
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 monotolith kernel
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 to PXE
support I see no other option than to move
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 (previously Viking OS)
BRILLIANTSERVICE CO., LTD.
My blog http
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
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. Patch below makes
the stopped
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
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
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
packetfilter, already SMP
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 to gain the
O same? Or, to ask
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 there any plans for FreeBSD native
Hi,
From: mbsd m...@isgroup.com.ua
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 tests
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 yaneg...@gmail.com wrote:
On Fri, May 11, 2012 at 12:56 PM, Adrian Chadd adr...@freebsd.org 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
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
-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.
Unfortunately, the result
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)
back online). I'm just guessing.
Could it be that
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 config
file) without my patches?
I tried smp disabled on boot (kern.smp.disabled=1) and failed the
same way
! I wanted to do it
for very long time but I had no time to actually implement it. :-)
Yes, if it doesn't bother you. Hmmm, it doesn't seem related with
my SMP/i386 sleep patches.
I know for sure it is not related to your patches. In fact, we cannot
resume most NVIDIA controllers without NVIDIA
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.freebsd.org
Hi, Thanks for your report.
From: Peter Jeremy pe...@rulingia.com
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 iwas...@jp.freebsd.org wrote:
I've been
Hi, Thanks for you report.
From: David Wolfskill d...@freebsd.org
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
I've been working
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?
Well, that will require
Hi, Thanks for your report.
From: Gustau Pérez i Querol gpe...@entel.upc.edu
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 been working on suspend
Hi,
From: David Wolfskill da...@catwhisker.org
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 investigation
Enviat des del meu iTotxo
El 13/05/2012, a les 16:40, Mitsuru IWASAKI iwas...@jp.freebsd.org va
escriure:
Hi, Thanks for your report.
From: Gustau Pérez i Querol gpe...@entel.upc.edu
Subject: Re: [CFT] SMP/i386 suspend/resume
Date: Sun, 13 May 2012 09:57:33 +0200
Message-ID: 4faf696d
/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 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
On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI iwas...@jp.freebsd.org 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
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-suspend-CURRENT-20120511.diff
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-suspend-CURRENT-20120511.diff
http
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-suspend-CURRENT-20120511.diff
http
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
___
On Fri, May 11, 2012 at 12:56 PM, Adrian Chadd adr...@freebsd.org 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
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.diff
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 any further
. 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 two vCPUs
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
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 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
___
freebsd-current
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,
Thanks
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.8
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 matpoc...@gmail.com:
Oops, sorry, I forgot to revert the previous patch when test-compiling.
Please
On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote:
2011/7/11 KOT MATPOCKuH matpoc...@gmail.com:
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
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 matpoc...@gmail.com:
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
2011/7/11 KOT MATPOCKuH matpoc...@gmail.com:
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
2011/7/8 Marius Strobl mar...@alchemy.franken.de:
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
2011/7/7 Marius Strobl mar...@alchemy.franken.de:
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
On Fri, Jul 08, 2011 at 03:47:08PM +0400, KOT MATPOCKuH wrote:
2011/7/7 Marius Strobl mar...@alchemy.franken.de:
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:
2011/7/8 Marius Strobl mar...@alchemy.franken.de:
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
On Fri, Jul 08, 2011 at 11:17:20PM +0400, KOT MATPOCKuH wrote:
2011/7/8 Marius Strobl mar...@alchemy.franken.de:
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
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
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
2011/7/7 Marius Strobl mar...@alchemy.franken.de:
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:
On Thu, Jul 07, 2011 at 03:44:32PM +0400, KOT MATPOCKuH wrote:
2011/7/7 Marius Strobl mar...@alchemy.franken.de:
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
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?
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 please
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
2011/6/28 Marius Strobl mar...@alchemy.franken.de:
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
2011/6/29 KOT MATPOCKuH matpoc...@gmail.com:
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
On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote:
2011/6/29 KOT MATPOCKuH matpoc...@gmail.com:
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:
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 MATPOCKuHmatpoc...@gmail.com:
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:
(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 another sparc64,
with 1 processor, I does not have this problem.
I found
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 problems
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 since
= 2147483648 (2048 MB)
avail memory = 2086187008 (1989 MB)
ACPI APIC Table: PTLTD APIC
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 6
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version
On Sat, Feb 20, 2010 at 4:19 PM, Attilio Rao atti...@freebsd.org wrote:
2010/1/27 Brandon Gooch jamesbrandongo...@gmail.com:
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
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 the reason
2010/2/28 Andrew Brampton brampton+free...@gmail.com:
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
1 - 100 of 933 matches
Mail list logo
