Re: Clock stalls on Sabertooth 990FX

2011-08-16 Thread ambrosehuang ambrose 
2011/8/16 Joe Schaefer joes...@gmail.com

 FWIW here's a patch I needed to get buildworld to complete against head
 (as of today):

 Index: secure/libexec/ssh-keysign/Makefile
 ===
 --- secure/libexec/ssh-keysign/Makefile (revision 224899)
 +++ secure/libexec/ssh-keysign/Makefile (working copy)
 @@ -1,7 +1,7 @@
  # $FreeBSD$

  PROG=  ssh-keysign
 -SRCS=  ssh-keysign.c readconf.c roaming_dummy.c
 +SRCS=  ssh-keysign.c buffer.c readconf.c roaming_dummy.c
  MAN=   ssh-keysign.8
  CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
  .if defined(ENABLE_SUID_SSH)
 Index: sys/dev/acpica/acpi_hpet.c


 On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer joes...@gmail.com wrote:
  On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer joes...@gmail.com wrote:
  On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin m...@freebsd.org
 wrote:
  On 16.08.2011 00:13, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org
  wrote:
 
  On 15.08.2011 23:57, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org
   wrote:
 
  On 15.08.2011 22:18, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
   wrote:
 
  On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.
 
  Doesn't seem to help.  Eventtimer HPET and timecounter ACPI-fast still
 stalls.
 
 
  If changing timecounter won't help, try please this patch:
 
  --- acpi_hpet.c.prev2010-12-25 11:28:45.0 +0200
  +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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
 
  Will do next.
 
 
  Patch

Re: Clock stalls on Sabertooth 990FX

2011-08-16 Thread Joe Schaefer 
On Tue, Aug 16, 2011 at 7:39 AM, ambrosehuang ambrose
ambrose...@gmail.com wrote:


 2011/8/16 Joe Schaefer joes...@gmail.com

 FWIW here's a patch I needed to get buildworld to complete against head
 (as of today):

 Index: secure/libexec/ssh-keysign/Makefile
 ===
 --- secure/libexec/ssh-keysign/Makefile (revision 224899)
 +++ secure/libexec/ssh-keysign/Makefile (working copy)
 @@ -1,7 +1,7 @@
  # $FreeBSD$

  PROG=  ssh-keysign
 -SRCS=  ssh-keysign.c readconf.c roaming_dummy.c
 +SRCS=  ssh-keysign.c buffer.c readconf.c roaming_dummy.c
  MAN=   ssh-keysign.8
  CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
  .if defined(ENABLE_SUID_SSH)
 Index: sys/dev/acpica/acpi_hpet.c


 On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer joes...@gmail.com wrote:
  On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer joes...@gmail.com wrote:
  On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin m...@freebsd.org
  wrote:
  On 16.08.2011 00:13, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org
   wrote:
 
  On 15.08.2011 23:57, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org
   wrote:
 
  On 15.08.2011 22:18, Joe Schaefer wrote:
 
  On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
   wrote:
 
  On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.
 
  Doesn't seem to help.  Eventtimer HPET and timecounter ACPI-fast still
  stalls.
 
 
  If changing timecounter won't help, try please this patch:
 
  --- acpi_hpet.c.prev    2010-12-25 11:28:45.0 +0200
  +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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 =

Re: Clock stalls on Sabertooth 990FX

2011-08-16 Thread Alexander Motin 
Joe Schaefer wrote:
 If changing timecounter won't help, try please this patch:

 --- acpi_hpet.c.prev2010-12-25 11:28:45.0 +0200
 +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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
 Will do next.

 Patch applied. Running with HPET eventtimer and no stalls during
 make buildworld -j12.

 it maybe help, I used to come across a bug on Linux with regard to HPET,
 some northbridge chipset (maybe amd's, where
 HPET sit on) has a problem, that writes to  compatitor regs will not take
 effect immediately, you need a read to reg to flush it;
 
 So far the patch performs flawlessly for me.  I'm tempted to reenable turbo
 mode just for kicks (someday, not today- delighted with the uptime!)

I am going to commit following patch:
http://people.freebsd.org/~mav/hpet.paranoid.patch
. It uses same assumptions as Linux. Try it please.

-- 
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

Re: Clock stalls on Sabertooth 990FX

