Re: [Xen-ia64-devel] RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Thu, Mar 02, 2006 at 10:24:00AM -0700, Alex Williamson wrote:

> 
>    A little bit of data in case it sparks some debug ideas.  Enabling
> tracing in xenstored shows that the difference between the working and
> non-working case are exhibited pretty quickly.  There's definitely
> communication occurring through the mmap'd kmem page, but it's missing
> some important chunks.  For instance, here's the first few messages
> logged in the working case:
> 
> CREATE connection 0x6000000000022678
> IN  0x6000000000022678 07:15:03 DIRECTORY (device )
> OUT 0x6000000000022678 07:15:03 ERROR (ENOENT )
> IN  0x6000000000022678 07:15:03 DIRECTORY (backend )
> OUT 0x6000000000022678 07:15:03 ERROR (ENOENT )
> IN  0x6000000000022678 07:15:03 WATCH (device A000000100D20520 )
> CREATE watch 0x60000000000229a8
> OUT 0x6000000000022678 07:15:03 WATCH (OK )
> IN  0x6000000000022678 07:15:03 WATCH (backend A000000100D20500 )
> CREATE watch 0x60000000000228c8
> OUT 0x6000000000022678 07:15:03 WATCH_EVENT (device A000000100D20520 )
> OUT 0x6000000000022678 07:15:03 WATCH (OK )
> OUT 0x6000000000022678 07:15:03 WATCH_EVENT (backend A000000100D20500 )
> CREATE connection 0x6000000000022748
> IN  0x6000000000022748 07:15:03 WATCH (@introduceDomain domlist )
> CREATE watch 0x60000000000234c8
> OUT 0x6000000000022748 07:15:03 WATCH (OK )
> 
> In the failing case, I see:
> 
> CREATE connection 0x6000000000026388
> IN  0x6000000000026388 07:07:47 DIRECTORY (device )
> OUT 0x6000000000026388 07:07:47 ERROR (ENOENT )
> CREATE connection 0x60000000000265d8
> IN  0x60000000000265d8 07:07:47 WATCH (@introduceDomain domlist )
> CREATE watch 0x6000000000026d78
> OUT 0x60000000000265d8 07:07:47 WATCH (OK )
> 
> Note that only the lines dealing with A000000100D20520 are missing.

These are requests from the xenbus driver to create watches to monitor for new
devices being created.  That presumably means that either your xenbus driver
is fubar'd, or the mmap'd page is bust, as discussed earlier.

The requests that you are seeing are from xenconsoled and xend, each of which
is using the unix domain socket to talk to the store, not the shared page.

> The next absent chunk comes after about 300 lines of identical trace
> between the working and failing case.  This block is missing when it
> fails:

None of the watches are firing, because they haven't been registered.  No
surprise there.

Ewan.

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