> I tried 2048M (and other value), but I wasn't reproduce it.
> Hmm, does it reproduce with "dom0_mem=2048M" on all boxes which you
> tested?
Isaku/All,
This issue is really very hard to locate. Now I am a little suspecting it is
related with building process, as if changing building method, this issue is
gone too.
1, It doesn't happen to all machines. But it can be stably reproduce in our
nightly test machine with same binary.
2, When system crashing, dom0_mem is set to 2048M. And if using other memory
size, this issue disappeared too.
3, It seems happened between dom0 changeset 743~753, as it workds if we use old
built Dom0 kernel + new Xen. And the old nightly testing doesn't have issue.
4, When I try to do regression testing between 743~753, I found different build
method might cause crashing and non-crashing.
In our default building process, as stubdomain is not supported in IA64, so we
removed install-stubdom and dist-stubdom from "install:" and "dist:" lines in
main Makefile. It has been changed more than 2 months. The real compiling
command is "make -j3 >xyz_file". And the crashing issue is related with
building process.
When I do regression testing, sometimes I didn't change Makefile, but still use
"make -j3". Then the crashing is gone.
I am not sure if my suspection is possible, as it still need more trying.
Compiling Dom0 is not easy like Xen. It is costing. I would try to do more, but
maybe not so quick, as many another things need to do at the same time. If the
default compilation is okay, do you think it is worthy to do more
investigating?
Any suggestion will be much appreciated.
Best Regards,
Yongkang You
On Tuesday, December 16, 2008 10:22 AM, "Isaku Yamahata" wrote:
> On Tue, Dec 09, 2008 at 05:56:25PM +0800, You, Yongkang wrote:
>> On Monday, December 08, 2008 2:10 PM, "Isaku Yamahata" wrote:
>>
>>> On Mon, Dec 08, 2008 at 01:52:38PM +0800, Zhang, Jingke wrote:
>>>> Isaku Yamahata wrote:
>>>>> On Mon, Dec 08, 2008 at 11:31:15AM +0800, Zhang, Jingke wrote:
>>>>>> Hi Isaku,
>>>>>> We re-get the detail information from serial port, please see
>>>>>> below. Two comments add:
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>>> 1. We can be sure the Cset#18832 works well on the same
>>>>>> tiger4 machine. But we did not do regression test between 18832
>>>>>> and this 18860.
>>>>>> 2. It is strange that on another Tiger4 box, dom0 will NOT
>>>>>> crash. Do you have any idea from the serial log? Thanks!
>>>>>
>>>>> I haven't hit this crash. And Kuwamura-san's test seems that
>>>>> he haven't hit it either. Kuwamura-san, is it correct?
>>>>> Hmm... it seems to depend on hw configuration?
>>>>> I'm inclined to suspect masking/unmasking interruption race.
>>>>> event channel issues? But that's just only my very vague guess.
>>>>>
>>>>> The difference between 18832 and 18860 means the merging
>>>>> xen-unstable into xen-ia64-unstable. Looking the log, I suspect
>>>>> linux-2.6.18-xen instead of xen.
>>>>> Could you provide the linux c/s which corresponds to 18832 and
>>>>> 18860?
>>>>
>>>>
>>>> Hi Isaku,
>>>> Yes, some of our machines do not crash. I am afraid there may
>>>> be some potential issue. By testing 18832, we use linux#742.
>>>> While 18860 uses linux#753. Thanks!
>>>
>>> Thank you. Taking rough look at them those change sets doesn't seem
>>> culprit. I agree with you that this may indicate some potential
>>> bugs...
>>
>> Hi All,
>>
>> This bug is stably reproduced, if providing "dom0_mem=2048M" in
>> append option. And if setting dom0_mem to 1024M or 4096M, the
>> crashing doesn't happen.
>>
>> We tried #18869 Xen + #742 Dom0, system is okay. So the problem
>> might be in Linux tree between #742~#753
>
> I tried 2048M (and other value), but I wasn't reproduce it.
> Hmm, does it reproduce with "dom0_mem=2048M" on all boxes which you
> tested?
>
> thanks,
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home