2011-08-16 Thread Joe Schaefer 
On Tue, Aug 16, 2011 at 10:42 AM, Alexander Motin m...@freebsd.org wrote:
 Joe Schaefer wrote:
 If changing timecounter won't help, try please this patch:

 --- acpi_hpet.c.prev    2010-12-25 11:28:45.0 +0200
 +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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
 Will do next.

 Patch applied. Running with HPET eventtimer and no stalls during
 make buildworld -j12.

 it maybe help, I used to come across a bug on Linux with regard to HPET,
 some northbridge chipset (maybe amd's, where
 HPET sit on) has a problem, that writes to  compatitor regs will not take
 effect immediately, you need a read to reg to flush it;

 So far the patch performs flawlessly for me.  I'm tempted to reenable turbo
 mode just for kicks (someday, not today- delighted with the uptime!)

 I am going to commit following patch:
 http://people.freebsd.org/~mav/hpet.paranoid.patch
 . It uses same assumptions as Linux. Try it please.

+1 to apply: (tested with buildworld -j18)

--
 World build completed on Tue Aug 16 12:02:20 EDT 2011
--
5255.533u 2443.815s 30:28.62 421.0% 6535+4429k 0+0io 223826pf+0w
sextant# uname -a
FreeBSD sextant.sunstarsys.com 9.0-BETA1 FreeBSD 9.0-BETA1 #1
r224899M: Tue Aug 16 10:55:12 EDT 2011
j...@sextant.sunstarsys.com:/usr/obj/usr/src/sys/DTRACE  amd64
sextant# uptime
12:02PM  up 32 mins, 3 users, load averages: 6.90, 12.58, 10.64



 --
 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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Andriy Gapon 
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

When the problem starts using vmstat -i to check interrupt rates and see if any
relevant counter gets stuck.

-- 
Andriy Gapon
___
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
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
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2


 When the problem starts using vmstat -i to check interrupt rates and see if 
 any
 relevant counter gets stuck.

(during a buildworld run):

joe@sextant:~% vmstat -i   [master]
interrupt  total   rate
irq16: hdac2  39  0
irq17: ehci0 ehci1+2  0
irq18: ohci0 ohci1*56943  1
irq19: ahci0 1004414 24
irq22: fwohci0653499 16
irq46: atapci1 60047  1
irq256: hpet0:t0 8309347205
irq259: hdac0  1  0
irq260: hdac1  1  0
irq261: re093596  2
Total   10177889251
joe@sextant:~% vmstat -i   [master]
interrupt  total   rate
irq16: hdac2  39  0
irq17: ehci0 ehci1+2  0
irq18: ohci0 ohci1*57019  1
irq19: ahci0 1009467 24
irq22: fwohci0653921 16
irq46: atapci1 60146  1
irq256: hpet0:t0 8381321207
irq259: hdac0  1  0
irq260: hdac1  1  0
irq261: re093694  2
Total   10255611253
joe@sextant:~% date[master]
Mon Aug 15 09:18:25 EDT 2011
joe@sextant:~% date[master]
Mon Aug 15 09:18:27 EDT 2011
joe@sextant:~% vmstat -i   [master]
interrupt  total   rate
irq16: hdac2  39  0
irq17: ehci0 ehci1+2  0
irq18: ohci0 ohci1*57410  1
irq19: ahci0 1019054 25
irq22: fwohci0654275 16
irq46: atapci1 60230  1
irq256: hpet0:t0 8438249208
irq259: hdac0  1  0
irq260: hdac1  1  0
irq261: re093835  2
Total   10323096254
joe@sextant:~% date[master]
Mon Aug 15 09:19:41 EDT 2011
joe@sextant:~% date[master]
Mon Aug 15 09:19:41 EDT 2011
joe@sextant:~% vmstat -i   [master]
interrupt  total   rate
irq16: hdac2  39  0
irq17: ehci0 ehci1+2  0
irq18: ohci0 ohci1*57432  1
irq19: ahci0

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
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.
___
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Alexander Motin 

On 15.08.2011 23:57, Joe Schaefer wrote:

On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org  wrote:

On 15.08.2011 22:18, Joe Schaefer wrote:


On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.comwrote:


On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@freebsd.orgwrote:


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.


