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.
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 wok
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 that the
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 wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks
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 wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device pollin
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 4xi
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 wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device pollin
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 wrote:
> >>
> >>>doh, running kernel wasn't as GENERIC as I thought it was, looks like
> >>>device polling
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 one
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 :
=-=-=-=-=-=-=-=-=-=-=-=-=-
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 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, exactl
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
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
> On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden 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,0
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 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: err
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 [-Werror,-Wc
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden 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 this a known is
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
Re
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"
To: "freeBSD-CURRENT Mailing List"
Se
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 tim
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--
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
Davide Italiano wrote:
On Nov 4, 2012 10:40 PM, "Joe Holden" wrote:
Davide Italiano wrote:
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote:
Hi guys,
Has some default changed between 9.1-RC2 and HEAD?
On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
(GENERIC) I see
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
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 w
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
26 matches
Mail list logo
