Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 下午11:28，Konstantin Belousov kostik...@gmail.com 写道： On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: ?? 2012??1??31?? 12:43??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: ?? 2012??1??30?? 2:36??Kostik Belousov kostik...@gmail.com ?? 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 does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use buildworld buildkernel to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware I just did checkout + buildworld + buildkernel with -j 10 on UFS with PCID turned on, everything finished fine. It is up to date HEAD. sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月30日 下午2:36，Kostik Belousov kostik...@gmail.com 写道： 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 does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html I did not found anything about ASN in the AMD manual Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Thank you for looking at the patch. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 上午12:43，Kostik Belousov kostik...@gmail.com 写道： On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: ?? 2012??1??30?? 2:36??Kostik Belousov kostik...@gmail.com ?? 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 does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use buildworld buildkernel to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware MYKERNEL Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Does anyone try kib's Sandy Bridge PCID patch (pcid.2.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.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? I have two question about the pcid.2.patch 1. iff --git a/sys/amd64/amd64/apic_vector.S b/sys/amd64/amd64/apic_vector.S index 96c778d..5b7b759 100644 --- a/sys/amd64/amd64/apic_vector.S +++ b/sys/amd64/amd64/apic_vector.S @@ -149,17 +149,40 @@ IDTVEC(invltlb) #endif pushq %rax + pushq %rdx - movq%cr3, %rax /* invalidate the TLB */ - movq%rax, %cr3 - + cmpl$0,pmap_pcid_enabled + je 1f + + cmpq$0,smp_tlb_invpcid + je 1f + + /* +* For PCID-enabled pmap, set bit 63 of loaded %cr3 to zero. +*/ + movq%cr3,%rax + movq$pcid_cr3,%rdx + cmpq%rax,%rdx + je 1f + movq%rdx,%cr3 + btsq $63, %rax //set bit 63. not flush the tlb when recovering + jmp 2f + + /* +* Invalidate the TLB. +*/ +1: + movq%cr3,%rax +2: // if pcid is available, can we recover the old pcid with 63 bit set？ + movq%rax,%cr3 movqlapic, %rax movl$0, LA_EOI(%rax)/* End Of Interrupt to APIC */ 2. amd64/amd64/pmap.c @@ -5098,15 +5168,20 @@ pmap_activate(struct thread *td) critical_enter(); pmap = vmspace_pmap(td-td_proc-p_vmspace); oldpmap = PCPU_GET(curpmap); + CPU_ZERO(pmap-pm_save); cpuid = PCPU_GET(cpuid); #ifdef SMP CPU_CLR_ATOMIC(cpuid, oldpmap-pm_active); CPU_SET_ATOMIC(cpuid, pmap-pm_active); + CPU_SET_ATOMIC(cpuid, pmap-pm_save); #else CPU_CLR(cpuid, oldpmap-pm_active); CPU_SET(cpuid, pmap-pm_active); + CPU_SET(cpuid, pmap-pm_active); // this should be pm_save not pm_active #endif cr3 = DMAP_TO_PHYS((vm_offset_t)pmap-pm_pml4); + if (pmap-pm_pcid != -1) + cr3 |= pmap-pm_pcid; td-td_pcb-pcb_cr3 = cr3; load_cr3(cr3); PCPU_SET(curpmap, pmap); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
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 ventur...@gmail.com 写道： I assume every who responded so far doesn't use dtrace? Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
sorry, I'm late. the -current has the same problem. here is coredump
capoor-daemon dumped core - see /var/crash/vmcore.2
Thu Nov 24 15:46:46 CST 2011
FreeBSD capoor-daemon 10.0-CURRENT FreeBSD 10.0-CURRENT #1
r+8692e3b-dirty: Thu Nov 24 15:34:53 CST 2011
root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64
panic:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
118Nov 24 15:44:10 capoor-daemon syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...Syncing
disks, vnodes remaining...6 3 1 1 1 0 0 done
All buffers synced.
Uptime: 50s
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8075e19b
stack pointer = 0x28:0xff811c0e29b0
frame pointer = 0x28:0xff811c0e29c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1555 (reboot)
Reading symbols from /boot/kernel/uplcom.ko...Reading symbols from
/boot/kernel/uplcom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/uplcom.ko
Reading symbols from /boot/kernel/ucom.ko...Reading symbols from
/boot/kernel/ucom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ucom.ko
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261
261 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261
#1 0x802d0fd0 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:537
#2 0x802d0901 in db_command (last_cmdp=0x80b08340,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:448
#3 0x802d0b50 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:501
#4 0x802d2c84 in db_trap (type=Variable type is not available.
#5 0x804e4fb1 in kdb_trap (type=9, code=0, tf=0xff811c0e2900)
at /usr/src/sys/kern/subr_kdb.c:625
#6 0x80744072 in trap_fatal (frame=0xff811c0e2900, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:814
#7 0x8074467b in trap (frame=0xff811c0e2900)
at /usr/src/sys/amd64/amd64/trap.c:617
#8 0x8072e7d3 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#9 0x8075e19b in uncore_pcpu_fini (md=0xfe0004b03c00,
cpu=Variable cpu is not available.
)
at cpufunc.h:353
#10 0x802fc5ea in load (module=Variable module is not available.
)
at /usr/src/sys/dev/hwpmc/hwpmc_mod.c:4885
#11 0x804b803a in syscall_module_handler (mod=0xfe00017b9b00,
what=Variable what is not available.
) at /usr/src/sys/kern/kern_syscalls.c:185
#12 0x8049b30f in module_shutdown (arg1=Variable arg1 is not
available.
)
at /usr/src/sys/kern/kern_module.c:104
#13 0x804adc36 in kern_reboot (howto=0)
at /usr/src/sys/kern/kern_shutdown.c:446
#14 0x804ae3dc in sys_reboot (td=0xfe00b219b460,
uap=0xff811c0e2bc0) at /usr/src/sys/kern/kern_shutdown.c:188
#15 0x80743887 in amd64_syscall (td=0xfe00b219b460, traced=0)
at subr_syscall.c:131
#16 0x8072eab7 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 davide.itali...@gmail.com 写道：
On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose ambrose...@gmail.com wrote:
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith kensm...@freebsd.org
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 for the balance of the
9.0-RELEASE
release cycle.
Approved by:re (implicit)
when my machine shutdown in my absence yesterday evening, I find a
kernel oops this morning,(sorry, just printf, I can not get a kernel
dump)
the kernel says it is at uncore_pcpu_fini+0x5b
I check the source, and it is at
static int
uncore_pcpu_fini(struct pmc_mdep *md, int cpu)
{
.
for (n = 0; n npmc; n++)
wrmsr(UCP_EVSEL0 + n, 0); //here
.
here is my cpu type, and build hwpmc into kernel
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986
Re: [PATCH] Intel Sandy Bridge support for hwpmc
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith kensm...@freebsd.org
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 for the balance of the
9.0-RELEASE
release cycle.
Approved by:re (implicit)
when my machine shutdown in my absence yesterday evening, I find a
kernel oops this morning,(sorry, just printf, I can not get a kernel
dump)
the kernel says it is at uncore_pcpu_fini+0x5b
I check the source, and it is at
static int
uncore_pcpu_fini(struct pmc_mdep *md, int cpu)
{
.
for (n = 0; n npmc; n++)
wrmsr(UCP_EVSEL0 + n, 0); //here
.
here is my cpu type, and build hwpmc into kernel
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011
root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64
CPU: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz (2793.02-MHz K8-class CPU)
I will try to apply this to current to see if this is reproduced.
2011/11/14 Attilio Rao atti...@freebsd.org:
2011/11/13 Davide Italiano davide.itali...@gmail.com:
On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano
davide.itali...@gmail.com wrote:
Good evening folks.
During last days I've written a patch to add sandy bridge support to
hwpmc. Until now, the most recent Intel processor microarchitecture
supported was Westmere.
Testing is appreciated, in order to see if there's something that have
to be fixed.
You can find the diff here:
http://davit.altervista.rg/hwpmc_sandy_bridge.diff
I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@
and fabient@ for the useful suggestions.
Best
Davide
Sorry, bad link. It should be:
http://davit.altervista.org/hwpmc_sandy_bridge.diff
I can perform some small cleanups and likely test it too.
If Fabien or George can review it I'm fine with committing as long as
all that is settled.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
If there is anything I can do for kern/160307 or other Dtrace issue ,
please let me know
2011/11/8 Ryan Stone ryst...@gmail.com:
On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose ambrose...@gmail.com wrote:
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
I have committed this as r227342. Thanks for the fix.
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
Yes, I can take a look.
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
Offhand, no. I'll try to find some time to look at your PRs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
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)
in kern/kern_ctf.c
int link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
struct nameidata nd;
struct thread *td = curthread;
uint8_t ctf_hdr[CTF_HDR_SIZE];
#endif
int error = 0;
if (lf == NULL || lc == NULL)
return (EINVAL);
/* Set the defaults for no CTF present. That's not a crime! */
bzero(lc, sizeof(*lc));
#ifdef DDB_CTF
/*
* First check if we've tried to load CTF data previously and the
* CTF ELF section wasn't found. We flag that condition by setting
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)//second
time with same module,
return (0);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
/* We only need to load once. */
lc-ctftab = ef-ctftab;
lc-ctfcnt = ef-ctfcnt;
lc-symtab = ef-ddbsymtab;
lc-strtab = ef-ddbstrtab;
lc-strcnt = ef-ddbstrcnt;
lc-nsym = ef-ddbsymcnt;
lc-ctfoffp = (uint32_t **) ef-ctfoff;
lc-typoffp = (uint32_t **) ef-typoff;
lc-typlenp = ef-typlen;
return (0);
}
/*
* We need to try reading the CTF data. Flag no CTF data present
* by default and if we actually succeed in reading it, we'll
* update ctfcnt to the number of bytes read.
*/
ef-ctfcnt = -1;
-
fisrt time, set ctfcnt to -1, if module does not has ctf section, and
ef-ctfcnt does NOT update with a valid value(0) later,
then second time enter this function with same module(ef), previous
if (ef-ctfcnt 0)
return (0);// should not be 0 here
pass over first time ctf section check, I think we need another fix .
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
And thank you again for your work!
--
[PATCH] Fix kernel panics when using dtrace fbt return probes on i386
[PATCH] Fix types of arguments to dtrace syscall return probes
walltimestamp curpsinfo-pr_psargs has no args from Shawn Webb
latt...@gmail.com.
commit ec734d4fb07fec8d1b5fb8d1d4c8caa0fada4eea
Author: rstone rst...@freebsd.org
Replace fasttrap_copyout() with uwrite(). FreeBSD copyout() is not able to
write to the .text section of a process.
commit 83b04575eb8f73e557f245bb2814ac6db0a89696
Author: rstone rst...@freebsd.org
Fix the DTrace pid return trap interrupt vector. Previously we were using
31, but that vector is reserved.
2011/11/6 Ryan Stone ryst...@gmail.com:
Currently if you try to use the args[] array passed to a syscall
return probe, you get variables with the wrong type. This is because
the systrace implementation is currently using the same function to
provide the same argument types for both the entry and return probes,
which is completely wrong. For example:
# dtrace -v -l -n syscall::mmap:return
ID PROVIDER MODULE FUNCTION NAME
32159 syscall mmap return
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: caddr_t
args[1]: size_t
args[2]: int
args[3]: int
args[4]: int
Re: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
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 ryst...@gmail.com:
I have run into the same issue recently. I have been testing the
following patch(on 8.2-RELEASE) and it seems to have worked for me:
--- mkmakefile.c 11:09:30.0 -0400
+++ mkmakefile.c 2011-10-06 11:13:31.0 -0400
@@ -742,15 +742,16 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n.if defined(NORMAL_CTFCONVERT)
- !empty(NORMAL_CTFCONVERT)\n
- \t${NORMAL_CTFCONVERT}\n.endif, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+ fprintf(f, .if defined(NORMAL_CTFCONVERT)
+ !empty(NORMAL_CTFCONVERT)\n
+ \t${NORMAL_CTFCONVERT}\n.endif\n\n);
}
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
config(8) does not add post-processing for source file with compile-with command in sys/conf/files
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/mkmakefile.c, line 746
}
compilewith = ftp-f_compilewith;
if (compilewith == 0) { // no compile-with
const char *ftype = NULL;
switch (ftp-f_type) {
case NORMAL:
ftype = NORMAL;
break;
case PROFILING:
if (!profiling)
continue;
ftype = PROFILE;
break;
default:
fprintf(stderr,
config: don't know rules for %s\n, np);
break;
}
// only add post-processing for source file without compile-with
snprintf(cmd, sizeof(cmd),
${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
if (strlen(ftp-f_objprefix))
fprintf(f, \t%s $S/%s\n\n, compilewith, np);
else
fprintf(f, \t%s\n\n, compilewith);
}
}
I wonder whether it was NOT allowed to add post-processing to files
with compile-with, license or other issues?
if not a license issue, then I wonder if this fix is OK( I test it on
8-stable with gcc, and 9-stable with both gcc and clang)
diff --git a/usr.sbin/config/mkmakefile.c b/usr.sbin/config/mkmakefile.c
index 2372839..25a85de 100644
--- a/usr.sbin/config/mkmakefile.c
+++ b/usr.sbin/config/mkmakefile.c
@@ -767,6 +767,14 @@ do_rules(FILE *f)
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
+ //handle CTF issule with NORMAL_C and NORMAL_C_NOERROR
+ else if (!strncmp(compilewith, ${NORMAL_C,sizeof(${NORMAL_C))) {
+ snprintf(cmd, sizeof(cmd),
+%s\n\t@${NORMAL_CTFCONVERT}, compilewith);
+ compilewith = cmd;
+ }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is there a step by step howto for dtrace on 9.0 ?
the wiki DTrace (http://wiki.freebsd.org/DTrace) is available and enough for being a HOWTO. 2011/10/9 Adrian Chadd adr...@freebsd.org 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 ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] dtrace crashes when trying to trace fbt probes
);
VFS_UNLOCK_GIANT(vfslocked);
if (hdr != NULL)
free(hdr, M_LINKER);
if (shdr != NULL)
free(shdr, M_LINKER);
if (shstrtab != NULL)
free(shstrtab, M_LINKER);
if (ctftab != NULL)
free(ctftab, M_LINKER);
if (raw != NULL)
free(raw, M_LINKER);
#else
error = EOPNOTSUPP;
#endif
return (error);
}
Here is patch to fix the missing check
..
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index 758ad81..b78e474 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -164,8 +164,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* section names aren't present, then we can't locate the
* .SUNW_ctf section containing the CTF data.
*/
-if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB)
+if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB) {
+
+printf(%s(%d):e_shstrndx is %d, sh_type is %d\n, lf-pathname,
__LINE__,
+hdr-e_shstrndx, shdr[hdr-e_shstrndx].sh_type);
goto out;
+}
/* Allocate memory to buffer the section header strings. */
if ((shstrtab = malloc(shdr[hdr-e_shstrndx].sh_size, M_LINKER,
@@ -187,8 +191,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
break;
/* Check if the CTF section wasn't found. */
-if (i = hdr-e_shnum)
+if (i = hdr-e_shnum) {
+error = EFTYPE;
+printf(%s(%d): module %s has no .SUNW_ctf section\n, __func__,
+__LINE__, lf-pathname);
goto out;
+}
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
@@ -197,12 +205,20 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
-if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
+if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf) {
+error = EFTYPE;
+printf(%s(%d): module %s has wrong 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__,
+lf-pathname, ctf_hdr[2]);
goto out;
+}
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
.
2011/9/26 Paul Ambrose ambrose...@gmail.com
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 CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
And I came across the similar problem on 9-current only once, but when I
recompile the kernel,
it does not reproduce. I will try your patch on 8-stable, but could you
tell me where did you meet
the problem, and what is your module without CTF data?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] dtrace crashes when trying to trace fbt probes
sorry, I miss a check, here is the patch
.
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index 758ad81..6beefcc 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -164,8 +164,14 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* section names aren't present, then we can't locate the
* .SUNW_ctf section containing the CTF data.
*/
-if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB)
+if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB) {
+
+error = EFTYPE;
+printf(%s(%d): module %s e_shstrndx is %d, sh_type is %d\n,
__func__,
+__LINE__, lf-pathname, hdr-e_shstrndx,
+shdr[hdr-e_shstrndx].sh_type);
goto out;
+}
/* Allocate memory to buffer the section header strings. */
if ((shstrtab = malloc(shdr[hdr-e_shstrndx].sh_size, M_LINKER,
@@ -187,8 +193,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
break;
/* Check if the CTF section wasn't found. */
-if (i = hdr-e_shnum)
+if (i = hdr-e_shnum) {
+error = EFTYPE;
+printf(%s(%d): module %s has no .SUNW_ctf section\n, __func__,
+__LINE__, lf-pathname);
goto out;
+}
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
@@ -197,12 +207,20 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
-if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
+if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf) {
+error = EFTYPE;
+printf(%s(%d): module %s has wrong 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__,
+lf-pathname, ctf_hdr[2]);
goto out;
+}
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
2011/9/29 Paul Ambrose ambrose...@gmail.com
In 8-stable, WITH_CTF=1 configure item is enabled in command line, not in
make.conf, so when I build kernel module out of /usr/src source tree, such
as x11/nvidia-driver, I forgot to use WITH_CTF=1 and nvidia.ko was built
without .SUNW_ctf section. However, when I run:
#dtrace -lv
trigger the NULL pointer dereference at: /usr/src/sys/cddl/dev/fbt/fbt.c
..
if (*lc.ctfoffp == NULL) { // page fault here
/*
* Initialise the CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
the reason is at /usr/src/sys/kern/kern_ctf.c:
..
/* Search for the section containing the CTF data. */
for (i = 0; i hdr-e_shnum; i++)
if (strcmp(.SUNW_ctf, shstrtab + shdr[i].sh_name) == 0)
break;
/* Check if the CTF section wasn't found. */
if (i = hdr-e_shnum) //here we found no ctf data, but NOT
update the varible error
goto out; // see label out
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
shdr[i].sh_offset, UIO_SYSSPACE, IO_NODELOCKED, td-td_ucred,
NOCRED, resid, td)) != 0)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
goto out;
/* Check if version 2. */
if (ctf_hdr[2] != 2)
goto out;
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
uint32_t *u32 = (uint32_t *) ctf_hdr;
/*
* The last two fields in the CTF header are the offset
* from the end of the header to the start of the string
* data and the length of that string data. se this
* information to determine the decompressed CTF data
* buffer required.
*/
sz = u32[CTF_HDR_STRTAB_U32] + u32[CTF_HDR_STRLEN_U32] +
sizeof(ctf_hdr);
/*
* Allocate memory for the compressed CTF data, including
* the header (which isn't compressed).
*/
if ((raw = malloc(shdr[i].sh_size, M_LINKER, M_WAITOK)) == NULL) {
error = ENOMEM
[PATCH] dtrace crashes when trying to trace fbt probes
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 CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
And I came across the similar problem on 9-current only once, but when I
recompile the kernel,
it does not reproduce. I will try your patch on 8-stable, but could you tell
me where did you meet
the problem, and what is your module without CTF data?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
I heard of that news, but I didn't realize that web site was managed by John Birrell. Now, DTrace is not feature-complete and stable, I don't think it is suitable to http://www.freebsd.org/doc/handbook/dtrace.html, but to http://wiki.freebsd.org/DTrace, and people can easily update it 2011/8/31 Craig Rodrigues rodr...@crodrigues.org Hi, http://dtrace.what-creek.com no longer exists, because sadly, the author of that web page (John Birrell) is no longer with us: http://lists.freebsd.org/pipermail/freebsd-announce/2009-November/001284.html There are some other documentation pages available for DTrace on FreeBSD: http://wiki.freebsd.org/DTrace http://www.freebsd.org/doc/handbook/dtrace.html If you have ideas for how to enhance this documentation, you should submit your ideas. The freebsd-...@freebsd.org mailing list is a good place to start. -- Craig Rodrigues rodr...@crodrigues.org On Tue, Aug 30, 2011 at 9:21 PM, Paul Ambrose ambrose...@gmail.com 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 maybe I miss something. I started to use FreeBSD about 2.5 year ago, and learn FreeBSD kernel recently because of DTrace. I like it and I hope I can do something more ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
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 different from Solaris/Mac OS X. The DTraceToolkit, which has many amazing feature, can not 100% works on FreeBSD, and there is no doc to identify the difference. 3 There is a missing feature list about DTrace, but no schedule list about when to fix it. 2011/8/30 Sergey Kandaurov pluk...@gmail.com On 30 August 2011 13:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 08/30/11 09:29, Hans Petter Selasky wrote: On Monday 29 August 2011 21:58:29 Volodymyr Kostyrko wrote: 27.08.2011 22:13, Hartmann, O. wrote: This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html I think this one would better look like list of major features with os comparison, like: = Networking = * IPv6: major support, best stack around. * SCTP: full kernel implementation, still no userland support (i.e. ssh doesn't work over sctp by default yet). = Data storage = * ZFS: full support, datasets, compression, dedup, other stuff. Linux has LVM (?features...) and btrfs (?unstable.. ?features..), Windows has dynamic disks since XP (?features). = SMP = * (?something about comparing other shedulers with SCHED_ULE), (?some rt stuff), (?some comparison with other interesting shedulers, like DragonflyBSD and QNX). And USB. I believe there are significant changes in the USB subsystems which those who are making performance benchmarks completely fail to mention. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org What's about DTrace? = Development/System Profiling = * DTrace: Some notes of the Kernel Gurus what this could mean for performance profiling and development = Licensing Model = * Some striking comments on the advantage for companies or interested people of the BSD-like licensing model over the GPLv3 on which Linux is based now and which has serious implications for those who wants to develop and sell software developed on/with GNU stuff. it would be very honest, if we do not only emphasize only the pros. BSD came from the academic environment, that was where I met it the first time and I appreciated the way things were developed and 'sloppyness' was a nogo. So we should keep it up and a serious and honest set of contraru points for all compared OS should be appreciable. Does the VM of FreeBSD still have advantges (measurable) over Linux? [Taking random email.] I think we could merge the $subj web page with this one (which is more actual, as of 7.0): http://www.freebsd.org/features.html -- wbr, pluknet ___ freebsd-performa...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to freebsd-performance-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
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 we have done. The kernel DTrace is quite stable, but compared to Solaris, what else do we miss, what Solaris has but we do not, whether we implement all the builtin var and function, if not, do we have other alternative?. I come across problems with DTrace, but I don't know whether it is a bug or has not been supported 2 write more examples about how to debug kernel with DTrace on FreeBSD, I think these example can let others know what we can do with DTrace. BTW, I am a Chinese and live in Chengdu, China, I can't have access to dtrace.what-creek.com because of GFW, so maybe I miss something. I started to use FreeBSD about 2.5 year ago, and learn FreeBSD kernel recently because of DTrace. I like it and I hope I can do something more 2011/8/31 Andriy Gapon a...@freebsd.org on 30/08/2011 18:39 Andriy Gapon said the following: 4. There is a missing developer/maintainer for DTrace on FreeBSD. I probably should clarify this point: it doesn't have to be *the* maintainer, a collective maintainer is also perfect. Thus, contributions are very welcome. Nevertheless the kernel DTrace is quite usable and useful for kernel debugging. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
