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?

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list

Reply via email to