Re: Clock stalls on Sabertooth 990FX
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: DTrace unable to dump typedef'ed argument
it has been fixed by kern/159064: [dtrace] MFC request for dtrace to fix invalid probe specifier 2011/8/14 ambrosehuang ambrose ambrose...@gmail.com same problem on 8.2-stable 2011/8/10 Shrikanth Kamath shrikant...@gmail.com I found this on a FreeBSD 8.1 box... %dtrace -l -f rtalloc_fib -v ... Argument Types args[0]: struct route * args[1]: (unknown) The function defined in sys/net/route.c: void rtalloc_fib(struct route *ro, u_int fibnum) u_int is typedef unsigned int I checked the ctfdump for /boot/kernel/kernel and found u_int is a resolved type. [14077] FUNC (rtalloc_fib) returns: 29 args: (1335, 5) Checking the CTF table 5 is found to be a resolved typedef. 4 INTEGER unsigned int encoding=0x0 offset=0 bits=32 5 TYPEDEF u_int refers to 4 But since it shows unknown with dtrace -l -f o/p, one cannot directly use args[1]. Is this a known problem, any fix or workaround? -- Shrikanth R K ___ 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 ___ 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: DTrace unable to dump typedef'ed argument
same problem on 8.2-stable 2011/8/10 Shrikanth Kamath shrikant...@gmail.com I found this on a FreeBSD 8.1 box... %dtrace -l -f rtalloc_fib -v ... Argument Types args[0]: struct route * args[1]: (unknown) The function defined in sys/net/route.c: void rtalloc_fib(struct route *ro, u_int fibnum) u_int is typedef unsigned int I checked the ctfdump for /boot/kernel/kernel and found u_int is a resolved type. [14077] FUNC (rtalloc_fib) returns: 29 args: (1335, 5) Checking the CTF table 5 is found to be a resolved typedef. 4 INTEGER unsigned int encoding=0x0 offset=0 bits=32 5 TYPEDEF u_int refers to 4 But since it shows unknown with dtrace -l -f o/p, one cannot directly use args[1]. Is this a known problem, any fix or workaround? -- Shrikanth R K ___ 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 ___ 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: DTrace script asserts and kills the other process
2011/8/4 ambrosehuang ambrose ambrose...@gmail.com
2011/8/3 Andriy Gapon a...@freebsd.org
on 28/07/2011 07:10 ambrosehuang ambrose said the following:
Yuri y...@rawbw.com wrote:
I am trying to run this dtrace script:
#!/usr/sbin/dtrace -s
pid123:libc::entry
{
self-timestmp[probefunc] = timestmp;
}
pid123:libc::return
/self-timestmp[probefunc] != 0/
{
@function_duration[probefunc] = sum(timestmp -
self-timestmp[probefunc]); timestmp[probefunc] = 0;
}
which I got from here:
http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html
replacing 123 with the pid of some running process.
Result: dtrace utility asserts:
Assertion failed: (dpr != NULL), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c,
line 751.
Abort trap: 6
Also the target process is killed too:
Killed: 9
8.2-STABLE amd64
This is a known issue. You may be able to work around it by
letting dtrace start the traced process.
There's already a PR about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431
but the limitation isn't mentioned in the wiki:
http://wiki.freebsd.org/DTrace/userland
FYI and benefit: I've committed what should be a fix for this issue,
r224632.
It's not clear to me if this has worked in the past or if it
works for other architectures (the reporter and I are both using
amd64, too).
Fabian
I came across the same problem in 8.2-stable , it seemed the problem had
been there since 8.2-release with userland dtrace integrated. I followed
the
PR185431 and found when dtrace started, it indeed attached to the
traced
process( dpr != NULL), but the traced process died soon, and
according to the PR, this is error in error since the dtrace came
accross
error in dfatal
#3 0x000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40,
remove=0)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751
#4 0x000808d8af92 in dt_proc_destroy (dtp=0x80b841000,
P=0x80d7ffb40)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763
#5 0x000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162
#6 0x000808daa4b5 in dtrace_close (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554
#7 0x00402775 in dfatal (fmt=0x408572 no probes %s\n)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236
#8 0x00406b2c in main (argc=3, argv=0x7ffed9c0)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
.
___
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
I just saw your commit, I will verify it on 8-stable soon, thank you!
--
Andriy Gapon
I test your commit on 8-stable, here is my commit:
commit 84f49c7ffa130ec4bcd7fb0a619b36ab615dfeb4
Author: mm m...@freebsd.org
Date: Thu Aug 4 10:37:12 2011 +
this is the my result:
[root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:libc::entry' -p 39699
libc.so.7: invalid probe specifier pid$target:libc::entry: probe description
pid39699:libc::entry
User defined signal 1: 30
[1]+ Hangup: 1 ../test
I also test the example from userland/dtrace in wiki, it failed with same
result,
it seems the pid provider has something wrong with libc when probing;
[root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:::entry' -p 40346
test: description 'pid$target:::entry' matched 2 probes
^C
success
[root@lateaxfreebsd dtrace]# dtrace -ln 'pid$target:::entry' -p 40346
ID PROVIDERMODULE FUNCTION NAME
33913 pid40346 test_start entry
33914 pid40346 test main entry
User defined signal 1: 30
[1]+ Hangup: 1 ../test
Anyway, there is no core dump.
___
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: DTrace script asserts and kills the other process
2011/8/3 Andriy Gapon a...@freebsd.org
on 28/07/2011 07:10 ambrosehuang ambrose said the following:
Yuri y...@rawbw.com wrote:
I am trying to run this dtrace script:
#!/usr/sbin/dtrace -s
pid123:libc::entry
{
self-timestmp[probefunc] = timestmp;
}
pid123:libc::return
/self-timestmp[probefunc] != 0/
{
@function_duration[probefunc] = sum(timestmp -
self-timestmp[probefunc]); timestmp[probefunc] = 0;
}
which I got from here:
http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html
replacing 123 with the pid of some running process.
Result: dtrace utility asserts:
Assertion failed: (dpr != NULL), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c,
line 751.
Abort trap: 6
Also the target process is killed too:
Killed: 9
8.2-STABLE amd64
This is a known issue. You may be able to work around it by
letting dtrace start the traced process.
There's already a PR about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431
but the limitation isn't mentioned in the wiki:
http://wiki.freebsd.org/DTrace/userland
FYI and benefit: I've committed what should be a fix for this issue,
r224632.
It's not clear to me if this has worked in the past or if it
works for other architectures (the reporter and I are both using
amd64, too).
Fabian
I came across the same problem in 8.2-stable , it seemed the problem had
been there since 8.2-release with userland dtrace integrated. I followed
the
PR185431 and found when dtrace started, it indeed attached to the
traced
process( dpr != NULL), but the traced process died soon, and
according to the PR, this is error in error since the dtrace came
accross
error in dfatal
#3 0x000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40,
remove=0)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751
#4 0x000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763
#5 0x000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162
#6 0x000808daa4b5 in dtrace_close (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554
#7 0x00402775 in dfatal (fmt=0x408572 no probes %s\n)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236
#8 0x00406b2c in main (argc=3, argv=0x7ffed9c0)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
.
___
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
I just saw your commit, I will verify it on 8-stable soon, thank you!
--
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: DTrace script asserts and kills the other process
Yuri y...@rawbw.com wrote:
I am trying to run this dtrace script:
#!/usr/sbin/dtrace -s
pid123:libc::entry
{
self-timestmp[probefunc] = timestmp;
}
pid123:libc::return
/self-timestmp[probefunc] != 0/
{
@function_duration[probefunc] = sum(timestmp -
self-timestmp[probefunc]); timestmp[probefunc] = 0;
}
which I got from here:
http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html
replacing 123 with the pid of some running process.
Result: dtrace utility asserts:
Assertion failed: (dpr != NULL), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c,
line 751.
Abort trap: 6
Also the target process is killed too:
Killed: 9
8.2-STABLE amd64
This is a known issue. You may be able to work around it by
letting dtrace start the traced process.
There's already a PR about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431
but the limitation isn't mentioned in the wiki:
http://wiki.freebsd.org/DTrace/userland
It's not clear to me if this has worked in the past or if it
works for other architectures (the reporter and I are both using
amd64, too).
Fabian
I came across the same problem in 8.2-stable , it seemed the problem had
been there since 8.2-release with userland dtrace integrated. I followed the
PR185431 and found when dtrace started, it indeed attached to the traced
process( dpr != NULL), but the traced process died soon, and
according to the PR, this is error in error since the dtrace came accross
error in dfatal
#3 0x000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40,
remove=0)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751
#4 0x000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763
#5 0x000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162
#6 0x000808daa4b5 in dtrace_close (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554
#7 0x00402775 in dfatal (fmt=0x408572 no probes %s\n)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236
#8 0x00406b2c in main (argc=3, argv=0x7ffed9c0)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
.
___
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
