Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2011-06-07 at 10:07 +0100, Stefan Bader wrote:
> On 07.06.2011 10:48, Ian Campbell wrote:
> > On Tue, 2011-06-07 at 08:44 +0100, Stefan Bader wrote:
> >> Resending. I could not see this going to the list, so I subscribed and am 
> >> trying
> >> again.
> > 
> > Posts from non-subscribers are moderated, it would have come through at
> > some point.
> > 
> I was not sure how long that would take or whether non-subscribers would just
> get dropped to prevent spam. It does not hurt to be subscribed, so discussion
> can go quicker.
> 
> >> -Stefan
> >>
> >> -------- Original Message --------
> >> Subject: Stable candidate? xen: events: do not unmask event channels on 
> >> resume
> >> Date: Wed, 25 May 2011 16:46:47 +0200
> >> From: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
> >> To: xen-devel@xxxxxxxxxxxxxxxxxxx <xen-devel@xxxxxxxxxxxxxxxxxxx>
> >> CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>
> >> The following patch was reported to solve (at least some in the .32 case) 
> >> hangs
> >> on migration for 2.6.32 and 2.6.35 based kernels. I am not completely sure 
> >> about
> >> the 2.6.32 case as some reporters were reporting success after it was 
> >> applied,
> >> others still had issues[1]. But at least it seemed to improve the 
> >> situation.
> >> Should this get proposed for upstream longterm trees?
> >>
> >> -Stefan
> >>
> >> From cf2e26cf8402af6f65bd89611682497db278f309 Mon Sep 17 00:00:00 2001
> > 
> > This seems to be 6903591f314b in the upstream tree. Also there was a
> > subsequent cleanup in 676dc3cf5bc3 which relies on dc5f219e, which we
> > should consider too. I think as a set they make sense for a
> > stable/longterm backport so you can have my:
> > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > for forwarding to stable@
> > 
> > I expect you'll want/need tglx's Ack for the latter two as well.
> >
> They would be needed when trying to push the whole set, yes. On the other 
> hand,
> on a casual glance, these just seem to make some functionality that the first
> patch did on the xen side, available in the generic framework.
> If there is no issue without the two, my feeling would be, that going with the
> single patch for stable/longterm would be better. To me things going there
> should have a real functional benefit.
> But probably I am overlooking something in the cleanup.

The original patch was really a hack on the xen side, the followups do
it properly...


> 
> -Stefan
> 
> > Ian.
> > 
> >> From: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >> Date: Mon, 1 Nov 2010 16:30:09 +0000
> >> Subject: [PATCH] xen: events: do not unmask event channels on resume
> >>
> >> [1] https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/681083
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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