Also, please check whether kern.timecounter.tc.X.counter value changes for
the selected timercounter and whether you are receiving timer interrupts in
`vmstat -i`


--
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Alexander Motin 

On 15.08.2011 22:18, Joe Schaefer wrote:

On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com  wrote:

On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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?


Also, please check whether kern.timecounter.tc.X.counter value changes 
for the selected timercounter and whether you are receiving timer 
interrupts in `vmstat -i`


--
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
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 Motinm...@freebsd.org  wrote:

 On 15.08.2011 22:18, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
  wrote:

 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.


 Also, please check whether kern.timecounter.tc.X.counter value changes
 for
 the selected timercounter and whether you are receiving timer interrupts
 in
 `vmstat -i`

Yep.
___
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Alexander Motin 

On 16.08.2011 00:13, Joe Schaefer wrote:

On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org  wrote:

On 15.08.2011 23:57, Joe Schaefer wrote:


On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.orgwrote:


On 15.08.2011 22:18, Joe Schaefer wrote:


On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
  wrote:


On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.prev2010-12-25 11:28:45.0 +0200
+++ acpi_hpet.c 2011-05-11 14:30:59.0 +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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
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 Schaeferjoes...@gmail.com  wrote:

 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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).


 Also, please check whether kern.timecounter.tc.X.counter value changes for
 the selected timercounter and whether you are receiving timer interrupts in
 `vmstat -i`

 --
 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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin m...@freebsd.org wrote:
 On 16.08.2011 00:13, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org  wrote:

 On 15.08.2011 23:57, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org
  wrote:

 On 15.08.2011 22:18, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
  wrote:

 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.

Doesn't seem to help.  Eventtimer HPET and timecounter ACPI-fast still stalls.


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

 --- acpi_hpet.c.prev    2010-12-25 11:28:45.0 +0200
 +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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

Will do next.
___
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer joes...@gmail.com wrote:
 On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin m...@freebsd.org wrote:
 On 16.08.2011 00:13, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org  wrote:

 On 15.08.2011 23:57, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org
  wrote:

 On 15.08.2011 22:18, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
  wrote:

 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.

 Doesn't seem to help.  Eventtimer HPET and timecounter ACPI-fast still stalls.


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

 --- acpi_hpet.c.prev    2010-12-25 11:28:45.0 +0200
 +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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

 Will do next.


Patch applied. Running with HPET eventtimer and no stalls during
make buildworld -j12.
___
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

Re: Clock stalls on Sabertooth 990FX

2011-08-15 Thread Joe Schaefer 
FWIW here's a patch I needed to get buildworld to complete against head
(as of today):

Index: secure/libexec/ssh-keysign/Makefile
===
--- secure/libexec/ssh-keysign/Makefile (revision 224899)
+++ secure/libexec/ssh-keysign/Makefile (working copy)
@@ -1,7 +1,7 @@
 # $FreeBSD$

 PROG=  ssh-keysign
-SRCS=  ssh-keysign.c readconf.c roaming_dummy.c
+SRCS=  ssh-keysign.c buffer.c readconf.c roaming_dummy.c
 MAN=   ssh-keysign.8
 CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
 .if defined(ENABLE_SUID_SSH)
Index: sys/dev/acpica/acpi_hpet.c


On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer joes...@gmail.com wrote:
 On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer joes...@gmail.com wrote:
 On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin m...@freebsd.org wrote:
 On 16.08.2011 00:13, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motinm...@freebsd.org  wrote:

 On 15.08.2011 23:57, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motinm...@freebsd.org
  wrote:

 On 15.08.2011 22:18, Joe Schaefer wrote:

 On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaeferjoes...@gmail.com
  wrote:

 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapona...@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.

 Doesn't seem to help.  Eventtimer HPET and timecounter ACPI-fast still 
 stalls.


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

 --- acpi_hpet.c.prev    2010-12-25 11:28:45.0 +0200
 +++ acpi_hpet.c 2011-05-11 14:30:59.0 +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

 Will do next.


 Patch applied. Running with HPET eventtimer and no stalls during
 make buildworld -j12.

___
freebsd-hackers@freebsd.org mailing

Clock stalls on Sabertooth 990FX

2011-08-13 Thread Joe Schaefer 
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?
___
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