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.
xc_pm-debug.patch
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home