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] Re: Please try latest xen/ia64 on xen-ia64.bkbits.n

Thinking about it, if the MCU advance is ending up as zero that suggests 
something really weird is going on...

There's only one place where it is assigned to after domain create and that's 
done by a dom0 schep_op call.  Assuming that's not being called, nothing 
should be writing data there - it's rather worrying if it's somehow ending up 
as zero :-/

Cheers,
Mark

On Friday 15 April 2005 15:22, Mark Williamson wrote:
> > Haavard -- Good work tracking this down!  Apparently
> > we need to find where the time-used is recorded... it
> > must be in the arch-dep code in x86 and hasn't made its
> > way into the equivalent ia64 code yet.
>
> Do you have a NOW() macro yet?  That'd be where I'd look.
>
> > Alternately
> > perhaps we could switch to a different default
> > scheduler?  (Since sched_bvt.c is common code, we
> > won't be able to get your change in.)
>
> It should be OK once tracked down - there's not a lot of arch dep code in
> there?
>
> > Mark -- Xen/ia64 doesn't have keyboard input (yet) so
> > the keyhandler routines don't work.  (We need a volunteer
> > with serial port expertise to work on this... and get
> > the serial input code more generalized too!  It is
> > currently a very bad hack!)
>
> I had a nasty feeling you'd say that :-(  I suppose having a dom0 op to
> invoke Xen key handlers wouldn't be a bad idea in some ways (would also be
> useful on machines with no serial line at all).
>
> Cheers,
> Mark
>
> > Dan
> >
> > > -----Original Message-----
> > > From: Mark Williamson [mailto:maw48@xxxxxxxxxxxx]
> > > Sent: Friday, April 15, 2005 8:04 AM
> > > To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > > Cc: Haavard Bjerke; Magenheimer, Dan (HP Labs Fort Collins);
> > > ipf-xen@xxxxxxxxx
> > > Subject: Re: [Xen-ia64-devel] Re: Please try latest xen/ia64
> > > on xen-ia64.bkbits.net
> > >
> > > Oh dear!  That's not nice.
> > >
> > > MCU advance is the inverse of a domain's weight in BVT.  If
> > > it's zero then the
> > > domain will always be more important than anything else :-(
> > >
> > > As far as I know this should only change if the userspace
> > > scheduler control
> > > tools request it, so it's rather weird.
> > >
> > > What happens if you invoke the "Dump runqueues" key handler
> > > on the serial line
> > > (sorry, I forget which key this is exactly).  This'll output
> > > (amongst other
> > > things) the MCU advance, the evt and the avt per domain.
> > > Might give us an
> > > idea what it thinks it's doing!
> > >
> > > Cheers,
> > > Mark
> > >
> > > On Friday 15 April 2005 12:42, Haavard Bjerke wrote:
> > > > This is what I've found out so far -
> > > >
> > > > Apparently, domU is never scheduled, because the actual
> > >
> > > (AVT) and effective
> > >
> > > > virtual times of dom0 are not increased as dom0 runs, so
> > >
> > > dom0 is always
> > >
> > > > favored by the BVT scheduler.
> > > >
> > > > The problem seems to be the inc->mcu_advance variable,
> > >
> > > which decides how
> > >
> > > > much AVT is increased per dispatch. This is initially set
> > >
> > > to MCU_ADVANCE (=
> > >
> > > > 10) in do_createdomain(), but in the scheduler, in
> > >
> > > calc_avt(), it is read
> > >
> > > > as 0, so AVT isn't increased.
> > > >
> > > > I don't understand why the inc->mcu_advance variable is
> > >
> > > changed to 0, but
> > >
> > > > when applying the following hack in sched_bvt.c:calc_avt(),
> > >
> > > domU is loading
> > >
> > > > again:
> > > >
> > > > static inline u32 calc_avt(struct exec_domain *d, s_time_t now)
> > > > {
> > > >     ...
> > > >
> > > >     if(dom1_scheduled && d->domain->id == 0){
> > > >         inf->mcu_advance = MCU_ADVANCE;
> > > >     }
> > > >
> > > >     return einf->avt + mcus * inf->mcu_advance;
> > > > }
> > > >
> > > > Håvard
> > > >
> > > > On Tue, Apr 12, 2005 at 03:51:25PM -0700, Magenheimer, Dan
> > >
> > > (HP Labs Fort
> > >
> > > Collins) wrote:
> > > > > I can confirm the latest symptoms when trying to launch
> > > > > a domU: domU gets set up but never seems to get scheduled.
> > > > > Indeed several domU's can be launched and nothing gets
> > > > > scheduled.  In all cases (for me at least), dom0 continues
> > > > > to run.
> > > > >
> > > > > I suspect that this is a softirq delivery problem similar to
> > > > > the one you (Haavard) saw and identified a fix for last week.
> > > > >
> > > > > Dan
> > > > >
> > > > > P.S. Note xen-ia64-devel list cc'ed but I haven't seen
> > > > > anyone from Intel sign up yet so have also cc'ed ipf-xen@intel
> > > > > for now.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Haavard Bjerke [mailto:havard.bjerke@xxxxxxx]
> > > > > > Sent: Tuesday, April 12, 2005 3:41 AM
> > > > > > To: Magenheimer, Dan (HP Labs Fort Collins)
> > > > > > Cc: ipf-xen@xxxxxxxxx; Haavard Bjerke; Greg Edwards;
> > >
> > > Eranian, Stephane
> > >
> > > > > > Subject: Re: Please try latest xen/ia64 on xen-ia64.bkbits.net
> > > > > >
> > > > > > It seems to be working fine here. Except, with this new
> > > > > > build, loading domU doesn't work at all; not even your
> > > > > > xenlinux26112 binary.
> > > > > >
> > > > > > This is where domU stops:
> > > > > >
> > > > > > (XEN) domain mem: type=0, attr=0x0,
> > > > > > range=[0x0000000000000000-0x0000000000000000) (0M)
> > > > > > (XEN) new_thread, done with dom_fw_setup
> > > > > > (XEN) new_thread returns
> > > > > > (XEN) current=f000000007fe0000,shared_info=f000000007fd8000
> > > > > >
> > > > > > FYI,
> > > > > > Håvard
> > > > > >
> > > > > > On Mon, Apr 11, 2005 at 03:09:54PM -0700, Magenheimer, Dan
> > > > > >
> > > > > > (HP Labs Fort Collins) wrote:
> > > > > > > I have integrated Greg Edwards' update of Xen/ia64 to
> > > > > > > use Linux 2.6.11 files, tested it, and pushed it to
> > > > > > > xen-ia64.bkbits.net/xeno-unstable-ia64.bk.
> > > > > > >
> > > > > > > NOTE that this release requires a linux-2.6.11 directory
> > > > > > > (NOT linux-2.6.11.2 or later!) where the linux-2.6.7
> > > > > > > directory was before (sister directory to
> > >
> > > xeno-unstable-ia64.bk).
> > >
> > > > > > > It is not recommended to pull this into an existing
> > > > > > > bk tree as mkbuildtree will NOT work properly.
> > > > > > > Please clone a new bk tree, run mkbuildtree, and
> > > > > > > try it out.
> > > > > > >
> > > > > > > After it gets a little mileage, I will ask Keir to pull
> > > > > > > it into the main Xen tree.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Dan
> > > > > > >
> > > > > > > P.S. Greg -- I moved the changes from common files into
> > > > > > > arch files to avoid debate.  I will fix this up later if/when
> > > > > > > the common files change.
> > > >
> > > > _______________________________________________
> > > > 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