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

[Atom2 <ariel.atom2@xxxxxxxxxx>]

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