Attachment is our test source. Use "gcc -lxenctrl residency.c -o residency" to
compile, then run "./ residency -n 1 -c" to get the c status data.
And following is the backtrace and output with your patch:
[root@vt-nhm7 tools]# gdb xenpm
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xenpm...done.
(gdb) set args get-cpuidle-states
(gdb) r
Starting program: /usr/sbin/xenpm get-cpuidle-states
[Thread debugging using libthread_db enabled]
xc__hypercall_bounce_pre bounced 136 bytes from user buf 0x7fffffffe700 into
hcall buf 0x607004
xc__hypercall_bounce_post bounced 136 bytes back from hcall buf 0x607004 into
user buf 0x7fffffffe700
xc__hypercall_bounce_pre bounced 136 bytes from user buf 0x7fffffffe6d0 into
hcall buf 0x607004
xc__hypercall_bounce_post bounced 136 bytes back from hcall buf 0x607004 into
user buf 0x7fffffffe6d0
Max C-state: C7
xc__hypercall_bounce_pre bounced 136 bytes from user buf 0x7fffffffe620 into
hcall buf 0x607004
xc__hypercall_bounce_post bounced 136 bytes back from hcall buf 0x607004 into
user buf 0x7fffffffe620
get_cxstat_by_cpuid: max_cx 4 for cpuid 0
xc__hypercall_bounce_pre bounced 136 bytes from user buf 0x7fffffffe4f0 into
hcall buf 0x607004
xc__hypercall_bounce_post bounced 136 bytes back from hcall buf 0x607004 into
user buf 0x7fffffffe4f0
xc__hypercall_bounce_pre bounced 32 bytes from user buf 0x7fffffffe720 into
hcall buf 0x607004
xc__hypercall_bounce_pre bounced 32 bytes from user buf 0x7fffffffe728 into
hcall buf 0x609004
xc__hypercall_bounce_pre bounced 136 bytes from user buf 0x7fffffffe610 into
hcall buf 0x60b004
xc__hypercall_bounce_post bounced 136 bytes back from hcall buf 0x60b004 into
user buf 0x7fffffffe610
xc__hypercall_bounce_post bounced 32 bytes back from hcall buf 0x609004 into
user buf 0x7fffffffe728
xc__hypercall_bounce_post bounced 32 bytes back from hcall buf 0x607004 into
user buf 0x7fffffffe720
xc_pm_get_cxstat done returning 0
get_cx_stat_by_cpuid succeeded for cpu 0
cpu id : 0
total C-states : 4
idle time(ms) : 32842665
Program received signal SIGSEGV, Segmentation fault.
0x000000000040255a in print_cxstat (xc_handle=<value optimized out>,
cpuid=<value optimized out>)
at xenpm.c:90
90 printf("C%d : transition [%020"PRIu64"]\n",
(gdb) bt
#0 0x000000000040255a in print_cxstat (xc_handle=<value optimized out>,
cpuid=<value optimized out>)
at xenpm.c:90
#1 show_cxstat_by_cpuid (xc_handle=<value optimized out>, cpuid=<value
optimized out>) at xenpm.c:167
#2 0x0000000000403a8b in cxstat_func (argc=<value optimized out>, argv=<value
optimized out>)
at xenpm.c:191
#3 0x0000000000401394 in main (argc=2, argv=0x7fffffffe998) at xenpm.c:1177
best regards
yang
> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx]
> Sent: Monday, November 01, 2010 6:27 PM
> To: Zhang, Yang Z
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Jackson
> Subject: RE: xenpm fail
>
> On Mon, 2010-11-01 at 02:14 +0000, Zhang, Yang Z wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx]
> > > Sent: Friday, October 29, 2010 5:26 PM
> > > To: Zhang, Yang Z
> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Jackson
> > > Subject: Re: xenpm fail
> > >
> > > On Fri, 2010-10-29 at 09:32 +0100, Zhang, Yang Z wrote:
> > > > Hi ian
> > > > I find Cs 22292 cause xenpm broken. When run "xenpm start" or
> > > > "xenpm get-cpuidle-states" and other xenmpm command, it will get
> > > > segment fault.
> > > > After do some investigation, I find call xc_pm_get_cxstat() will
> > > > free the cxstat->tiggers, For example:
> > > > Here is some code form my test.c.
> > > >
> > > > struct xc_cx_stat cxstatinfo, *cxstat = &cxstatinfo;
> > > >
> > > > cxstat->triggers = malloc(max_cx_num * sizeof(uint64_t));
> > > >
> > > > if ( !cxstat->triggers ) {
> > > > printf("get memory fail");
> > > > return NOMEM;
> > > > }
> > > > ret = xc_pm_get_cxstat(xc_handle, cpu, cxstat);
> > >
> > > what is ret at this point?
> > >
> > ret = 0
>
> Are you running the precise code you give above? xc_pm_get_cxstat will return
> failure if cxstat->residencies is not initialised. This didn't change in
> 22292:a1b39d2b9001. I suspect the error you are seeing with your test.c may
> be due to this and unrelated to the problem(s) with xenpm.
>
> My guess is that 22292:a1b39d2b9001 added a new potential failure case to
> xc_pm_get_cxstat (the bounce buffer allocation) which is causing an error to
> be
> returned which is incorrectly handled in xenpm but unfortunately I can't see
> it
> from staring at the code.
>
> Please can you try the attached, increasingly desperate, debugging patch and
> send the complete output of running both your test case and xenpm.
>
> Please could you also run xenpm under gdb and grab a backtrace from the
> location of the segfault.
>
> Ian.
residency.c
Description: residency.c
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home