David Chisnall writes:
[...]
> libcxxrt and libc++ are now in contrib and building with the base
> system, but are not used by anything (and are only built if you set
> WITH_LIBCPLUSPLUS=yes when building world, not by default). If you
> want to test some code with the new stack, you need to bui
On Sun Dec 18 11, Andrey Chernov wrote:
> On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > I observe ULE interactivity slowness even on single core machine
> > (Pentium
>
On Sun Dec 18 11, Alexander Best wrote:
> On Sun Dec 18 11, Andrey Chernov wrote:
> > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > > I observe ULE interactivity slo
On 18/12/2011 10:34, Adrian Chadd wrote:
I applaud reppie for trying to make it as easy as possible for people
to use KTR to provide scheduler traces for him to go digging with, so
please, if you have these issues and you can absolutely reproduce
them, please follow his instructions and work with
On 12/18/11 02:45, Alexander Kabaev wrote:
> On Sun, 18 Dec 2011 01:09:00 +0100
> "O. Hartmann" wrote:
>
>> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
>> panic: sleeping thread
>> cpuid = 0
>>
>> PID 16 is always USB on my box.
>
> You really need to give us a backtrace when
On 12/18/11 03:37, Bruce Cran wrote:
> On 13/12/2011 09:00, Andrey Chernov wrote:
>> I observe ULE interactivity slowness even on single core machine
>> (Pentium 4) in very visible places, like 'ps ax' output stucks in the
>> middle by ~1 second. When I switch back to SHED_4BSD, all slowness is
>>
TB --- 2011-12-18 15:26:46 - tinderbox 2.8 running on freebsd-current.sentex.ca
TB --- 2011-12-18 15:26:46 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2011-12-18 15:26:46 - cleaning the object tree
TB --- 2011-12-18 15:26:57 - cvsupping the source tree
TB --- 2011-12-18 15:26:57 - /usr
Alexander,
On Sat, Dec 17, 2011 at 03:08:43PM +0100, Alexander Leidinger wrote:
A> we never had a kernel part in the list. Reinstallkernel is not a valid
target after updating the sources. The renaming will only take effekt after
updating. And we already hat issues because the list was too lon
FreeBSD Tinderbox writes:
> In file included from /src/sys/dev/e1000/if_em.c:400:
> /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync':
> /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *'
> pointer
> /src/sys/dev/netmap/if_em_netmap.h:332: error: request for
Hi,
What Attilllo and others need are KTR traces in the most stripped down
example of interactive-busting workload you can find.
Eg: if you're doing 32 concurrent buildworlds and trying to test
interactivity - fine, but that's going to result in a lot of KTR
stuff.
If you can reproduce it using a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Any ideas why courier-authdaemon is now reporting ..
authdaemond: in openpam_dynamic(): No error: 0
authdaemond: in openpam_load_module(): no pam_unix.so found
I've recompiled libpam and courier from scratch :-(
imb
-BEGIN PGP SIGNATURE-
On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Any ideas why courier-authdaemon is now reporting ..
>
> authdaemond: in openpam_dynamic(): No error: 0
> authdaemond: in openpam_load_module(): no pam_unix.so found
>
> I've recompiled li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/18/11 15:20, Garrett Cooper wrote:
> On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Any ideas why courier-authdaemon is now reporting ..
>>
>> authdaemond: in openpam_dynamic()
On Wed, 14 Dec 2011, Ivan Klymenko wrote:
?? Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker ??:
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
If the algorithm ULE does not contain problems - it means the
problem has Core2Duo, or in a piece of code that uses the ULE
Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel
:
On 12/15/2011 02:48 AM, Michael Ross wrote:
Anyway these tests were performed on different hardware, FWIW.
And with different filesystems, different compilers, different GUIs...
No, the same hardware was used for each OS.
The pictur
On 12/15/2011 04:41 AM, Michael Ross wrote:
Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel
:
On 12/15/2011 02:48 AM, Michael Ross wrote:
Anyway these tests were performed on different hardware, FWIW.
And with different filesystems, different compilers, different GUIs...
No, the same
Am 15.12.2011, 11:55 Uhr, schrieb Michael Larabel
:
On 12/15/2011 04:41 AM, Michael Ross wrote:
Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel
:
On 12/15/2011 02:48 AM, Michael Ross wrote:
Anyway these tests were performed on different hardware, FWIW.
And with different filesystems,
Hi, all,
Am 15.12.2011 um 12:18 schrieb Michael Ross:
> Following Steven Hartlands' suggestion,
> from one of my machines:
>
> /usr/ports/sysutils/dmidecode/#sysctl -a | egrep "hw.vendor|hw.product"
>
> /usr/ports/sysutils/dmidecode/#dmidecode -t 2
> # dmidecode 2.11
> SMBIOS 2.6 present.
>
> H
On Thu, Dec 15, 2011 at 04:55:16AM -0600, Michael Larabel wrote:
> On 12/15/2011 04:41 AM, Michael Ross wrote:
> >Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel
> >:
> >
> >>On 12/15/2011 02:48 AM, Michael Ross wrote:
> >
> >>>Anyway these tests were performed on different hardware, FWIW.
> >>>A
On Thu, Dec 15, 2011 at 05:32:47AM -0700, Samuel J. Greear wrote:
> > Well, the only way it's going to get fixed is if someone sits down,
> > replicates it, and starts to document exactly what it is that these
> > benchmarks are/aren't doing.
> >
>
> I think you will find that investigation is lar
On 12/15/2011 08:26 AM, Sergey Matveychuk wrote:
15.12.2011 17:36, Michael Larabel пишет:
On 12/15/2011 07:25 AM, Stefan Esser wrote:
Am 15.12.2011 11:10, schrieb Michael Larabel:
No, the same hardware was used for each OS.
In terms of the software, the stock software stack for each OS was
u
On Thu, 15 Dec 2011, Pieter de Goeje spaketh thusly:
-}Detailed results here:
-}http://openbenchmarking.org/result/1112113-AR-ORACLELIN37
LOL! Pretty much 2 entirely different systems, even running different screen
resolutions. Tnx for this link.
-}
-}As usual, the phoronix benchmarks are ver
> Well, the only way it's going to get fixed is if someone sits down,
> replicates it, and starts to document exactly what it is that these
> benchmarks are/aren't doing.
>
I think you will find that investigation is largely a waste of time,
because not only are some of these benchmarks just downr
On 12/15/2011 07:25 AM, Stefan Esser wrote:
Am 15.12.2011 11:10, schrieb Michael Larabel:
No, the same hardware was used for each OS.
In terms of the software, the stock software stack for each OS was used.
Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with
journaling enabled) s
On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
> 2011/12/13 Jeremy Chadwick :
> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> > issue. And yes, there are cases where SCHED_ULE shows much
Thanks.
My request for the person documenting the tunings also runs = the
benchmark to ensure expected behaviour.
The installation, execut= ion and comparison against the benchmarks in
the article is fairly simple.<= br>
Note that some tuning may not be relevant or recommended (i
On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> On 13/12/2011 09:00, Andrey Chernov wrote:
> > I observe ULE interactivity slowness even on single core machine (Pentium
> > 4) in very visible places, like 'ps ax' output stucks in the middle by ~1
> > second. When I switch back to SHED_4
The trouble is that there's lots of anecdotal evidence, but noone's
really gone digging deep into _their_ example of why it's broken. The
developers who know this stuff don't see anything wrong. That hints to
me it may be something a little more creepy - as an example, the
interplay between netisr/
Michael Butler writes:
> Any ideas why courier-authdaemon is now reporting ..
>
> authdaemond: in openpam_dynamic(): No error: 0
> authdaemond: in openpam_load_module(): no pam_unix.so found
>
> I've recompiled libpam and courier from scratch :-(
Can you ktrace courier-authdaemon?
# env LD_UTRAC
On 18. Dec 2011, at 18:07 , Dag-Erling Smørgrav wrote:
> FreeBSD Tinderbox writes:
>> In file included from /src/sys/dev/e1000/if_em.c:400:
>> /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync':
>> /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *'
>> pointe
30 matches
Mail list logo
