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
|
Home