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

[Ben Guthro <ben@xxxxxxxxxx>]

Interestingly enough, just updating to the parent of this changeset,
without the hack mentioned previously seems to be enough to
suspend/resume multiple times on this machine.



On Thu, Aug 23, 2012 at 3:06 PM, Ben Guthro <ben@xxxxxxxxxx> wrote:
> 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