[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Powerdown problem on XEN | ACPI S5



Hi Andrew,
please see my inline comments further below.

And many thanks to all of you for your support so far!

Am 14.08.13 16:00, schrieb Andrew Cooper:
On 14/08/13 14:52, Atom2 wrote:
Hi Jan,
thanks for reply. You are obviously right that the first thing
device_power_down does, is console_suspend(). I don't know why that
escaped my eyes when I originally searched the file ...

Anyways, I have now disabled console_suspend() and also added a few
more lines to the code with printk statements indicating up to which
point the system had gone (without errors). With hindsight I guess the
new printk() statements might not have been required as now, with the
console still active, a panic message pops up at the end, resulting in
rebooting the system:

(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S5 state.
(XEN) After local_irq_save
(XEN) After spin_debug_disable
(XEN) After time_suspend
(XEN) After li8259_suspend
(XEN) After ioapic_suspend
(XEN) DMAR_IQA_REG = 80d87c002
(XEN) DMAR_IQH_REG = 120
(XEN) DMAR_IQT_REG = 140
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

NOTE: All the messages starting with "(XEN) After" are from my changes
to the code; the rest is as is - except me commenting out
console_suspend() in power.c. I hope that helps in resolving the issue
and the panic is not just the result of a knock-on effect from
commenting out console_suspend() earlier.

Huh - I thought I had fixed this issue already.

Can you confirm exactly which version of Xen you are using (including
changeset), and perhaps compile in this patch:
The version I am using is 4.2.2 from the gentoo ebuild. Interesting enough, the log in the consoles states
(XEN) Latest ChangeSet: unavailable
I don't know what to make out of this - or is there any other way to figure out, what you are after?

The alternative would be to apply the WARN() to the 4.3.0 version I have downloaded yesterday from xenbits at http://www.xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430/287-xen-430-2/file.html (FYI: the reboot also happened there). If that helps, I'll rerun it on the 4.3.0 version. So far I have used the gentoo version as this allows me to stay within the portage system.

diff --git a/xen/drivers/passthrough/vtd/qinval.c
b/xen/drivers/passthrough/vtd/qinval.c
index 6a410d8..d023b26 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -220,6 +220,7 @@ static int queue_invalidate_wait(struct iommu *iommu,
              if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
              {
                  print_qi_regs(iommu);
+                WARN();
                  panic("queue invalidate wait descriptor was not
executed\n");
              }
              cpu_relax();
I have manually applied the patch - which was just an added
        WARN();
inbetween if I read the patch correctly; the rest was already there in 4.2.2 (and also 4.3.0 - I checked its source as well). I have attached the serial log from my 4.2.2 run to prevent line-wrap. I hope that helps.


~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

Attachment: XEN console log
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.