Stefan Bader
2011-Jun-07 07:44 UTC
[Xen-devel] Stable candidate? xen: events: do not unmask event channels on resume
Resending. I could not see this going to the list, so I subscribed and am trying again. -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@canonical.com> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> CC: Ian Campbell <ian.campbell@citrix.com> 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 2001From: Ian Campbell <ian.campbell@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jun-07 08:48 UTC
[Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume
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.> -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@canonical.com> > To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> > CC: Ian Campbell <ian.campbell@citrix.com> > > 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 2001This 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@citrix.com> for forwarding to stable@ I expect you''ll want/need tglx''s Ack for the latter two as well. Ian.> From: Ian Campbell <ian.campbell@citrix.com> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan Bader
2011-Jun-07 09:07 UTC
Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume
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@canonical.com> >> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> >> CC: Ian Campbell <ian.campbell@citrix.com> >> >> 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@citrix.com> > 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. -Stefan> Ian. > >> From: Ian Campbell <ian.campbell@citrix.com> >> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jun-07 09:14 UTC
Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume
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@canonical.com> > >> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> > >> CC: Ian Campbell <ian.campbell@citrix.com> > >> > >> 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@citrix.com> > > 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@citrix.com> > >> 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan Bader
2011-Jun-07 10:01 UTC
Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume
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@canonical.com> >>>> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> >>>> CC: Ian Campbell <ian.campbell@citrix.com> >>>> >>>> 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@citrix.com> >>> 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. Then we will see how things go there. -Stefan> >> >> -Stefan >> >>> Ian. >>> >>>> From: Ian Campbell <ian.campbell@citrix.com> >>>> 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@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jun-07 10:23 UTC
Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume
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@canonical.com> > >>>> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com> > >>>> CC: Ian Campbell <ian.campbell@citrix.com> > >>>> > >>>> 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@citrix.com> > >>> 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@citrix.com> > >>>> 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@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel