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 ---
# HG changeset patch
# User kaf24@xxxxxxxxxxxxxxxxxxxx
# Node ID bdc77b74bf61dd9583d3128f76cea4d8d5248f5f
# Parent 3233e7ecfa9f98616a0b5514eabf58dd56b5052b
Remove bad lines from start od script.
diff -r 3233e7ecfa9f -r bdc77b74bf61 tools/examples/xen-backend.agent
--- a/tools/examples/xen-backend.agent Thu Sep 15 07:38:53 2005
+++ b/tools/examples/xen-backend.agent Thu Sep 15 07:45:06 2005
@@ -1,7 +1,3 @@
-
-copyrev: 0000000000000000000000000000000000000000
-copy: tools/examples/backend.hotplug
-
#! /bin/sh
#ACTION=add
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
--- End Message ---
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home