on 05/11/2012 04:41 David Xu said the following:
Another problem I remembered is that a thread on runqueue may be starved
because ULE treats a sleeping thread and a thread waiting on runqueue
differently. If a thread has slept for a while, after it is woken up,
its priority is boosted, but for
On 05.11.2012 02:39, Manfred Antar wrote:
At 01:57 PM 11/4/2012, you wrote:
On 04.11.2012 21:15, Andreas Tobler wrote:
On 04.11.12 14:57, Andre Oppermann wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar
Le dimanche 4 novembre 2012, Alexander Leidinger a écrit :
The machine has 12 MB RAM (no swap configured), after nearly a day
uptime it looks like this:
---snip---
Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free
ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M
Davide Italiano wrote:
On Nov 4, 2012 10:40 PM, Joe Holden li...@rewt.org.uk wrote:
Davide Italiano wrote:
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden li...@rewt.org.uk wrote:
Hi guys,
Has some default changed between 9.1-RC2 and HEAD?
On identical machines, one with 9.1-RC2 and one with
Le lundi 5 novembre 2012, Olivier Smedts a écrit :
Le dimanche 4 novembre 2012, Alexander Leidinger a écrit :
The machine has 12 MB RAM (no swap configured), after nearly a day
uptime it looks like this:
---snip---
Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free
ARC:
Le lundi 5 novembre 2012, Olivier Smedts a écrit :
Le lundi 5 novembre 2012, Olivier Smedts a écrit :
Le dimanche 4 novembre 2012, Alexander Leidinger a écrit :
The machine has 12 MB RAM (no swap configured), after nearly a day
uptime it looks like this:
---snip---
Mem: 348M Active,
I've already posted this to freebsd-fs@ but still have no idea as to why
the below has happened.
On 10/30/12 09:08, Paul Wootton wrote:
Hi,
I have had lots of bad luck with SATA drives and have had them fail on
me far too often. Started with a 3 drive RAIDZ and lost 2 drives at
the same
Yes RAIDZ2 should enable a 2 drive failure without the array faulting so
something strange is going on there somewhere.
Silly question, what size drives and what driver are you using?
Regards
Steve
- Original Message -
From: Paul Wootton paul-free...@fletchermoorland.co.uk
To:
On 11/05/12 10:49, Steven Hartland wrote:
Yes RAIDZ2 should enable a 2 drive failure without the array faulting so
something strange is going on there somewhere.
That was my thought, but I dont know what or why.
Silly question, what size drives and what driver are you using?
See below
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device polling not only breaks dynamic ticks but also reduces rx ability
significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without
Is
While building world as of today, I receive this error:
In file included from /usr/src/usr.bin/less/../../contrib/less/main.c:16:
In file included from /usr/src/usr.bin/less/../../contrib/less/less.h:29:
/usr/src/usr.bin/less/../less/defines.h:188:25: error: '/*' within block
comment
On 2012-11-05 14:17, O. Hartmann wrote:
While building world as of today, I receive this error:
In file included from /usr/src/usr.bin/less/../../contrib/less/main.c:16:
In file included from /usr/src/usr.bin/less/../../contrib/less/less.h:29:
/usr/src/usr.bin/less/../less/defines.h:188:25:
Hi.
Full interrupt rate on some CPU means that your system is not idle, but
running some process. Another possibility is that you have DUMMYNET
compiled into your kernel, which tends to schedule callout for every HZ
tick, effectively blocking skipping interrupts for one of CPUs.
Check 'top
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device polling not only breaks dynamic ticks but also reduces rx ability
significantly,
Dears,
Since FreeBSD 8.0, there is some changes about routing table, in particular
the IPv4 'link-local' route.
In my case, i have this config: em0 192.168.0.1 / 24
In FreeBSD 8, if I run 'route get 192.168.0.0', it tell me :
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
route
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device polling not only breaks dynamic ticks but also reduces rx ability
On 2012-11-05 17:21, Alexandre Martins wrote:
Since FreeBSD 8.0, there is some changes about routing table, in particular
the IPv4 'link-local' route.
In my case, i have this config: em0 192.168.0.1 / 24
In FreeBSD 8, if I run 'route get 192.168.0.0', it tell me :
Alexander Motin wrote:
Hi.
Full interrupt rate on some CPU means that your system is not idle, but
running some process. Another possibility is that you have DUMMYNET
compiled into your kernel, which tends to schedule callout for every HZ
tick, effectively blocking skipping interrupts for
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device polling
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks
Joe Holden wrote:
It looks like the device polling is what was causing it, once I'd
removed that from kernconf it returned to normal - full interupt rate is
ok though if I can increase the rate to a decent level
FWIW, this is how my igb(4) system is tuned and with PF, it's able
to fill 4xigb
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks
Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote:
doh, running kernel wasn't as GENERIC as I
(r242624)
@@ -24,6 +24,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10
disable the most expensive debugging functionality run
ln -s 'abort:false,junk:false' /etc/malloc.conf.)
+20121105:
+ On i386 and amd64 systems WITH_CLANG_IS_CC is now the default.
+ This means
On 2012/11/05 17:13, Andriy Gapon wrote:
on 05/11/2012 04:41 David Xu said the following:
Another problem I remembered is that a thread on runqueue may be starved
because ULE treats a sleeping thread and a thread waiting on runqueue
differently. If a thread has slept for a while, after it is
On Mon, Nov 05, 2012 at 01:52:33PM -0600, Brooks Davis wrote:
B I've made clang the default on x86 systems. There will probably be a
B few bumps as we work out the last kinks including a ABI issue for i386
B system libraries, but the transition is expected to be fairly smooth for
B most users.
B
26 matches
Mail list logo
