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