[Xen-ia64-devel] RE: Latest status about multiple domains on XEN/IPF

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Yeah, seems we're on same page now. I doubt the console issue may be also the 
reason of the blkfront connection, since unwanted delay may cause timeout. 
Still need more investigation. ;-(

Thanks,
Kevin

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年9月16日 3:24
>To: Tian, Kevin
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: Latest status about multiple domains on XEN/IPF
>
>I got it all built with all the patches.  I am now
>able to run xend.  But when I do "xm create"
>I just get as far as:
>
>xen-event-channel using irq 233
>store-evtchn = 1
>
>and then the 0+1+01 (etc) debug output.
>
>Wait... I tried launching another domain and got
>further.  Or I guess this is just delayed console
>output from the first "xm create"?
>
>It gets as far as:
>Xen virtual console successfully installed as tty0
>Event-channel device installed.
>xen_blk: Initialising virtual block device driver
>
>and then nothing else.
>
>So I tried launching some more domains (with name=xxx).
>Now I get as far as the kernel unable-to-mount-root
>panic.
>
>It's hard to tell what is working because of the
>console problems (that I see you have posted a question
>about on xen-devel).
>
>Dan
>
>> -----Original Message-----
>> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
>> Sent: Thursday, September 15, 2005 6:32 AM
>> To: Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: ipf-xen
>> Subject: RE: Latest status about multiple domains on XEN/IPF
>>
>> Hi, Dan,
>>
>>      Attached are updated xeno patch (xen patch still same),
>> but no functional enhancement actually. Some Makefile change
>> is required to build latest xenolinux.hg, though bit ugly.
>> ;-) Together with another patch I sent out for solving domU
>> crash on the mailing list (Took me most time of the day),
>> hope you can reach same point as mine:
>>      Blkfront failed to connect to xenstore, and mount root fs panic.
>>
>> Thanks,
>> Kevin
>>
>> >-----Original Message-----
>> >From: Magenheimer, Dan (HP Labs Fort Collins)
>> [mailto:dan.magenheimer@xxxxxx]
>> >Sent: 2005年9月15日 12:05
>> >To: Tian, Kevin
>> >Cc: ipf-xen
>> >Subject: RE: Latest status about multiple domains on XEN/IPF
>> >
>> >>   Thanks for comments. When I sent out the patch, I
>> >> didn't mean it as the final one and just for you to continue
>> >> debug. So the style is a bit messed, and your most comments
>> >> regarding coding style are correct. I anyway will be careful
>> >> next time even when sending out temp patch.
>> >
>> >Oh, OK.  I didn't realize it was a "continue debug" patch.
>> >
>> >> >I haven't seen any machine crashes, but I am both
>> >> >running on a different machine and exercising it
>> >> >differently.  If you have any test to reproduce
>> >> >it, please let me know.  I have noticed that
>> >> >running "hg clone" seems to reproducibly cause
>> >> >a segmentation fault... I haven't had any time
>> >> >to try to track this down.  (I think Intel has better
>> >> >hardware debugging capabilities... perhaps if you
>> >> >can reproduce this, someone on the Intel team can
>> >> >track it down?)
>> >>
>> >> I see the crash when domU was executing. Actually if only
>> >> dom0 is up, it can run safely for several days.
>> >
>> >OK.  Yes, I have seen dom0 stay up for many days
>> >too; that's why I was concerned if it was crashing.
>> >
>> >> >When I last tried, I wasn't able to get xend to
>> >> >run (lots of python errors).  It looks like you
>> >> >have gotten it to run?
>> >>
>> >> Is it possible due to the python version? The default python
>> >> version on EL3 is 2.2, and with it we saw many python errors
>> >> before. Now we're using 2.4.1.
>> >
>> >I am using 2.3.5 but that has always worked before.
>> >
>> >> One more question. Did you try xend with all my patches
>> >> applied? Without change to do_memory_ops which is explained
>> >> below, xend doesn't start since its memory reservation
>> >> request will fail.
>> >
>> >I bet that is the problem.  I haven't tried it since
>> >receiving your patch and will try it again tomorrow.
>> >
>> >> >3) In privcmd.c (other than the same comment about
>> >> >   ifdef'ing every change), why did you change the
>> >> >   direct_remap_... --> remap__... define back?
>> >> >   Was it incorrect or just a style change?  Again,
>> >> >   I am trying to change the patches to something that
>> >> >   will likely be more acceptable upstream and
>> >> >   I think we will be able to move this simple
>> >> >   define into an asm header file.  If my change
>> >> >   to your patch is broken, please let me know.
>> >>
>> >> But as you may note, two functions requires different
>> >> parameters, one for mm_struct and another for vma. So your
>> >> previous change is incorrect.
>> >
>> >No I missed that difference entirely!  Good catch!
>> >
>> >> >6) I will add your patch to hypercall.c (in the hypervisor).
>> >> >   But the comment immediately preceding concerns me...
>> >> >   are reservations implemented or not?  (I think not,
>> >> >   unless maybe they are only in VTI?)
>> >>
>> >> No, both don't handle the reservation. However the issue is
>> >> that now nr_extents is not the level 1 parameter which
>> >> previous code simply retrieves from pt_regs. Now it's a sub
>> >> field in a new reservation structure, with the later only
>> >> parameter passed in. So I have to add above logic to get
>> >> nr_extents and return result that caller wants.
>> >
>> >OK.
>> >
>> >If you have an updated patch by the end of your day,
>> >please send it and I will try it out tomorrow.
>> >
>> >Dan
>>

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel