OK. I see. The patch has strange characters in it because
the file it is modifying has strange characters in it (and
the patch removes them). I will manually remove the lines.
Will Anthony's final VTI-merge patch break multiple domains?
It appears not, but it would be good if you tried it in
your environment.
Thanks,
Dan
> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Wednesday, September 21, 2005 6:11 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: Multiple domains up on a bit old Rev
>
> I don't know whether other changesets will break the multiple
> domain support, but better not do that way. If you don't want
> to apply the changeset from the mail, you can simply remove
> the leading lines from the specific file directly and then
> check in. Though it may add a new changeset there, but
> finally the hg merge can solve and there'll be no confliction
> since doing exactly same removal.
>
> Thanks,
> Kevin
>
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins)
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005年9月21日 20:08
> >To: Tian, Kevin
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: Multiple domains up on a bit old Rev
> >
> >Hi Kevin --
> >
> >The attachment you sent is garbled. It may have 16-bit
> >(non-ASCII) characters in it?
> >
> >If you point me to the xen-unstable changeset that Keir's
> >fix is in, I may grab the whole changeset and apply it,
> >which may simplify merging with xen-unstable later
> >(unless you think other parts of Keir's changeset will
> >break your multiple-domain work?)
> >
> >Dan
> >
> >> -----Original Message-----
> >> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> >> Sent: Wednesday, September 21, 2005 6:03 AM
> >> To: Magenheimer, Dan (HP Labs Fort Collins)
> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: RE: Multiple domains up on a bit old Rev
> >>
> >> I also couldn't reproduce same result on tip last night.
> >> However today I made it. No special steps compared to
> previous flow.
> >>
> >> In the start, I found out the image size calculated for xenU
> >> kernel is incorrect (By check /var/log/xend-debug.log), which
> >> made parseelfimage in control panel failed to retrieve ELF
> >> header info and thus failed in "xm create".
> >>
> >> However when I added some debug information to libxc,
> >> everything worked well then and xenU can boot to shell. Then
> >> even when I remove those debug information and roll back,
> >> xenU still worked.
> >>
> >> So I doubt there's some environmental dirty between first and
> >> second try. Of course it's also possible that some
> >> intermittent bug hides behind. Maybe you can make a fresh try
> >> tomorrow and see whether it works for you then.
> >>
> >> BTW, please add attached changeset into xen-ia64-unstable.hg,
> >> which was made by Keir last week to remove bad lines in
> >> xen-backend.agent. That's the reason why I always failed to
> >> see "physical-device" created in xenstore.
> >>
> >> Thanks,
> >> Kevin
> >>
> >> >-----Original Message-----
> >> >From: Magenheimer, Dan (HP Labs Fort Collins)
> >> [mailto:dan.magenheimer@xxxxxx]
> >> >Sent: 2005年9月21日 3:14
> >> >To: Tian, Kevin
> >> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> >Subject: RE: Multiple domains up on a bit old Rev
> >> >
> >> >I checked in the changes but am unable to reproduce your
> >> >success on tip, even with the public structure changes
> >> >propogated. I think only arch-ia64.h changed, as part
> >> >of Anthony's merge_cpu_2 patch, and arch-ia64.h gets
> >> >auto-copied when xenlinux is rebuilt so I can't explain
> >> >why it would work on rev 6857 and not on tip.
> >> >
> >> >Can you get reproduce your success on tip and, if so,
> >> >describe the steps?
> >> >
> >> >Thanks,
> >> >Dan
> >> >
> >> >> -----Original Message-----
> >> >> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> >> >> Sent: Tuesday, September 20, 2005 7:29 AM
> >> >> To: Tian, Kevin; Magenheimer, Dan (HP Labs Fort Collins)
> >> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> >> Subject: Multiple domains up on a bit old Rev
> >> >>
> >> >> OK, attached patches can make multiple domains working
> >> again, however
> >> >> with a bit old Rev upon which I'm working consistently:
> >> >>
> >> >> Xen-ia64-unstable.hg: Rev 6857
> >> >> Xenlinux-ia64: Rev 37
> >> >>
> >> >> I tried the latest xen-ia64-unstable (6867) and failed at
> >> "xm create".
> >> >> This is reasonable since there're some public structure
> >> >> changes in a few
> >> >> new changesets. Lucky thing is, that problem is easy to
> debug since
> >> >> these changes are well controlled, not like past 1.5 weeks
> >> to struggle
> >> >> with some unknown feature changes in common part. ;-)
> >> >>
> >> >> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
> >> >>
> >> >> Some interesting issues found related to two small patches:
> >> >> 1. Only "xm console 1" and "Ctrl + ]" can make xenU
> >> forward progress,
> >> >> and however still failed to connect blkback later.
> >> >> [Reason] Previous event injection on XEN/IPF
> only set vIRR bit
> >> >> when evtchn_set_pending. However with the latest xenlinux
> >> code, it's
> >> >> possible for xenlinux to set pending indication and
> selector when
> >> >> unmasking some pending event channel. This path has
> >> nothing to do with
> >> >> vIRR bit.
> >> >>
> >> >> [Solution] We should check event pending every time when
> >> >> checking pending interrupts before returning to guest.
> >> >>
> >> >> 2. After fixing first issue, nested event is injected when
> >> first event
> >> >> is still in handle with lock held. Then dead lock
> happens at end of
> >> >> "xend start".
> >> >> [Reason] Due to same logic as above, xenlinux
> may set pending
> >> >> indication and re-trigger pending event by
> >> force_evtchn_callback. On
> >> >> x86, this stub just does a dummy xen_version hypercall and
> >> >> pending event
> >> >> will be injected back when leaving hypervisor. However on IA64,
> >> >> force_evtchn_callback is incautiously made invoking
> >> evtchn_interrupt()
> >> >> directly, while the former may be called with lock held.
> >> >>
> >> >> [Solution] Just let force_evtchn_callback as
> empty for simple
> >> >> now.
> >> >>
> >> >> 3. There's one xenstore node named "physical-device",
> >> which contains
> >> >> major/minor number of device taken as disk for xenU.
> >> However that node
> >> >> is not created automatically and thus later blkfront/blkback
> >> >> communication failed since no virtual disk is found
> >> >> [Reason] Dunno yet. I sent a mail to xen-devel,
> and hope someone
> >> >> can answer the puzzle for me. ;-)
> >> >>
> >> >> [Solution] This one really took me much time,
> and below is a
> >> >> temp hack for you to try out. (Don't check-in)
> >> >>
> >> >> diff -r 7f9acc83ffcd tools/python/xen/xend/XendDomainInfo.py
> >> >> --- a/tools/python/xen/xend/XendDomainInfo.py Mon Sep 19
> >> >> 17:08:20 2005
> >> >> +++ b/tools/python/xen/xend/XendDomainInfo.py Tue Sep 20
> >> >> 21:16:13 2005
> >> >> @@ -419,7 +419,8 @@
> >> >> back = { 'type' : type,
> >> >> 'params' : params,
> >> >> 'frontend' : frontpath,
> >> >> - 'frontend-id' : "%i" % self.domid }
> >> >> + 'frontend-id' : "%i" % self.domid,
> >> >> + 'physical-device' : "%li" %
> >> >> blkdev_name_to_number(params) }
> >> >> xstransact.Write(backpath, back)
> >> >>
> >> >> return
> >> >>
> >> >> Thanks,
> >> >> Kevin
> >> >>
> >>
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home