On 07/06/10 10:41, Jan Beulich wrote:
>>>> On 06.07.10 at 01:17, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>> On 07/05/2010 03:52 PM, Joanna Rutkowska wrote:
>>> On 07/06/10 00:43, Jeremy Fitzhardinge wrote:
>>>> Do you know what's going on it in that it might be waiting
>>>> for?
>>>>
>>> No idea. I might be guessing that it would be different kernel
>>> subsystems each time -- e.g. when I'm lucky and when the apps got only
>>> "partially" locked up, I can e.g. open new tabs in Google Chrome, I can
>>> see some thumbnails of my popular websites, but without their contents.
>>> This would suggest the networking subsystem is dead, but at the same
>>> time Chrome is apparently communicating fine with the X server in the
>>> DomU (and which in turn talks fine with Dom0 over Xen shared
>>> memory/evtchanl).
>>>
>>> I experienced the above behavior also when had only one VCPU er DomU.
>>>
>>
>> I've seen similar things with just normal domain save/restore, where the
>> timer interrupt seems to be failing. Can you ssh into the domain? I
>> found that I couldn't do an interactive ssh (hung at the prompt), but a
>> non-interactive command would work, so I could cat /proc/interrupts.
>
> Did either of you try disabling the setting of sched_clock_stable in
> arch/x86/kernel/cpu/intel.c:early_init_intel()? I found this to be a
> requirement in our pv kernels (though in connection with the use of
> C-states, not with S3).
>
Before I try it -- can you explain what would be the theory behind it,
specifically how this would be related to HT? Clearly it is a HT
problem, and intuitively, I would expect this to be a Xen-side problem,
rather than DomU-side?
joanna.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|