WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status ---

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status --- Dom0 Crash
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Mon, 5 Jan 2009 12:29:55 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-ia64-devel@xxxxxxxxxxxxxxxxxxx" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 04 Jan 2009 20:30:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090105033216.GB32353%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20081216022138.GH11466%yamahata@xxxxxxxxxxxxx> <8FED46E8A9CA574792FC7AACAC38FE7701C7E4255D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC21C8E8F0C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090105033216.GB32353%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aclu5mFcYEaw6/4GSmyQSwBckUU07gAB4Tyg
Thread-topic: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status --- Dom0 Crash
Isaku Yamahata wrote:
> Hi. Good catch. Some comments.
> I attached two patches to fix, could you try them?
> 
> - bss.page_aligned.
>   Where is the section used?
>   grep didn't tell me. Surely x86 uses .bss.page_aligned in
>   linux/arch/[i386, x86_64]/kernel/head[-xen].S,
>   but no files unuder linux/arch/ia64/ don't use it.

You may need to check drivers/xen/core/evtchn.c, the code as following :-)
Xiantao

static int pirq_eoi_does_unmask;
static DECLARE_BITMAP(pirq_needs_eoi, ALIGN(NR_PIRQS, PAGE_SIZE * 8))
        __attribute__ ((__section__(".bss.page_aligned"), 
__aligned__(PAGE_SIZE)));



> - ia64_fast_eoi.
>   I suppose ia64_fast_eoi is used for optimization instead of
>   PHYSDEVOP_eoi. I'm not sure how much improvement it provides,
>   though. Anyway ia64_fast_eoi hypercall implementation should also
>   be updated which I overlooked when I added PHYSDEVOP_pirq_eoi_gmfn
> support. 
> 
> thanks,
> 
> On Sun, Jan 04, 2009 at 06:05:07PM +0800, Zhang, Xiantao wrote:
>> Hi, Isaku & All
>>     The attached patch should fix the weird issue.  In upstream, we
>> also find some other weird issues, for example, we can't boot dom0
>> on some platforms, and dom0 may have different behavior with
>> different initrds.  After debug, I found it should be caused by
>> incorrect setting for pirq_needs_eoi page.  There are two main
>> issues found during the debug:     
>> 1.  the related two hypercalls are not enabled in the correct way,
>> so dom0 and hypervisor doesn't have the agreement on which pirq
>> needs EOI.  
>> 2.  the page is not really linked to bss section even if this is the
>> must, so kernel deems it as memory cache and uses it for many ways,
>> and finally leads to varid issues.  
>> Thanks
>> Xiantao
>> 
>> 
>> 
>> You, Yongkang wrote:
>>>> 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
>> 
> 
> 
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel


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