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

Re: [Xen-devel] Xen4.2 S3 regression?



No such luck.

Panic below:

(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) ----[ Xen-4.2.0-rc3-pre  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c48016773e>] irq_complete_move+0x42/0xb4
(XEN) RFLAGS: 0000000000010086   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff830148a81880   rcx: 0000000000000001
(XEN) rdx: ffff82c480301e48   rsi: 0000000000000028   rdi: ffff830148a81880
(XEN) rbp: ffff830148a77d80   rsp: ffff830148a77d50   r8:  0000000000000004
(XEN) r9:  ffff82c3fffff000   r10: ffff82c4803027c0   r11: 0000000000000246
(XEN) r12: 0000000000000018   r13: ffff830148a818a4   r14: 0000000000000000
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000001026b0
(XEN) cr3: 00000000aa2c5000   cr2: 000000000000007c
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff830148a77d50:
(XEN)    0000000000000086 ffff830148a809a4 0000000000000000 0000000000000001
(XEN)    ffff830148a77d80 ffff830148ae2620 ffff830148a77da0 ffff82c480144013
(XEN)    ffff830148a81880 0000000000000018 ffff830148a77e10 ffff82c4801696b6
(XEN)    0000000000000086 00000001030d8ac4 0000000000000001 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000202 0000000000000010
(XEN)    ffff82c480302938 0000000000000001 0000000000000001 ffff82c480302938
(XEN)    ffff830148a77e70 ffff82c48017e132 0000001048a77e70 ffff82c480302930
(XEN)    ffff82c480302938 0000000000000001 000000010115fa86 0000000000000003
(XEN)    ffff830148a77f18 0000000000000001 ffffffffffffffff ffff830148ac3080
(XEN)    ffff830148a77e80 ffff82c4801013e3 ffff830148a77ea0 ffff82c480125fb6
(XEN)    ffff830148ac30c0 ffff830148ac30f0 ffff830148a77ec0 ffff82c48012753e
(XEN)    ffff82c4801256aa ffff830148ac3110 ffff830148a77ef0 ffff82c4801278a9
(XEN)    00000000ffffffff ffff830148a77f18 ffff830148a77f18 00000008030d8ac4
(XEN)    ffff830148a77f10 ffff82c48015888d ffff8300aa303000 ffff8300aa303000
(XEN)    ffff830148a77e10 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffffffff81aafda0 ffff88003976df10 ffff88003976dfd8 0000000000000246
(XEN)    00000000deadbeef 0000000000000000 aaaaaaaaaaaaaaaa 0000000000000000
(XEN)    ffffffff8100130a 00000000deadbeef 00000000deadbeef 00000000deadbeef
(XEN)    0000010000000000 ffffffff8100130a 000000000000e033 0000000000000246
(XEN)    ffff88003976def8 000000000000e02b d0354dcf5bcd9824 9ea5d0ef618deca5
(XEN) Xen call trace:
(XEN)    [<ffff82c48016773e>] irq_complete_move+0x42/0xb4
(XEN)    [<ffff82c480144013>] dma_msi_mask+0x1d/0x49
(XEN)    [<ffff82c4801696b6>] fixup_irqs+0x19b/0x2ff
(XEN)    [<ffff82c48017e132>] __cpu_disable+0x337/0x37e
(XEN)    [<ffff82c4801013e3>] take_cpu_down+0x43/0x4a
(XEN)    [<ffff82c480125fb6>] stopmachine_action+0x8a/0xb3
(XEN)    [<ffff82c48012753e>] do_tasklet_work+0x8d/0xc7
(XEN)    [<ffff82c4801278a9>] do_tasklet+0x6b/0x9b
(XEN)    [<ffff82c48015888d>] idle_loop+0x67/0x71
(XEN)
(XEN) Pagetable walk from 000000000000007c:
(XEN)  L4[0x000] = 0000000148adf063 ffffffffffffffff
(XEN)  L3[0x000] = 0000000148ade063 ffffffffffffffff
(XEN)  L2[0x000] = 0000000148add063 ffffffffffffffff
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 000000000000007c
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Thu, Aug 23, 2012 at 2:54 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/08/12 19:03, Ben Guthro wrote:
>
> I did some more bisecting here, and I came up with another changeset
> that seems to be problematic, Re: IRQs
>
> After bisecting the problem discussed earlier in this thread to the
> changeset below,
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/0695a5cdcb42
>
>
> I worked past that issue by the following hack:
>
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1103,7 +1103,7 @@ void evtchn_destroy_final(struct domain *d)
>  void evtchn_move_pirqs(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> -    const cpumask_t *mask = cpumask_of(v->processor);
> +    //const cpumask_t *mask = cpumask_of(v->processor);
>      unsigned int port;
>      struct evtchn *chn;
>
> @@ -1111,7 +1111,9 @@ void evtchn_move_pirqs(struct vcpu *v)
>      for ( port = v->pirq_evtchn_head; port; port = chn->u.pirq.next_port )
>      {
>          chn = evtchn_from_port(d, port);
> +#if 0
>          pirq_set_affinity(d, chn->u.pirq.irq, mask);
> +#endif
>      }
>      spin_unlock(&d->event_lock);
>  }
>
>
> This seemed to work for this rather old changeset, but it was not
> sufficient to fix it against the 4.1, or unstable trees.
>
> I further bisected, in combination with this hack, and found the
> following changeset to also be problematic:
>
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c2cb776a5365
>
>
> That is, before this change I could resume reliably (with the hack
> above) - and after I could not.
> This was surprising to me, as this change also looks rather innocuous.
>
> And by the looks of that changeset, the logic in fixup_irqs() in irq.c
> was changed.
>
> Jan: The commit message says "simplify operations [in] a few cases".
> Was the change in fixup_irqs() deliberate?
>
> ~Andrew
>
>
> Ben: Could you test the attached patch?  It is for unstable and undoes the
> logical change to fixup_irqs()
>
> ~Andrew
>
>
> Naturally, backing out this change seems to be non-trivial against the
> tip, since so much around it has changed.
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
>
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com

_______________________________________________
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®.