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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/