On 26 January 2013 02:15, Andriy Gapon a...@freebsd.org 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
on 27/01/2013 19:27 Adrian Chadd said the following:
On 26 January 2013 02:15, Andriy Gapon a...@freebsd.org 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
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 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;HLT
On 23 January 2013 06:58, Andriy Gapon a...@freebsd.org 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
On Jan 22, 2013, at 2:40 AM, Adrian Chadd adr...@freebsd.org wrote:
On Jan 21, 2013, at 4:33 AM, Daniel Braniss da...@cs.huji.ac.il 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
On Jan 22, 2013, at 2:40 AM, Adrian Chadd adr...@freebsd.org wrote:
On Jan 21, 2013, at 4:33 AM, Daniel Braniss da...@cs.huji.ac.il 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
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
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 wait
Thus spake Daniel Braniss da...@cs.huji.ac.il:
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
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
On 01/22/13 07:27, Julian Stecklina wrote:
Thus spake Daniel Braniss da...@cs.huji.ac.il:
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
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
After many trials (and errors), here are some facts:
host: DELL PowerEdge R710, 16GB,
mfi0: Dell PERC H700 Integrated
mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal
mfi1: Dell PERC 6
mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is
optimal
we
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 da...@cs.huji.ac.il wrote:
After many trials (and errors), here are some
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 931
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: Dell PERC H700 Integrated
mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal
mfi1: Dell PERC 6
mfid1: 12393472MB
...
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 to
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
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
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
21 matches
Mail list logo
