KVM crashes when using certain USB device

Commit Message

Jim Paris July 16, 2009, 7:15 a.m. UTC

Hi G,

> >> I've continued my attempts to get the HASP dongle working, but with no success:
...
> Good idea. The results from three test runs after that change are in
> the attached files. The third was done while also dumping the USB bus,
> and the output from that dump is also attached.

The gdb output here looks questionable.  Only the second trial seems
to have USB related stuff in the backtrace, so either gdb is wrong or
there's some memory corruption that is causing crashes elsewhere.
Maybe valgrind could help?

You can also add more debugging to the usb code to try to figure out
where things are going wrong.  See the attached patch for some printfs
that might help.

Try again with less memory on the guest, like -m 2048, just to reduce
possible problems with the 32-bit guest and address space.

I didn't see anything obviously wrong with the usbmon dumps you sent,
or the debugging that qemu printed out, but I'm not familiar with this
code.

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.

-jim

Comments

G July 20, 2009, 3:51 p.m. UTC | #1

On Thu, Jul 16, 2009 at 9:15 AM, Jim Paris<[e-mail]> wrote:
> Hi G,
>
>> >> I've continued my attempts to get the HASP dongle working, but with no success:
> ...
>> Good idea. The results from three test runs after that change are in
>> the attached files. The third was done while also dumping the USB bus,
>> and the output from that dump is also attached.
>
> The gdb output here looks questionable.  Only the second trial seems
> to have USB related stuff in the backtrace, so either gdb is wrong or
> there's some memory corruption that is causing crashes elsewhere.

My guess is that the usb code in kvm/qemu causes memory corruption
that is triggering these crashes. The crashes are definitely caused by
my use of the HASP HL USB dongle.

> Maybe valgrind could help?

To some extent. I've run three tests using valgrind, and there are
some messages that to me seem to indicate memory errors ("Invalid read
of size 1"). However, running with valgrind doesn't give me any core
files when it crashes.

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.

> You can also add more debugging to the usb code to try to figure out
> where things are going wrong.  See the attached patch for some printfs
> that might help.

I have applied that patch (and also uncommented the DEBUG flag).

> Try again with less memory on the guest, like -m 2048, just to reduce
> possible problems with the 32-bit guest and address space.

Done in these test runs.

Attached to this mail is a tarball containing a bunch of files. The
first and third testrun, doing things in a different order, have
output from the qemu monitor (including all debug printf()s),
valgrind, and usb sniffs generated by wireshark. The second testrun
only have qemu monitor and valgrind output. I have inserted some
comments in the qemu monitor and valgrind files, look for square
brackets at the beginning of lines to find them.

> I didn't see anything obviously wrong with the usbmon dumps you sent,
> or the debugging that qemu printed out, but I'm not familiar with this
> code.
>
> 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.

[e-mail]? 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.

Erik Rull July 20, 2009, 4:44 p.m. UTC | #2

Hi there,

try to switch to USB 1.1 - not the best way but this helped my Windows XP 
running and doing things like printing, formatting USB keys or using a 
Dongle (Aladin, I think, it's also HASP)
USB 2.0 was not really working well with KVM :-(

Best regards,

Erik


G wrote:
> On Thu, Jul 16, 2009 at 9:15 AM, Jim Paris<[e-mail]> wrote:
>> Hi G,
>>
>>>>> I've continued my attempts to get the HASP dongle working, but with no success:

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff -urN kvm-87/usb-linux.c kvm-87-debug/usb-linux.c
--- kvm-87/usb-linux.c	2009-06-23 09:32:38.000000000 -0400
+++ kvm-87-debug/usb-linux.c	2009-07-16 03:06:22.000000000 -0400
@@ -209,16 +209,21 @@ 
 
 static AsyncURB *async_alloc(void)
 {
-    return (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+    AsyncURB *aurb = (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+    dprintf("husb: allocated %p\n", aurb);
+    return aurb;
 }
 
 static void async_free(AsyncURB *aurb)
 {
+    dprintf("husb: freeing %p\n", aurb);
     qemu_free(aurb);
 }
 
 static void async_complete_ctrl(USBHostDevice *s, USBPacket *p)
 {
+    dprintf("husb: complete ctrl, host state %d len %d\n", 
+	    s->ctrl.state, s->ctrl.len);
     switch(s->ctrl.state) {
     case CTRL_STATE_SETUP:
         if (p->len < s->ctrl.len)
@@ -266,6 +271,7 @@ 
                 aurb, aurb->urb.status, aurb->urb.actual_length);
 
 	if (p) {
+	    dprintf("husb: p=%p\n", p);
             switch (aurb->urb.status) {
             case 0:
                 p->len = aurb->urb.actual_length;
@@ -280,11 +286,12 @@ 
                 p->len = USB_RET_NAK;
                 break;
             }
-
+	    dprintf("husb: completing, p->len=%d\n", p->len);
             usb_packet_complete(p);
 	}
 
         async_free(aurb);
+
     }
 }