Re: [Xen-devel] Re: DomU lockups after resume from S3 on Core i5 processors

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 07/05/2010 03:07 PM, Joanna Rutkowska wrote:
> On 07/05/10 23:28, Joanna Rutkowska wrote:
>   
>> On 07/05/10 12:38, Joanna Rutkowska wrote:
>>     
>>> I'm experiencing very reproducible DomU lockups that occur after I
>>> resume the system from an S3 sleep. Strangely this seem to happen only
>>> on my Core i5 systems (tested on two different machines), but not on
>>> older Core 2 Duo systems.
>>>
>>> Usually this causes the apps (e.g. Firefox) running in DomUs to become
>>> unresponsive, but sometimes I see that some very limited functionality
>>> of the app is still available (e.g. I can open/close Tabs in Firefox,
>>> but cannot do much anything more). Also, when I log in to the DomU via
>>> xm console, I usually can see the login prompt, can enter the username,
>>> but then the console hangs.
>>>
>>> I tried to attach to such a hanged DomU using gdbserver-xen, but when I
>>> subsequently try to attach to the server from gdb (via the target
>>> 127.0.0.1:9999 command), my gdb segfaults (how funny!).
>>>
>>> I'm running Xen 3.4.3, and fairly recent pvops0 kernel in DomU. In Dom0
>>> I run 2.6.34-xenlinux kernel (opensuse patches), but I doubt it is
>>> relevant in any way.
>>>
>>> This seems like a scheduling problem, and, because it seems to affect
>>> Core i5 processors, but not Core 2 Duos, it might have something to do
>>> with Hyperthreading perhaps?
>>>
>>>       
>> Ok, finally got the gdbsever working. This is the backtrace I get when
>> attaching to a lockedup DomU after resume:
>>
>> #0  0xffffffff810093aa in ?? ()
>> #1  0xffffffff8168be18 in ?? ()
>> #2  0xffff880003a21600 in ?? ()
>> #3  0xffffffff8100ee63 in HYPERVISOR_sched_op ()
>>     at
>> /usr/src/debug/kernel-2.6.32/linux-2.6.32.x86_64/arch/x86/include/asm/xen/hypercall.h:292
>> #4  xen_safe_halt () at arch/x86/xen/irq.c:104
>> #5  0xffffffff8100c33e in raw_safe_halt () at
>> /usr/src/debug/kernel-2.6.32/linux-2.6.32.x86_64/arch/x86/include/asm/paravirt.h:110
>> #6  xen_idle () at arch/x86/xen/setup.c:193
>> #7  0xffffffff81011cdd in cpu_idle () at arch/x86/kernel/process_64.c:143
>> #8  0xffffffff8144b997 in rest_init () at init/main.c:445
>> #9  0xffffffff81824ddc in start_kernel () at init/main.c:695
>> #10 0xffffffff818242c1 in x86_64_start_reservations
>> (real_mode_data=<value optimized out>) at arch/x86/kernel/head64.c:123
>> #11 0xffffffff81828160 in xen_start_kernel () at
>> arch/x86/xen/enlighten.c:1300
>> #12 0xffffffff838f3000 in ?? ()
>> #13 0xffffffff838f4000 in ?? ()
>> #14 0xffffffff838f5000 in ?? ()
>>
>> Any ideas?
>>
>>     
> ... and when I disabled Hyperthreading in BIOS, the problem seems to
> gone. Obviously this is not a desired solution...
>   

HT has historically been very good at flushing out race conditions which
would normally be tricky to hit on SMP systems.  I assume your domain is
single CPU?  Do you know what's going on it in that it might be waiting
for?  Is it not longer getting timer events or something?  Does the Xen
'q' debug-key make it do anything?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel