Custom Query (16363 matches)
Results (283 - 285 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #20727 | duplicate | VirtualBox EHCI-controller doesn’t return host URB result when input length buffer is less than 0x4000 bytes | ||
| Description |
Hello! I have noticed some problems with USB 2.0 devices under VirtualBox (Beta 6.1.97 is also affected). Firstly, I’ve noticed problems with my smart card USB 2.0 reader. According to a log, each operation of reading data with input buffer more than 16*1024 bytes fails by timeout opensc-tool --send-apdu “80:40:00:00 lo1ol@lo1ol-VirtualBox:~/Desktop$ opensc-tool --send-apdu "80:40:00:00:00" Using reader with a card: Aktiv Rutoken ECP 00 00 Sending: 80 40 00 00 00 APDU transmit failed: Card removed VM’s usbmon output: ffff96d8f3308000 3398494430 S Bi:1:005:2 -115 43 < ffff96d8f3308000 3398496771 C Bi:1:005:2 0 25 = 800f0000 00000e00 00003b8b 01527574 6f6b656e 20445320 c1 ffff96d8f3308000 3398508627 S Bo:1:005:2 -115 15 = 6f050000 00000f00 00008040 000000 ffff96d8f3308000 3398510000 C Bo:1:005:2 0 15 > ffff96d8f3308000 3398510386 S Bi:1:005:2 -115 65556 < ffff96d8f3308000 3401515182 C Bi:1:005:2 -2 10 = 80000000 00000f80 0000 ffff96d9138d86c0 3401517591 S Bo:1:005:2 -115 10 = 65000000 00001000 0000 Host’s usbmon output: ffff933d38f10600 1786904293 S Bi:3:008:2 -115 43 < ffff933d38f10600 1786904357 C Bi:3:008:2 0 25 = 800f0000 00000e00 00003b8b 01527574 6f6b656e 20445320 c1 ffff933ce4e7a600 1786917684 S Bo:3:008:2 -115 15 = 6f050000 00000f00 00008040 000000 ffff933ce4e7a600 1786917732 C Bo:3:008:2 0 15 > ffff933c8eae6600 1786920019 S Bi:3:008:2 -115 16384 < ffff933c8eae6600 1786920065 C Bi:3:008:2 0 10 = 80000000 00000f80 0000 ffff933e4096c900 1789929753 S Bo:3:008:2 -115 10 = 65000000 00001000 0000 ffff933e4096c900 1789929820 C Bo:3:008:2 0 10 > As you can see, the VM’s usbmon log has status=-2, but host log is not. Also, I noticed that the input buffer length was changed. So I decided to reduce the maximal used input ccid buffer length to 0x4000(16384). This workaround helps me to resolve the problem. So I tried to reproduce the problem via a usb 2.0 flash drive and wrote the following test program, which is affected by the same bug. sources: main.c Compilation: gcc main.c -lusb-1.0
Before run:
Unmount/eject flash drive
Unload uas and usb-storage modules:
To run: sudo LIBUSB_DEBUG=4 ./a.out {idVend} {idProd} [{epOut} {epIn}]
My usbmon output was the same as for the smart card bug: ffff96d8e0037a80 676937289 S Bo:1:006:2 -115 31 = 55534243 01000000 24000000 80000612 00000024 00000000 00000000 000000 ffff96d8e0037a80 676972987 C Bo:1:006:2 0 31 > ffff96d8e0037a80 676973082 S Bi:1:006:1 -115 16385 < ffff96d8e0037a80 679977237 C Bi:1:006:1 -2 36 = 00800402 1f736d69 55464420 322e3020 53696c69 636f6e2d 506f7765 72313647 I think there is some problem with your EHCI-controller driver implementation. May you reproduce the bug by yourself, confirm and fix it? Waiting for your response! Thanks! |
|||
| #20726 | fixed | VirtualBox EHCI-controller doesn’t return host URB result when input length buffer is less than 0x4000 bytes | ||
| Description |
Hello! I have noticed some problems with USB 2.0 devices under VirtualBox (Beta 6.1.92 is also affected). Firstly, I’ve noticed problems with my smart card USB 2.0 reader. According to a log, each operation of reading data with input buffer more than 16*1024 bytes fails by timeout opensc-tool --send-apdu “80:40:00:00 lo1ol@lo1ol-VirtualBox:~/Desktop$ opensc-tool --send-apdu "80:40:00:00:00" Using reader with a card: Aktiv Rutoken ECP 00 00 Sending: 80 40 00 00 00 APDU transmit failed: Card removed VM’s usbmon output: ffff96d8f3308000 3398494430 S Bi:1:005:2 -115 43 < ffff96d8f3308000 3398496771 C Bi:1:005:2 0 25 = 800f0000 00000e00 00003b8b 01527574 6f6b656e 20445320 c1 ffff96d8f3308000 3398508627 S Bo:1:005:2 -115 15 = 6f050000 00000f00 00008040 000000 ffff96d8f3308000 3398510000 C Bo:1:005:2 0 15 > ffff96d8f3308000 3398510386 S Bi:1:005:2 -115 65556 < ffff96d8f3308000 3401515182 C Bi:1:005:2 -2 10 = 80000000 00000f80 0000 ffff96d9138d86c0 3401517591 S Bo:1:005:2 -115 10 = 65000000 00001000 0000 Host’s usbmon output: ffff933d38f10600 1786904293 S Bi:3:008:2 -115 43 < ffff933d38f10600 1786904357 C Bi:3:008:2 0 25 = 800f0000 00000e00 00003b8b 01527574 6f6b656e 20445320 c1 ffff933ce4e7a600 1786917684 S Bo:3:008:2 -115 15 = 6f050000 00000f00 00008040 000000 ffff933ce4e7a600 1786917732 C Bo:3:008:2 0 15 > ffff933c8eae6600 1786920019 S Bi:3:008:2 -115 16384 < ffff933c8eae6600 1786920065 C Bi:3:008:2 0 10 = 80000000 00000f80 0000 ffff933e4096c900 1789929753 S Bo:3:008:2 -115 10 = 65000000 00001000 0000 ffff933e4096c900 1789929820 C Bo:3:008:2 0 10 > As you can see, the VM’s usbmon log has status=-2, but host log is not. Also, I noticed that the input buffer length was changed. So I decided to reduce the maximal used input ccid buffer length to 0x4000(16384). This workaround helps me to resolve the problem. So I tried to reproduce the problem via a usb 2.0 flash drive and wrote the following test program, which is affected by the same bug. sources: main.c Compilation: gcc main.c -lusb-1.0
Before run:
Unmount/eject flash drive
Unload uas and usb-storage modules:
To run: sudo LIBUSB_DEBUG=4 ./a.out {idVend} {idProd} [{epOut} {epIn}]
My usbmon output was the same as for the smart card bug: ffff96d8e0037a80 676937289 S Bo:1:006:2 -115 31 = 55534243 01000000 24000000 80000612 00000024 00000000 00000000 000000 ffff96d8e0037a80 676972987 C Bo:1:006:2 0 31 > ffff96d8e0037a80 676973082 S Bi:1:006:1 -115 16385 < ffff96d8e0037a80 679977237 C Bi:1:006:1 -2 36 = 00800402 1f736d69 55464420 322e3020 53696c69 636f6e2d 506f7765 72313647 I think there is some problem with your EHCI-controller driver implementation. May you reproduce the bug by yourself, confirm and fix it? Waiting for your response! Thanks! |
|||
| #20721 | fixed | VBoxCreateUSBNode.sh string comparison using -eq => Fixed in SVN | ||
| Description |
Udev $attr{bDeviceClass} is a string representing a 2-digit hexadecimal value. As an example, this bluetooth adapter belongs to the 0xff device class: Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 1 bDeviceProtocol 1 bMaxPacketSize0 64 idVendor 0x0a5c Broadcom Corp. idProduct 0x21e8 BCM20702A0 Bluetooth 4.0 bcdDevice 1.12 iManufacturer 1 Broadcom Corp iProduct 2 BCM20702A0 iSerial 3 000000000000 bNumConfigurations 1 Cheers |
|||

