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

[Javier Marcet <jmarcet@xxxxxxxxx>]

On Tue, Sep 25, 2012 at 4:06 PM, Konrad Rzeszutek Wilk
<konrad@xxxxxxxxxx> wrote:

>> >> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >> >>
>> >> >
>> >> > I see - so the advanced methods are not being used then
>> >
>> > You mean with the v3.5 kernel? I would think they would be used..
>> >
>> >> > This same kernel does work with Xen-4.0.x though. Is there an 
>> >> > assumption in
>> >> > the code that ties Xen-4.2 to a newer kernel?
>> >>
>> >> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>> >
>> > Huh? How so?
>>
>> I've tried adding a wbinvd() call before the halts in
>> xen/arch/x86/domain.c:default_idle and I could do full suspend and
>> resume cycle once, but a reboot later I couldn't resume anymore. Here
>
> Did you use the patch that Jan posted?
>> is the trace I get:
>
> That is a different issue. That is the kernel, while the outstanding
> issue in regards to suspend/resume is in the hypervisor.
>>
>> [  142.322778] ACPI: Preparing to enter system sleep state S3
>> [  142.723286] PM: Saving platform NVS memory
>> [  142.736453] Disabling non-boot CPUs ...
>> [  142.851387] ------------[ cut here ]------------
>> [  142.851397] WARNING: at
>> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
>> rcu_do_batch.isra.41+0x5f/0x213()
>
>
> which ought to be fixed, but lets concentrate on one thing at a time.
> If you use the patch that Jan posted, does it work? And I presume
> you also have the two out-of-tree patches to make resume work in the
> dom0?

I haven't been able to see the actual patch, I only read a description
of what it should do. Two possible places where a wbinvd() call should
be added. On the first of these two places there were already calls to
wbinvd() just before the halts. I added it to the other one, within
xen/arch/x86/domain.c:default_idle and I could complete a
suspend/resume cycle without the back trace but after rebooting I
tried it again and it failed, more than once.

I do have the other two out-of-tree patches applied, otherwise it
would break way before than now.

>> [  142.851401] Hardware name: To Be Filled By O.E.M.
>> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
>> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> iptable_filter ip_tables x_tables [last unloaded: cx25840]
>> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
>> 3.5.0-14-i7 #18~precise1
>> [  142.851469] Call Trace:
>> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
>> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
>> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
>> [  142.851504]  [<ffffffff810c687f>] ?
>> check_for_new_grace_period.isra.35+0x38/0x44
>> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
>> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
>> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
>> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
>> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
>> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
>> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
>> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
>> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
>> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
>> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
>> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
>> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
>> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
>> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
>> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
>> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
>> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
>> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
>> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
>> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
>> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
>> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
>> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
>> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
>> [  144.257229] ACPI: Low-level resume complete
>> [  144.257322] PM: Restoring platform NVS memory


-- 
Javier Marcet <jmarcet@xxxxxxxxx>

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