在 2012年1月31日 下午11:28，Konstantin Belousov 写道：
> On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote:
>> ?? 2012??1??31?? 12:43??Kostik Belousov ??
>> > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote:
>> >> ?? 2012??1??
在 2012年1月31日 上午12:43，Kostik Belousov 写道：
> On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote:
>> ?? 2012??1??30?? 2:36??Kostik Belousov ??
>> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote:
>> >> I have two boxes, one is AMD
在 2012年1月30日 下午2:36，Kostik Belousov 写道：
> On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote:
>> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current
>> patched with pcid.2.patch? It works well without other issue and it
>> seem the pcid patch
>
I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current
patched with pcid.2.patch? It works well without other issue and it
seem the pcid patch
does not affect other part of the kernel. The other one is Sandy
Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the
pcid.2.pa
I think dtrace for freebsd userland is close to complete( after
r227290, at least no more kernel panic). but is not suitable for a
daily use now.
在 2011年11月30日 上午5:42，Sevan / Venture37 写道：
> I assume every who responded so far doesn't use dtrace?
>
>
> Sevan
> __
f8072eab7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#17 0x000800882bbc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
在 2011年11月18日 上午2:52，Davide Italiano 写道：
> On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose wrote:
>> hi, I apply your
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith
Date: Mon Nov 14 00:45:25 2011 +
The releng/9.0 release branch has been created so convert stable/9 over
to our standard "Politically Correct" name
If there is anything I can do for kern/160307 or other Dtrace issue ,
please let me know
2011/11/8 Ryan Stone :
> On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose wrote:
>> diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
>> index bdff96e..2737860 100644
>> --- a/sys/ker
Thank you for your work. I will give it a try in stable/9. I have
another two PR:
kern/160307 and bin/160275 that maybe you can help;
the reason of bin/160275 is complicated, but the fix for kernel crash
caused by module without ctf section(for example, nvidia.ko) missed
somthing
(my mistake)
i
There are many other compile-with not started with ${NORMAL_C}, your
patch adds
${NORMAL_CTFCONVERT} to them too, which could not be suitable for this.
2011/10/19 Ryan Stone :
> I have run into the same issue recently. I have been testing the
> following patch(on 8.2-RELEASE) and it seems to ha
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
In /usr/src/usr.sbin/config/mkmak
the wiki DTrace (http://wiki.freebsd.org/DTrace) is available and
enough for being a HOWTO.
2011/10/9 Adrian Chadd
>
> Hi,
>
> the subject says it all - does anyone have a step by step howto for
> doing userland and kernel dtrace on 9.0?
>
> Thanks,
>
>
> Adrian
>
YPE;
+printf("%s(%d): module %s CTF format version is %d\n", __func__,
__LINE__,
+lf->pathname, ctf_hdr[2]);
goto out;
+}
/* Check if the data is compressed. */
if ((ctf_hdr[3] & 0x1) != 0) {
....
format\n", __func__, __LINE__,
+lf->pathname);
goto out;
+}
/* Check if version 2. */
-if (ctf_hdr[2] != 2)
+if (ctf_hdr[2] != 2) {
+error = EFTYPE;
+printf("%s(%d): module %s CTF format version is %d\n", __func__,
__LINE__,
+
Hi, Ryan, I came across the similar problem on 8-stable when I run
# dtrace -lv
the panic message says:
page fault just happened at fbt.c
if (*lc.ctfoffp == NULL) { // page fault
/*
* Initialise the
is a good place to start.
>
> --
> Craig Rodrigues
> rodr...@crodrigues.org
>
>
> On Tue, Aug 30, 2011 at 9:21 PM, Paul Ambrose
> wrote:
> > BTW, I am a Chinese and live in Chengdu, China, I can't have access to
> > dtrace.what-creek.com because of GFW, so
I can help, I just changed my job and get more spare time. Currently I can
help write doc and test. There is much documentation about DTrace ( thanks
Sun), but none of these describes the technical details of FreeBSD DTrace
implementation, so I think we can start with this.
1 write doc about what
I do not believe the current status of DTrace is appropriate for promoting
1. DTrace is an experimental function or Semi-finished products. The kernel
dtrace support is ok, but the userland support is far from completion(at
least the pid provider has many bugs)
2 the FreeBSD implementation is
18 matches
Mail list logo
