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

[Guanqun Lu <guanqun.lu@xxxxxxxxx>]

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)
 {
     iommu_suspend();

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

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

 static void device_power_up(void)
 {
+    console_resume();
+
     lapic_resume();

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

     time_resume();
-
-    console_resume();

     iommu_resume();
 }



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



-- 
Guanqun

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