I guess the next step is to remove your entire patch and
rerun the test to see if the problem goes away (as it
does for me). You may see about 1 out of 10 linux-builds
fail with a segmentation violation; this needs to be tracked
down (with a hardware debugger)... it was a regression that
I started seeing in July (when the first merge, vcpu_translate,
and some of the fast paths went in... I turned off the fast
paths and the problem didn't go away and haven't looked
at it since).
If the infinite loop problem goes away with no patch, try
breaking up your patch into multiple patches and see which
one provokes the problem. If you are good with scripting
(I'm not!), you might be able to catch it earlier with a script
that runs "ps" and notices if any task has used more than a
minute of CPU time.
Dan
> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> Sent: Friday, September 16, 2005 5:12 AM
> To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch
> to merge vcpu.c
>
> Dan,
> I am testing the latest xenolinux using your script,
> The first three times of building kernel is successful.
> At the fourth time, gcc seems has frozen or gotten into an
> infinite loop, and not make forward progress, just like what you saw,
> My platform is tiger4 with Madison.
>
> Thanks
> Anthony
>
> -----Original Message-----
> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
> Behalf Of Xu, Anthony
> >Sent: 2005年9月16日 11:53
> >To: Magenheimer, Dan (HP Labs Fort Collins)
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] This is the first
> patch to merge vcpu.c
> >
> >Dan,
> >
> >The build-test is very slow; I am testing the latest
> xenolinux using your script,
> >It cost 3 hours for 4 times of building.
> >
> >Thanks
> >Anthony
> >
> >>-----Original Message-----
> >>From: Magenheimer, Dan (HP Labs Fort Collins)
> [mailto:dan.magenheimer@xxxxxx]
> >>Sent: 2005年9月15日 11:53
> >>To: Xu, Anthony
> >>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>Subject: RE: [Xen-ia64-devel] [PATCH] This is the first
> patch to merge vcpu.c
> >>
> >>Script attached. It's not pretty and will need
> >>to be adapted for a different environment, but
> >>I've used the same script for a long time so
> >>that I can compare results.
> >>
> >>The privcnt lines can be removed... I can't find
> >>the source for privcnt, but it is probably the
> >>same as what I posted here:
> >>
> >>http://lists.xensource.com/archives/html/xen-devel/2005-03/m
sg00216.html
> >>
> >>> -----Original Message-----
> >>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >>> Sent: Wednesday, September 14, 2005 8:38 PM
> >>> To: Magenheimer, Dan (HP Labs Fort Collins)
> >>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch
> >>> to merge vcpu.c
> >>>
> >>> Thanks for your suggestion,
> >>> Please send me your buildlinux script, see whether I can
> reproduce it.
> >>> And I can do this stress_test before I send patch..
> >>>
> >>> Thanks
> >>> Anthony
> >>>
> >>>
> >>>
> >>> >-----Original Message-----
> >>> >From: Magenheimer, Dan (HP Labs Fort Collins)
> >>> [mailto:dan.magenheimer@xxxxxx]
> >>> >Sent: 2005年9月15日 10:18
> >>> >To: Xu, Anthony
> >>> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >Subject: RE: [Xen-ia64-devel] [PATCH] This is the first
> >>> patch to merge vcpu.c
> >>> >
> >>> >I forgot to add: This kind of bug is VERY difficult to
> >>> >find and fix because there is no obvious trigger to
> >>> >start debugging. With the segmentation fault, the
> >>> >delivery of a fault is rare enough that one can
> >>> >add code to the hypervisor to printf info when it
> >>> >happens, but if a user app (especially something
> >>> >as large and complex as a compiler) just goes into
> >>> >an infinite loop, there's nothing as a trigger.
> >>> >
> >>> >If you can reproduce this, I'd suggest breaking
> >>> >down the patch into smaller patches to see what
> >>> >specific change causes the problem. If I just
> >>> >accept the patch, it will be much harder to track
> >>> >the problem down later.
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>> >> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> >>> >> Of Magenheimer, Dan (HP Labs Fort Collins)
> >>> >> Sent: Wednesday, September 14, 2005 8:09 PM
> >>> >> To: Xu, Anthony
> >>> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >> Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch
> >>> >> to merge vcpu.c
> >>> >>
> >>> >> Yes, definitely, I run my stress test before checking
> >>> >> in any change. I do periodically see a segmentation
> >>> >> fault (ever since about mid-July when the first round
> >>> >> of merge changes went in) that I haven't been able
> >>> >> to isolate yet, but have never seen this "freeze"
> >>> >> behavior before.
> >>> >>
> >>> >> > -----Original Message-----
> >>> >> > From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >>> >> > Sent: Wednesday, September 14, 2005 7:03 PM
> >>> >> > To: Magenheimer, Dan (HP Labs Fort Collins)
> >>> >> > Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >> > Subject: RE: [Xen-ia64-devel] [PATCH] This is the first patch
> >>> >> > to merge vcpu.c
> >>> >> >
> >>> >> > Hi Dan,
> >>> >> >
> >>> >> > I haven't stress-tested my patch, my patch almost doesn't
> >>> >> > touch xeno code,
> >>> >> > I am curious have you done the same stress-test on dom0
> >>> >> > without my patch?
> >>> >> > I think we'd better setup the infrastructure ( domU and VTdom
> >>> >> > up) first, then we will come back to make all this stable.
> >>> >> >
> >>> >> > Thanks
> >>> >> > Anthony
> >>> >> >
> >>> >> > >-----Original Message-----
> >>> >> > >From: Magenheimer, Dan (HP Labs Fort Collins)
> >>> >> > [mailto:dan.magenheimer@xxxxxx]
> >>> >> > >Sent: 2005年9月14日 12:48
> >>> >> > >To: Xu, Anthony
> >>> >> > >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >> > >Subject: RE: [Xen-ia64-devel] [PATCH] This is the first
> >>> >> > patch to merge vcpu.c
> >>> >> > >
> >>> >> > >Hi Anthony --
> >>> >> > >
> >>> >> > >I tried your patch. It applies cleanly and compiles
> >>> >> > >cleanly. However, I am seeing problems when testing it.
> >>> >> > >I run a script that builds linux ten times as
> >>> >> > >a stress test. During this test, twice, gcc has
> >>> >> > >frozen or gotten into an infinite loop; I'm not
> >>> >> > >really sure other than it continues to eat up CPU
> >>> >> > >time and not make forward progress. Other times
> >>> >> > >building linux completes OK.
> >>> >> > >
> >>> >> > >Have you stress-tested the patch on your system?
> >>> >> > >I would be curious whether you can reproduce it.
> >>> >> > >I can send you my buildlinux script if you like.
> >>> >> > >
> >>> >> > >Dan
> >>> >> > >
> >>> >> > >
> >>> >> > >> -----Original Message-----
> >>> >> > >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >>> >> > >> Sent: Monday, September 12, 2005 6:28 AM
> >>> >> > >> To: Magenheimer, Dan (HP Labs Fort Collins)
> >>> >> > >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >> > >> Subject: [Xen-ia64-devel] [PATCH] This is the
> first patch to
> >>> >> > >> merge vcpu.c
> >>> >> > >>
> >>> >> > >> Dan,
> >>> >> > >> This patch is based on ver 6723. And definitely I can boot
> >>> >> > >> dom0 with this patch.
> >>> >> > >>
> >>> >> > >> Following things are done in this patch.
> >>> >> > >> 1. Merge structure pt_reg.
> >>> >> > >> 2. Though vcpu_info structure has been merged,
> non-vt domain
> >>> >> > >> used pointer vcpu->vcpu_info->arch.privregs, and vt domain
> >>> >> > >> used pointer vcpu->arch.arch_vmx.vpd, the value
> of these two
> >>> >> > >> pointers are different, that means vt and non-vt
> domain still
> >>> >> > >> use different privileged registers pages, in this case, we
> >>> >> > >> can't merge vcpu.c, so I merged these two
> pointer, and put it
> >>> >> > >> at vcpu->arch.privregs. vcpu->vcpu_info->arch.privregs and
> >>> >> > >> vcpu->arch.arch_vmx.vpd will not exist. Why put it at
> >>> >> > >> vcpu->arch.privregs? 1. There will be one less pointer
> >>> >> > >> unreferenced when accessing this privileged
> registers page.
> >>> >> > >> 2. vcpu->vcpu_info can be accessed by guest, but
> guest can't
> >>> >> > >> access privileged registers page through this
> address, guest
> >>> >> > >> can access this privileged page only through
> another special
> >>> >> > >> mapping. So there is no need to expose this
> pointer to guest
> >>> >> > >> by putting it in vcpu->vcpu_info structure. All
> accesses to
> >>> >> > >> this page is through VCPU(vcpu,y) macro,
> >>> >> > >> 3. Merged following functions.
> >>> >> > >> Vcpu_set/get_(interruption control registers from cr16
> >>> >> > >> to cr25), corresponding functions vmx_vcpu_set/get_***
> >>> >> > will not exist.
> >>> >> > >> Vcpu->arch.arch_vmx.in_service[4] will not exist, we
> >>> >> > >> will all use vcpu->arch.insvc[4]
> >>> >> > >> 4. Cleaned up some unused structure members and codes.
> >>> >> > >>
> >>> >> > >>
> >>> >> > >> Signed-off-by Anthony Xu <Anthony.xu@xxxxxxxxx>
> >>> >> > >>
> >>> >> > >> Thanks,
> >>> >> > >> Anthony
> >>> >> > >>
> >>> >> >
> >>> >>
> >>>
> >
> >_______________________________________________
> >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
|
Home