On Tue, 2011-06-07 at 11:01 +0100, Stefan Bader wrote:
> On 07.06.2011 11:14, Ian Campbell wrote:
> > 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...
> >
> I am not doubting that. It is more the way I see for stable:
> - first patch solves the problem
> - does it cause other problems? If no, done. Otherwise, what changes are
> necessary to make it work?
>
> So if the first patch is a hack, but one that makes things work and was
> upstream
> at some point, I think it is hard to argue for the cleanup as long as it
> "only"
> does things right.
>
> But I will check how well the other two fit into the various stable/longterm
> trees and then send a proposal to stable cc'ing you and Thomas with the
> options.
ACK. I think it's better to propose them and let them be rejected by the
stable/longterm maintainers if they don't think they are appropriate.
Ian.
> Then we will see how things go there.
>
> -Stefan
> >
> >>
> >> -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
|
Home