[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] 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?

> printf("triggers=%lx \n", cxstat->triggers[0]);
> 
> Run it, and it will show segment fault at print the cxtat->tiggers[0].
> It seems that xc_pm_get_cxstat() will free cxstat->triggers which we
> allocate memory before, and then when try to touch cxstat->tiggers[0],
> the issue raised.

I can't see any code which frees cxstat->triggers in xc_pm_get_cxstat,
there is only code which frees the bounce buffer.

Perhaps the issue you are seeing is with get_cxstat_by_cpuid from
xenpm.c rather than xc_pm_get_cxstat directly? I notice that
get_cxstat_by_cpuid is called on one occasion without checking the
return code and that it frees the trigger array when xc_pm_get_cxstat
fails so a new failure introduced by 22292 could cause this?

What hardware is this on? What is max_cx_num and max_cpu_nr for you?

> If remove the patch 22292, everything is ok.
> 
> best regards
> yang
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.