On 16.08.2011 00:13, Joe Schaefer wrote:
On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin<m...@freebsd.org>  wrote:
On 15.08.2011 23:57, Joe Schaefer wrote:

On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin<m...@freebsd.org>    wrote:

On 15.08.2011 22:18, Joe Schaefer wrote:

On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer<joes...@gmail.com>
  wrote:

On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon<a...@freebsd.org>
  wrote:

on 13/08/2011 20:16 Joe Schaefer said the following:

Brand new machine with a Phenom II X6 1100T and under chronic load
the clock will stop running periodically until the machine eventually
completely
freezes.  Note: during these stalls the kernel is still running, the
machine is still
mostly responsive, it's just that the clock is frozen in time.

I've disabled Turbo mode in the bios and toyed with just about every
other setting but nothing seems to resolve this problem.  Based on
the
behavior
of the machine (just making buildworld will eventually kill it,
upping
the -j flag
just kills it faster), I'm guessing it has something to do with the
Digi+ VRM features
but again nothing I've tried modifying in the bios seems to help.

I've tried both 8.2-RELEASE and FreeBSD 9 (head).  Running head now
with
a dtrace enabled kernel.

Suggestions?

On head, start with checking what source is used for driving clocks:
sysctl kern.eventtimer

% sysctl kern.eventtimer                                  [master]
kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400)
i8254(100) RTC(0)
kern.eventtimer.et.LAPIC.flags: 15
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.quality: 400
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.quality: 450
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.quality: 450
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.periodic: 0
kern.eventtimer.timer: HPET

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Changing this to "i8254" seems to have resolved the stalls.
I'm running buildworld -j12 without issue.  More than willing
to test out a patch or two against head if anyone's still
interested, otherwise I've thrown the change into loader.conf
and will move along quietly.

8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET
timer driver. That makes me think it is strange at least. Can you try
also
LAPIC timer and do alike experiments with kern.timeocunter?

My problems with 8.2-RELEASE may have been network based.  I don't recall
precisely if the clock was stalling there, my guess is no based on
what you wrote.

I'll test LAPIC next ... so far so good.  Just so I'm clear, you'd
like me to tweak
kern.timecounter.hardware as well?  (Currently it's HPET).

Yes. Instead. Ticking clock depends on both timecounter and eventtimer.

Haven't found a combination that hangs my machine other than with the
eventtimer at HPET.

I mean trying eventtimer HPET and different timecounters.

If changing timecounter won't help, try please this patch:

--- acpi_hpet.c.prev    2010-12-25 11:28:45.000000000 +0200
+++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300
@@ -190,7 +190,7 @@ restart:
                bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num),
                    t->next);
        }
-       if (fdiv < 5000) {
+       if (1 || fdiv < 5000) {
                bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num));
                now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER);

--
Alexander Motin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to