On Thu, Jul 20, 2006 at 04:14:49PM -0400, Peter Vetere wrote:
> Ok, I had a chance to run libvirt through the debugger as you asked.
> Here's what I got back:
>
> After the first ioctl:
>
> (gdb) ptype hc
> type = struct privcmd_hypercall {
> __u64 op;
> __u64 arg[5];
> }
> (gdb) print hc.op
> $6 = 17
> (gdb) print cmd
> $7 = 3166208
> (gdb) print ret
> $8 = -1
okay, failure with the new hypercall structure, that's normal.
> Then, after the second ioctl:
>
> (gdb) ptype old_hc
> type = struct old_hypercall_struct {
> long unsigned int op;
> long unsigned int arg[5];
> }
> (gdb) print old_hc.op
> $11 = 17
> (gdb) print cmd
> $12 = 1593344
> (gdb) print ret
> $13 = 196608
>
> The second ioctl appears to succeed. One additional item of note is
And here that succeed, now I would have to find why subsequent
hypercall are failing even though libvirt detected it was the old
interface.
> that I am running code that was compiled against xen 3.0.2, but is
> running on 3.0.1. This may be part of the problem.
Well if it was compiled against 3.0.1 that would not have changed
I guess but it's another thing to test.
> If there are any other quick tests you'd like me to run, just let me know.
I'm afraid now that the easy potential error has been dismissed, it will
be a real debug needed to find out why other hypercalls are failing.
Best is probably to bugzilla this and add a pointer to this thread for
reference (the recompilation against 3.0.1 should be tested too :-)
thanks again,
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/