From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [PATCH v2] Fix scheduler crash after s3 resume
Date: Fri, 25 Jan 2013 14:58:01 +0100
Message-ID: <51028F69.1070804@citrix.com>
References: <5100070F.7010808@citrix.com> <5100D229.4030906@ts.fujitsu.com>
	<510144A3.9060302@citrix.com>
	<5101630D02000078000B93AD@nat28.tlf.novell.com>
	<51016065.3080902@citrix.com>
	<510175E802000078000B94A1@nat28.tlf.novell.com>
	<51024B56.20706@citrix.com>
	<5102603302000078000B985C@nat28.tlf.novell.com>
	<5102541D.1070408@citrix.com>
	<5102694B02000078000B98B7@nat28.tlf.novell.com>
	<51025D2C.3040005@ts.fujitsu.com>
	<51026CFC02000078000B9917@nat28.tlf.novell.com>
	<51025FE5.1070200@ts.fujitsu.com> <510272DA.5030003@citrix.com>
	<5102883302000078000B9A04@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5102883302000078000B9A04@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, "Keir (Xen.org)" <keir@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 25/01/13 13:27, Jan Beulich wrote:
>>>> On 25.01.13 at 12:56, Tomasz Wroblewski<tomasz.wroblewski@citrix.com>  wrote:
>>>>          
>> I also tried Jan's suggestion of making do_softirq skip its job if we are
>> resuming, that causes a hang in rcu_barrier(), adding another resume
>> conditional rcu_barrier() made it progress further but crash elsewhere (don't
>> remember where exactly, this approach looked a bit like dead end so i
>> abandoned it quickly)
>>      
> I didn't say exactly that - for avoiding the hang, you still need to
> service the RCU softirq.
>    
Ah sorry. Ok this approach seems to work for avoiding vcpu_wake crash, 
although I am still getting this occasional crash in acpi_freq_target, 
same as when I tried Jurgen's suggestion. Not getting call stack 
captured for that so not sure where's that called from, but will try to 
pursue it abit.