Quoting Jimi Xenidis <[EMAIL PROTECTED]>:
I cannot how embarrassed I am by this.
watching evtchn's fly everywhere seen the wrong one get delivered and
the right one go no where and the whole time I was swapping the 2
Glad you caught it. :)
anyway, using the two files from:
Using the command:
$ xm create -c dom1
you should be able to boot a DomU and see its output, all the way until
it says it cannot find its rootfs.
Unfortunately this isn't working for me: my output stops after
PID hash table entries: 512 (order: 9, 4096 bytes)
When I bang keys, I can see events going on dom0 evtchn 10/domU evtchn
2: dom0/10 sends an event to domU/2 (presumably to notify domU of the
input), and domU/2 sends an event to dom0/10 (presumably to notify
dom0 that there is new console output to display). Strace on the "xm
console" process seems to confirm that the incoming event does not
wake xm console from its select() call.
I'm pretty sure I've rebuilt/reinstalled the various components
cleanly, twice. Could there be an outstanding diff still?
IBM Linux Technology Center
Xen-ppc-devel mailing list