|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] 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 >> --- Begin Message --- _______________________________________________ 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 |