on 27/01/2013 19:27 Adrian Chadd said the following:
> On 26 January 2013 02:15, Andriy Gapon wrote:
>> on 23/01/2013 18:20 Adrian Chadd said the following:
>>> It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be
>>> a quirk of the older generation celeron hardware - in which cas
On 26 January 2013 02:15, Andriy Gapon wrote:
> on 23/01/2013 18:20 Adrian Chadd said the following:
>> It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be
>> a quirk of the older generation celeron hardware - in which case, we
>> need to tell the user somehow..
>
> This is not s
on 23/01/2013 18:20 Adrian Chadd said the following:
> It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be
> a quirk of the older generation celeron hardware - in which case, we
> need to tell the user somehow..
This is not software related at all. It's the hardware feature (or
> On Jan 22, 2013, at 2:40 AM, Adrian Chadd wrote:>
> > On Jan 21, 2013, at 4:33 AM, Daniel Braniss wrote:
> >
> >> host: DELL PowerEdge R710, 16GB,
>
> I administer a Dell PowerEdge R710 and I've been seeing the exact same
> =thing. It's currently running FreeBSD 9.0-STABLE #0 r236355. It h
On Jan 22, 2013, at 2:40 AM, Adrian Chadd wrote:
> On Jan 21, 2013, at 4:33 AM, Daniel Braniss wrote:
>
>> host: DELL PowerEdge R710, 16GB,
I administer a Dell PowerEdge R710 and I've been seeing the exact same thing.
It's currently running FreeBSD 9.0-STABLE #0 r236355. It has a ZFS pool wh
On 23 January 2013 06:58, Andriy Gapon wrote:
> I don't think that this is true of x86 hardware in general.
> You might have hit some limitation or a quirk or a bug or an erratum for some
> particular hardware.
>
> E.g. a chipset on this machine has a bit described as such:
> "Set to 1 to skip th
on 22/01/2013 20:42 Adrian Chadd said the following:
> Hi!
>
> As I said before, the problem with non-HLT loops with event-timer in
> -9 and -head is that it calls the idle function inside a critical
> section (critical_enter and critical_exit) which blocks interrupts
> from occuring.
>
> The EI;
Hi!
As I said before, the problem with non-HLT loops with event-timer in
-9 and -head is that it calls the idle function inside a critical
section (critical_enter and critical_exit) which blocks interrupts
from occuring.
The EI;HLT instruction pair on i386/amd64 atomically and correctly
handles t
On 01/22/13 07:27, Julian Stecklina wrote:
Thus spake Daniel Braniss :
In the meantime here is some info:
Intel(R) Xeon(R) CPU E5645: running with no problems
LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0)
Intel(R) Xeon(R) CPU X5550: this is the problematic, at leas
On Tue, Jan 22, 2013 at 7:27 AM, Julian Stecklina <
jstec...@os.inf.tu-dresden.de> wrote:
> Does anyone know why the LAPIC is given a lower priority than HPET in
> this case? If you have an LAPIC, it should always be prefered to HPET,
> unless something is seriously wrong with it...
>
On many pro
Thus spake Daniel Braniss :
> In the meantime here is some info:
> Intel(R) Xeon(R) CPU E5645: running with no problems
> LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0)
>
> Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment
> HPET(450) HPET1(4
> Daniel,
>
> Have you run tests with the machdep.idle value changed, and fiddling
> kern.eventtimer.periodic / kern.eventtimer.idletick ?
Adrian,
not yet, for several reasons:
1- as I explained, I can't realy force the problem, it happens when we run some
zfs scripts, like mirror, but have to w
Daniel,
Have you run tests with the machdep.idle value changed, and fiddling
kern.eventtimer.periodic / kern.eventtimer.idletick ?
adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscri
> I still firmly believe the ACPI event timer code is racy, and what we
> may be seeing here is the fallout from that.
>
> It's very possible that we're missing interrupts here - the new
> eventtimer code that made it into 9.x puts the halt behind a critical
> section, with interrupts disabled. Th
I still firmly believe the ACPI event timer code is racy, and what we
may be seeing here is the fallout from that.
It's very possible that we're missing interrupts here - the new
eventtimer code that made it into 9.x puts the halt behind a critical
section, with interrupts disabled. The only platf
On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote:
> ...
> >
> > What's the output of sysctl kern.eventtimer?
>
> kern.eventtimer.periodic is 0
>
> > Does the bad behavior
> > change if you set kern.eventimer.periodic=1?
> >
>
> setting kern
...
>
> What's the output of sysctl kern.eventtimer?
kern.eventtimer.periodic is 0
> Does the bad behavior
> change if you set kern.eventimer.periodic=1?
>
setting kern.eventtimer.timer=LAPIC
instead of the default HPET made the missing cpu timers
On Mon, 2013-01-21 at 13:33 +0200, Daniel Braniss wrote:
> After many trials (and errors), here are some facts:
>
> host: DELL PowerEdge R710, 16GB,
> mfi0:
> mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal
> mfi1:
> mfid1: 12393472MB (25381830656 sectors) RAID volume '
> Hi,
>
> Try experimenting with kern.eventtimer.periodic and kern.eventtimer.idletick.
>
can you give/point to some info about this?
btw, I just noticed that on this hardware I get:
9.1-STABLE:
> vmstat -i
interrupt total rate
irq3: uart1
Hi,
Try experimenting with kern.eventtimer.periodic and kern.eventtimer.idletick.
If this fixes it for you, please file a PR with all the relevant details.
Thanks!
Adrian
On 21 January 2013 03:33, Daniel Braniss wrote:
> After many trials (and errors), here are some facts:
>
> host: DELL
After many trials (and errors), here are some facts:
host: DELL PowerEdge R710, 16GB,
mfi0:
mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal
mfi1:
mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is
optimal
we have NO problems with FreeBSD-8.3-STABL
21 matches
Mail list logo
