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

Re: [Xen-devel] Re: 2.6.39 merge window (git pulls and what is planned to go in)



> > > 4/5 needs to be upstream (via Rafael) first though, doesn't it? That's

Yes...
> > > the keystone here, the rest appears to fall out nicely once that has
> > > gone in.
> > >
> > err, that was not the plan (though what you suggested would also work).
> > Look at thread
> > "Q: Clarification about extra option.."
> > http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00267.html
> > 
> > The plan was that I would create a new tree by merging Rafael and
> > Stefano's trees. And then rebase my patches on this new tree, send out to
> > the list for review. Konrad meanwhile would pull this new tree+patches into 
> > his

So whatever I was hitting earlier on is gone (it also helps when I updated
my tools)

I took your tree, stuck it on top of my #linux-next and Stefano's #linux-next
and ran it with 'xm' (4.0) and 'xl' (4.1).

The 'xm save -c' and/or 'xm save' worked just great. The ping kept on going 
happily
doing these 'xm save -c'. 

The 'xl save -c' on the other hand, failed on me. I don't know what the failure 
is
but I see this state in the guest: 

test                                         8  1024     4     ---ss-       5.3

I should update my xen-uinstable tree just to make sure I am not missing 
something
obvious.

> > tree and push it after Rafael & Stefano's trees have gone in.
> 
> If Rafael is happy with that plan then fine, but I didn't see him ack it
> in that thread (AFAICT he only acked the concept of what the patch would
> do). Either way someone still needs to follow up with him to get an Ack
> on the 4/5 patch since it is to the PM core, if he's subsequently also

Yup. Please do ping him for his ACK. He needs to OK

      PM: Add visible HIBERNATION_INTERFACE and hide HIBERNATION


patch. Which btw, I looked in a kernel built before your patch
and had /sys/power/state contain "mem disk" (good). With your patch
and with 
CONFIG_HIBERNATION=y
# CONFIG_HIBERNATION_INTERFACE is not set

the /sys/power/state contained only "mem". Which is expected and
what the patch is suppose to do.

But what surprising is that I still had the /sys/power/disk attribute?

Also I saw this during compile:

/home/konrad/ssd/linux/kernel/power/hibernate.c:556: warning: âpower_downâ 
defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:68: warning: âsnapshot_openâ defined 
but not used
/home/konrad/ssd/linux/kernel/power/user.c:128: warning: âsnapshot_releaseâ 
defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:149: warning: âsnapshot_readâ 
defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:182: warning: âsnapshot_writeâ 
defined but not used
/home/konrad/ssd/linux/kernel/power/user.c:220: warning: âsnapshot_ioctlâ 
defined but not used

Which you should address (you could send a follow-up patch for it).
Hadn't tried to compile this under i386 so no idea if there are any
warnings there either.

> ok with taking it through a tree other than his own then great.

I stuck it in #linux-next-kitchensink

Will re-organize it appropiately soon.
> 
> Ian.

_______________________________________________
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®.