This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RE: odd IRQ behavior

To: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Subject: Re: [Xen-devel] RE: odd IRQ behavior
From: Guanqun Lu <guanqun.lu@xxxxxxxxx>
Date: Mon, 2 Mar 2009 14:09:39 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sun, 01 Mar 2009 22:10:05 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SqeDGTKpZSam/mcqxjWPjKJkfLvgC2dPp5obdeA/s3c=; b=PWAGIk+hV3+/DyQawVW1/S9MiDsXIaYwP6cku+DPny6Rygj+CHkaJgsD/Ll4fo1dLX 0ogF8dgHbD83cFC/+xj+1gNouuoXLHIjd/UxVatSwdxRjtd7kb2KqSbrVjvWBY6mdqQB sWrWDcZ3g2gnlx62YOWRM3jIbSbOW/eXpom3o=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gNT93JDWejPBEB/nT0ML4632Fx66x09ozXzFBg2wn4vQ/eA8+mRYkedSpApPSXX5j1 sU3W4r5bZGR/qFBWwQkfCAT5AEPulnViCeaLpDTolaDmZoZOa4VN1w9F6v47v2bpCeHC ByrPlpDcJ/f3aJcGM0RnYLZ2fu6elw09rSnaY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4F65016F6CB04E49BFFA15D4F7B798D98D4BA754@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4F65016F6CB04E49BFFA15D4F7B798D98D4BA47D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5CDBA65.3795%keir.fraser@xxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D98D4BA754@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, Feb 28, 2009 at 2:55 AM, Cihula, Joseph <joseph.cihula@xxxxxxxxx> wrote:
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Friday, February 27, 2009 7:42 AM
>> On 27/02/2009 14:35, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
>> >> Please provide some backtraces.
>> >>
>> >>  -- Keir
>> >
>> > Trace of assertion at shutdown entry:
>> Okay, the ASSERT(!in_irq()) crash on shutdown is due to having IPIed to the
>> BP to make it drive the shutdown. Hence the BP is actually in IRQ context.
>> If you then zero the IRQ counter, it will get decremented on exit from the
>> shutdown code (and the IPI interrupt) on S3 resume... Except I'm confused by
>> this because machine_restart() is not used for S3 suspend/resume. So
>> actually I'm not sure how you end up in IRQ context on S3 suspend, and you
>> didn't send a backtrace of that situation. To get to the BP on S3 suspend we
>> use continue_hypercall_on_cpu(), which does not leave us in IRQ context.
>> For the check_lock() assertion, either do not local_irq_disable() in
>> tboot_shutdown() (is that needed?) or perhaps even better (solves all the
>> crashes you've seen) why not disable paging before jumping into tboot and
>> hence avoid needing map_pages_to_xen()? I can't see why tboot would care to
>> run on our random pagetables, and implementing a stub to jump into / out of
>> non-paged mode would be very easy. I can explain more how to do this if this
>> is a suitable solution. Another alternative would be to map tboot pages
>> during boot and leave them mapped forever after. That also would avoid these
>> map_pages_to_xen() during S3/shutdown issues, and I suppose is easier than
>> implementing a return-to-no-paging stub.
> On S3, we also need to create integrity measurements for the xenheap and 
> domheap, which require mapping pages.  So I don't think that either moving 
> the 1:1 mapping early or the disable paging would solve the problem (it would 
> just shift it).
> I think that I did find a way to avoid the reboot spinlock BUG_ON by using 
> spin_debug_{disable/enable}().  S3 still isn't working, but I haven't been 
> able to track down why yet (unfortunately, serial output stops before it 
> fails).

On this serial output thing, you can delay the console suspend a
little bit to see more messages:
(use it for testing and debugging...)

diff -r e5c696aaf2a6 xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c Sun Mar 01 14:58:07 2009 +0000
+++ b/xen/arch/x86/acpi/power.c Mon Mar 02 21:53:17 2009 +0800
@@ -46,21 +46,23 @@ static int device_power_down(void)

+    time_suspend();
+    i8259A_suspend();
+    ioapic_suspend();
+    lapic_suspend();

-    time_suspend();
-    i8259A_suspend();
-    ioapic_suspend();
-    lapic_suspend();
     return 0;

 static void device_power_up(void)
+    console_resume();

@@ -68,8 +70,6 @@ static void device_power_up(void)

-    console_resume();


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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>