On Friday, October 30, 2009 4:39 AM Jeremy Fitzhardinge wrote:
> On 10/28/09 18:14, Zhang, Xiantao wrote:
>> Jeremy Fitzhardinge wrote:
>>
>>> On 10/27/09 20:03, Zhang, Xiantao wrote:
>>>
>>>> Seems it is caused by newly-introduced
>>>> hypercall(VCPUOP_register_vcpu_time_memory_area) for setting memory
>>>> area for vcpu time. Try the following patch(Just disable
>>>> Xen_TIM_VSYSCALL) to have a try.
>>>>
>>>>
>>> Are you saying that if that hypercall hasn't been implemented it
>>> crashes? Hm, will double-check. It's certainly supposed to just
>>> fall back.
>>>
>> No. If hypervisor doesn't support the hypercall, it just
> return -ENOSYS, and dom0 can work well. But after implementing
> the hypercall in the hypervisor(Cset#20339), both dom0 and
> hypervisor all performs correpsonding actions in this case, so
> issues happen. That is to say, if disable this hypercall
> either in hypervisor or in dom0, it should work, but if enable
> both, the issue occurs. So it should be caused by incorrect
> hypercall implementation
>>
>
> It's hard to see how any bug in either the Xen or kernel code relating
> to that could cause the symptoms you're reporting, at least directly.
> Could you post the full output of the kernel boot?
>
> What is the host hardware?
The bug is found only on 64-bit system, because on 32-bit system, option
PARAVIRT_CLOCK_VSYSCALL is not selected.
We meet the dom0 crash on both Core 2 Duo and Xeon X5300 Serial platorm.
Best Regards
Jiajun
x86_64_config-2.6.31.4
Description: x86_64_config-2.6.31.4
dom0_crash.log
Description: dom0_crash.log
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home