G wrote:
> I'm not too familiar with valgrind output, I have only used it on
> smaller programs I've written myself, so I don't know what to think of
> the messages (and amount of messages; valgrind told me to use
> --error-limit=no). I do get a bit nervous from all the complaints
> about uninitialized values and byes, but maybe it's normal for an
> application of kvm's size and type.
I'd be nervous too :) Many of the complaints look harmless, but it's
probably worth fixing them to make the real bugs stand out more.
> > Even though you're having problems with -no-kvm, I suspect this is an
> > upstream qemu issue, so you should probably try the qemu list too.
>
> qemu-devel@xxxxxxxxxx? I'll try to figure out the -no-kvm issue first,
> so I can run any commands they might want me to run.
>
> And thanks for your help and suggestions so far, btw.
Here's a patch to try. I'm not familiar with the code, but it looks
like this buffer might be too small versus the packet lengths that
you're seeing, and similar definitions in hw/usb-uhci.c.
-jim
diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
--- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.000000000 -0400
+++ kvm-87/usb-linux.c 2009-07-20 19:15:35.000000000 -0400
@@ -115,7 +115,7 @@
uint16_t offset;
uint8_t state;
struct usb_ctrlrequest req;
- uint8_t buffer[1024];
+ uint8_t buffer[2048];
};
typedef struct USBHostDevice {
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
