[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] RE: Multiple domains up on a bit old Rev
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |