* ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
@ 2019-12-20 13:50 Rene D. Obermueller
2019-12-20 14:48 ` Mathias Nyman
0 siblings, 1 reply; 9+ messages in thread
From: Rene D. Obermueller @ 2019-12-20 13:50 UTC (permalink / raw)
To: mathias.nyman; +Cc: linux-usb
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
Hello,
I'm trying to connect a USB audio device (DJ-Tech CTRL) to my laptop
using a Linux 5.4.5 kernel (with Debian patches, but not for xhci), but
that fails with the above error message. I've tried with a number of
kernels before during the last 9 months with the same result, but didn't
get round to actually collect the debug log and make a bug report yet.
The device worked on two different computers (one Windows 10, the other
an older 4.x Linux kernel) that have USB2 ports.
I've attached dynamic debug output (module xhci_hcd =pflm) from a
connection attempt. Is there any other info I should provide or any
other tests (vanilla kernel, rc kernel or the like) I should perform?
Thanks in advance for help.
Best regards,
René
[-- Attachment #2: ctrl_debug.txt --]
[-- Type: text/plain, Size: 12329 bytes --]
[ 5055.671781] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5055.677147] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16060 bytes untransferred
[ 5055.693065] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15980 bytes untransferred
[ 5055.693098] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 14784 bytes untransferred
[ 5055.693106] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 14720 bytes untransferred
[ 5057.246468] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5057.672570] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5059.674065] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5060.286530] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5061.674672] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5062.554485] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16040 bytes untransferred
[ 5062.678505] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16004 bytes untransferred
[ 5063.295120] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.295152] xhci_hcd:xhci_alloc_virt_device:993: xhci_hcd 0000:05:00.4: Slot 9 output ctx = 0xfff33000 (dma)
[ 5063.295156] xhci_hcd:xhci_alloc_virt_device:1001: xhci_hcd 0000:05:00.4: Slot 9 input ctx = 0xffe9f000 (dma)
[ 5063.295164] xhci_hcd:xhci_alloc_virt_device:1020: xhci_hcd 0000:05:00.4: Set slot id 9 dcbaa entry 0000000065b38789 to 0xfff33000
[ 5063.332378] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5063.386123] usb 3-2.3: new full-speed USB device number 11 using xhci_hcd
[ 5063.386133] xhci_hcd:xhci_setup_addressable_virt_dev:1154: xhci_hcd 0000:05:00.4: Set root hub portnum to 2
[ 5063.386136] xhci_hcd:xhci_setup_addressable_virt_dev:1155: xhci_hcd 0000:05:00.4: Set fake root hub portnum to 2
[ 5063.386141] xhci_hcd:xhci_setup_addressable_virt_dev:1194: xhci_hcd 0000:05:00.4: udev->tt = 0000000006df9d27
[ 5063.386143] xhci_hcd:xhci_setup_addressable_virt_dev:1195: xhci_hcd 0000:05:00.4: udev->ttport = 0x3
[ 5063.386149] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.386195] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Successful setup context command
[ 5063.386200] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Op regs DCBAA ptr = 0x000000ffff7000
[ 5063.386203] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Slot ID 9 dcbaa entry @0000000065b38789 = 0x000000fff33000
[ 5063.386206] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Output Context DMA address = 0xfff33000
[ 5063.386208] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Internal device address = 0
[ 5063.386922] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4: Waiting for status stage event
[ 5063.478509] xhci_hcd:xhci_discover_or_reset_device:3746: xhci_hcd 0000:05:00.4: Resetting device with slot ID 9
[ 5063.478519] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.478578] xhci_hcd:xhci_handle_cmd_reset_dev:1279: xhci_hcd 0000:05:00.4: Completed reset device command.
[ 5063.478589] xhci_hcd:xhci_discover_or_reset_device:3787: xhci_hcd 0000:05:00.4: Can't reset device (slot ID 9) in default state
[ 5063.478592] xhci_hcd:xhci_discover_or_reset_device:3790: xhci_hcd 0000:05:00.4: Not freeing device rings.
[ 5063.478599] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.478817] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Successful setup address command
[ 5063.478823] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Op regs DCBAA ptr = 0x000000ffff7000
[ 5063.478827] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Slot ID 9 dcbaa entry @0000000065b38789 = 0x000000fff33000
[ 5063.478829] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Output Context DMA address = 0xfff33000
[ 5063.478832] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Internal device address = 9
[ 5063.498074] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Max Packet Size for ep 0 changed.
[ 5063.498078] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Max packet size in usb_device = 8
[ 5063.498081] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Max packet size in xHCI HW = 64
[ 5063.498084] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Issuing evaluate context command.
[ 5063.498090] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.498133] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4: Successful evaluate context command
[ 5063.508815] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4: Waiting for status stage event
[ 5063.511945] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4: Waiting for status stage event
[ 5063.514941] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4: Waiting for status stage event
[ 5063.517938] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4: Waiting for status stage event
[ 5063.518821] usb 3-2.3: New USB device found, idVendor=2485, idProduct=504f, bcdDevice= 2.54
[ 5063.518825] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5063.518828] usb 3-2.3: Product: CTRL
[ 5063.518830] usb 3-2.3: Manufacturer: CTRL
[ 5063.518832] usb 3-2.3: SerialNumber: CTRL
[ 5063.519100] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4: add ep 0x1, slot id 9, new drop flags = 0x0, new add flags = 0x5
[ 5063.519113] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4: add ep 0x81, slot id 9, new drop flags = 0x0, new add flags = 0xd
[ 5063.519118] xhci_hcd:xhci_check_bandwidth:2878: xhci_hcd 0000:05:00.4: xhci_check_bandwidth called for udev 00000000f9c39172
[ 5063.519123] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.519167] xhci_hcd 0000:05:00.4: ERROR: unexpected command completion code 0x11.
[ 5063.519174] xhci_hcd:xhci_reset_bandwidth:2968: xhci_hcd 0000:05:00.4: xhci_reset_bandwidth called for udev 00000000f9c39172
[ 5063.519201] usb 3-2.3: can't set config #1, error -22
[ 5063.675540] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5065.659401] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16032 bytes untransferred
[ 5065.659438] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15992 bytes untransferred
[ 5065.670966] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16060 bytes untransferred
[ 5065.676831] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5065.686932] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15980 bytes untransferred
[ 5065.686963] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 13380 bytes untransferred
[ 5066.363714] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5066.395840] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5067.678212] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5069.370006] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16044 bytes untransferred
[ 5069.370059] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16044 bytes untransferred
[ 5069.679534] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5071.680166] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5072.379855] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15960 bytes untransferred
[ 5073.681413] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5075.295816] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15940 bytes untransferred
[ 5075.304573] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15568 bytes untransferred
[ 5075.319036] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15780 bytes untransferred
[ 5075.338924] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5075.418659] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5075.675209] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16060 bytes untransferred
[ 5075.682197] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5075.690167] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15980 bytes untransferred
[ 5075.690219] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 13380 bytes untransferred
[ 5076.961369] usb 3-2.3: USB disconnect, device number 11
[ 5076.961380] xhci_hcd:xhci_check_bandwidth:2878: xhci_hcd 0000:05:00.4: xhci_check_bandwidth called for udev 00000000f9c39172
[ 5076.961659] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5077.533612] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15824 bytes untransferred
[ 5077.533644] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15940 bytes untransferred
[ 5077.683255] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5078.418644] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5079.315613] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16040 bytes untransferred
[ 5079.437420] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16004 bytes untransferred
[ 5079.684935] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5081.456512] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5081.685711] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5083.686602] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[ 5084.112833] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15932 bytes untransferred
[ 5084.476642] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16036 bytes untransferred
[ 5085.655145] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16060 bytes untransferred
[ 5085.671949] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 15980 bytes untransferred
[ 5085.671973] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 13376 bytes untransferred
[ 5085.687793] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd 0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2019-12-20 13:50 ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;) Rene D. Obermueller
@ 2019-12-20 14:48 ` Mathias Nyman
[not found] ` <d65f140c-0854-62a5-f21e-5d92f0575635@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Mathias Nyman @ 2019-12-20 14:48 UTC (permalink / raw)
To: Rene D. Obermueller, mathias.nyman; +Cc: linux-usb
On 20.12.2019 15.50, Rene D. Obermueller wrote:
> Hello,
>
> I'm trying to connect a USB audio device (DJ-Tech CTRL) to my laptop using a Linux 5.4.5 kernel (with Debian patches, but not for xhci), but that fails with the above error message. I've tried with a number of kernels before during the last 9 months with the same result, but didn't get round to actually collect the debug log and make a bug report yet.
>
> The device worked on two different computers (one Windows 10, the other an older 4.x Linux kernel) that have USB2 ports.
>
> I've attached dynamic debug output (module xhci_hcd =pflm) from a connection attempt. Is there any other info I should provide or any other tests (vanilla kernel, rc kernel or the like) I should perform?
>
0x11 is Parameter error "Asserted by a command if a Context parameter is invalid."
adding xhci tracing will show more details.
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
< plug in USB audio device, let it fail >
Send content of /sys/kernel/debug/tracing/trace
Your log shows it's related to the input context pointed to when
we issue a configure endpoint command:
[ 5063.518821] usb 3-2.3: New USB device found, idVendor=2485, idProduct=504f, bcdDevice= 2.54
[ 5063.518825] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5063.518828] usb 3-2.3: Product: CTRL
[ 5063.518830] usb 3-2.3: Manufacturer: CTRL
[ 5063.518832] usb 3-2.3: SerialNumber: CTRL
[ 5063.519100] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4: add ep 0x1, slot id 9, new drop flags = 0x0, new add flags = 0x5
[ 5063.519113] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4: add ep 0x81, slot id 9, new drop flags = 0x0, new add flags = 0xd
[ 5063.519118] xhci_hcd:xhci_check_bandwidth:2878: xhci_hcd 0000:05:00.4: xhci_check_bandwidth called for udev 00000000f9c39172
[ 5063.519123] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: // Ding dong!
[ 5063.519167] xhci_hcd 0000:05:00.4: ERROR: unexpected command completion code 0x11.
Could be any part of the input context.
(input control context, slot context, or one of the endpoint context).
xhci tracepoints will show the input control context and the slot context.
If those seem fine we might need to add a hack that just dumps everything, including all endpoint contexts
-Mathias
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
[not found] ` <d65f140c-0854-62a5-f21e-5d92f0575635@gmail.com>
@ 2019-12-23 12:14 ` Mathias Nyman
2019-12-23 22:15 ` Rene D. Obermueller
2019-12-24 15:28 ` Alan Stern
0 siblings, 2 replies; 9+ messages in thread
From: Mathias Nyman @ 2019-12-23 12:14 UTC (permalink / raw)
To: Rene D. Obermueller; +Cc: linux-usb
On 20.12.2019 17.50, Rene D. Obermueller wrote:
> Hello Mathias,
>
>
> On 20.12.19 15:48, Mathias Nyman wrote:
>
>> 0x11 is Parameter error "Asserted by a command if a Context parameter is invalid."
>>
>> adding xhci tracing will show more details.
> [...]
>> Your log shows it's related to the input context pointed to when
>> we issue a configure endpoint command:
> [...]
>>
>> Could be any part of the input context.
>> (input control context, slot context, or one of the endpoint context).
>>
>> xhci tracepoints will show the input control context and the slot context.
>> If those seem fine we might need to add a hack that just dumps everything, including all endpoint contexts
>
>
> thanks for the explanation and instructions. Attaching the trace output.
>
> I've had a brief look at the trace, and I didn't see anything that was obvious to me, but that's probably not saying much. ;)
>
The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
Host are not required to support other values. See USB2 spec section 5.8.3 for details
Maybe forcing it to one of the allowed values could work.
Does the below hack help? (untested)?
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 3b1388fa2f36..29102776baed 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1476,8 +1476,12 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
if (!usb_endpoint_xfer_isoc(&ep->desc))
err_count = 3;
/* Some devices get this wrong */
- if (usb_endpoint_xfer_bulk(&ep->desc) && udev->speed == USB_SPEED_HIGH)
- max_packet = 512;
+ if (usb_endpoint_xfer_bulk(&ep->desc) {
+ if (udev->speed == USB_SPEED_HIGH)
+ max_packet = 512;
+ if (udev->speed == USB_SPEED_FULL)
+ max_packet = 1 << (fls(clamp_val(max_packet, 8, 64)) - 1);
+ }
/* xHCI 1.0 and 1.1 indicates that ctrl ep avg TRB Length should be 8 */
if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version >= 0x100)
avg_trb_len = 8;
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2019-12-23 12:14 ` Mathias Nyman
@ 2019-12-23 22:15 ` Rene D. Obermueller
2019-12-24 15:28 ` Alan Stern
1 sibling, 0 replies; 9+ messages in thread
From: Rene D. Obermueller @ 2019-12-23 22:15 UTC (permalink / raw)
To: Mathias Nyman; +Cc: linux-usb
Hello Mathias,
On 23.12.19 13:14, Mathias Nyman wrote:
> The Maximum Packet Size of the full-speed bulk endpoint looks a bit
> suspicious (maxp 4)
>
> 12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0
> interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4
> deq 00000000fff71001
>
> For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max
> Packet sizes.
> Host are not required to support other values. See USB2 spec section
> 5.8.3 for details
thanks for the explanation!
> Maybe forcing it to one of the allowed values could work.
> Does the below hack help? (untested)?
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 3b1388fa2f36..29102776baed 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1476,8 +1476,12 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
> if (!usb_endpoint_xfer_isoc(&ep->desc))
> err_count = 3;
> /* Some devices get this wrong */
> - if (usb_endpoint_xfer_bulk(&ep->desc) && udev->speed ==
> USB_SPEED_HIGH)
> - max_packet = 512;
> + if (usb_endpoint_xfer_bulk(&ep->desc) {
I changed this line for missing closing bracket...
> + if (udev->speed == USB_SPEED_HIGH)
> + max_packet = 512;
> + if (udev->speed == USB_SPEED_FULL)
> + max_packet = 1 <<
> (fls(clamp_val(max_packet, 8, 64)) - 1);
> + }
> /* xHCI 1.0 and 1.1 indicates that ctrl ep avg TRB Length
> should be 8 */
> if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version
> >= 0x100)
> avg_trb_len = 8;
...and with the new kernel, connecting the device works [1], and lsusb
reports the device as well. [2]
Only thing that looks different on my workstation is this
- iManufacturer 1 (error)
- iProduct 2 (error)
- iSerial 3 (error)
+ iManufacturer 1
+ iProduct 2
+ iSerial 3
Now, I had connected the device after reboot with the new kernel and
went afk for 4h. When I returned, aseqdump did not show anything.
But after reconnecting the device, I can read data from it with aseqdump
and also use the device in mixxx.
I can't put my finger on why it stopped working, and I will probably
have to have a closer look at this during the next days, but at first
glance it may not be related to USB at all.
So for now I'll say the hack gets the device to work. Thank you very
much for your help!
-René
[1]
[15189.483381] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.486515] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.489512] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.492514] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.493396] usb 3-2.3: New USB device found, idVendor=2485,
idProduct=504f, bcdDevice= 2.54
[15189.493400] usb 3-2.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[15189.493402] usb 3-2.3: Product: CTRL
[15189.493404] usb 3-2.3: Manufacturer: CTRL
[15189.493406] usb 3-2.3: SerialNumber: CTRL
[15189.493683] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4:
add ep 0x1, slot id 9, new drop flags = 0x0, new add flags = 0x5
[15189.493703] xhci_hcd:xhci_add_endpoint:1917: xhci_hcd 0000:05:00.4:
add ep 0x81, slot id 9, new drop flags = 0x0, new add flags = 0xd
[15189.493709] xhci_hcd:xhci_check_bandwidth:2878: xhci_hcd
0000:05:00.4: xhci_check_bandwidth called for udev 00000000972d7af8
[15189.493716] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: //
Ding dong!
[15189.493773] xhci_hcd:xhci_dbg_trace:31: xhci_hcd 0000:05:00.4:
Successful Endpoint Configure command
[15189.493781] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: //
Ding dong!
[15189.493818] xhci_hcd:handle_tx_event:2395: xhci_hcd 0000:05:00.4:
Stopped on No-op or Link TRB for slot 9 ep 1
[15189.493828] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: //
Ding dong!
[15189.493869] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: //
Ding dong!
[15189.493918] xhci_hcd:handle_tx_event:2395: xhci_hcd 0000:05:00.4:
Stopped on No-op or Link TRB for slot 9 ep 2
[15189.493926] xhci_hcd:xhci_ring_cmd_db:282: xhci_hcd 0000:05:00.4: //
Ding dong!
[15189.497485] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.500488] xhci_hcd:process_ctrl_td:2094: xhci_hcd 0000:05:00.4:
Waiting for status stage event
[15189.564944] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd
0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[15191.568180] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd
0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[15193.571621] xhci_hcd:process_bulk_intr_td:2257: xhci_hcd
0000:05:00.4: ep 0x87 - asked for 16384 bytes, 16068 bytes untransferred
[2]
Bus 003 Device 011: ID 2485:504f
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x2485
idProduct 0x504f
bcdDevice 2.54
iManufacturer 1 (error)
iProduct 2 (error)
iSerial 3 (error)
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0053
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x40
(Missing must-be-set bit!)
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 0
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0041
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 2 External
bJackID 2
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 3
bNrInputPins 1
baSourceID( 0) 2
BaSourcePin( 0) 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 2 External
bJackID 4
bNrInputPins 1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 1
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 3
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2019-12-23 12:14 ` Mathias Nyman
2019-12-23 22:15 ` Rene D. Obermueller
@ 2019-12-24 15:28 ` Alan Stern
2020-01-02 11:20 ` Mathias Nyman
1 sibling, 1 reply; 9+ messages in thread
From: Alan Stern @ 2019-12-24 15:28 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Rene D. Obermueller, linux-usb
On Mon, 23 Dec 2019, Mathias Nyman wrote:
> The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
>
> 12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
>
> For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
> Host are not required to support other values. See USB2 spec section 5.8.3 for details
>
> Maybe forcing it to one of the allowed values could work.
> Does the below hack help? (untested)?
Is this the sort of thing we should handle in
config.c:usb_parse_endpoint()?
Even though 4 is not a valid maxpacket size for full-speed bulk
endpoints, many host controllers and hubs will handle it okay. Much
the same is true for devices that have a high-speed bulk endpoint with
maxpacket set to 1024. Should we try to treat these two errors the
same way?
Alan Stern
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2019-12-24 15:28 ` Alan Stern
@ 2020-01-02 11:20 ` Mathias Nyman
2020-01-02 15:31 ` Alan Stern
0 siblings, 1 reply; 9+ messages in thread
From: Mathias Nyman @ 2020-01-02 11:20 UTC (permalink / raw)
To: Alan Stern; +Cc: Rene D. Obermueller, linux-usb
On 24.12.2019 17.28, Alan Stern wrote:
> On Mon, 23 Dec 2019, Mathias Nyman wrote:
>
>> The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
>>
>> 12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
>>
>> For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
>> Host are not required to support other values. See USB2 spec section 5.8.3 for details
>>
>> Maybe forcing it to one of the allowed values could work.
>> Does the below hack help? (untested)?
>
> Is this the sort of thing we should handle in
> config.c:usb_parse_endpoint()?
>
> Even though 4 is not a valid maxpacket size for full-speed bulk
> endpoints, many host controllers and hubs will handle it okay. Much
> the same is true for devices that have a high-speed bulk endpoint with
> maxpacket set to 1024. Should we try to treat these two errors the
> same way?
Makes sense.
Looks like config.c:usb_parse_endpoint() shows a warning if maxpacket size is incorrect for
high-speed bulk endpoints, but leaves the maxpacket size unchanged.
If xhci is used then the xhci driver will later force the maxpacket to 512
I'm all for both checking and forcing maxpacket sizes in usb_parse_endpoint(), but
is there a risk that we break some devices that used to work. For example full-speed
bulk devices with maxpacket 4 that work fine under EHCI, but device can't handle
a new maxpacket size set to 8?
Or should we only warn in config.c if the maxpacket sizes are not according to specifications,
and leave it to the host controller drivers to force new maxpacket values?
-Mathias
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2020-01-02 11:20 ` Mathias Nyman
@ 2020-01-02 15:31 ` Alan Stern
2020-01-02 16:01 ` Mathias Nyman
0 siblings, 1 reply; 9+ messages in thread
From: Alan Stern @ 2020-01-02 15:31 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Rene D. Obermueller, linux-usb
On Thu, 2 Jan 2020, Mathias Nyman wrote:
> On 24.12.2019 17.28, Alan Stern wrote:
> > On Mon, 23 Dec 2019, Mathias Nyman wrote:
> >
> >> The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
> >>
> >> 12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
> >>
> >> For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
> >> Host are not required to support other values. See USB2 spec section 5.8.3 for details
> >>
> >> Maybe forcing it to one of the allowed values could work.
> >> Does the below hack help? (untested)?
> >
> > Is this the sort of thing we should handle in
> > config.c:usb_parse_endpoint()?
> >
> > Even though 4 is not a valid maxpacket size for full-speed bulk
> > endpoints, many host controllers and hubs will handle it okay. Much
> > the same is true for devices that have a high-speed bulk endpoint with
> > maxpacket set to 1024. Should we try to treat these two errors the
> > same way?
>
> Makes sense.
> Looks like config.c:usb_parse_endpoint() shows a warning if maxpacket size is incorrect for
> high-speed bulk endpoints, but leaves the maxpacket size unchanged.
> If xhci is used then the xhci driver will later force the maxpacket to 512
Does the driver do this because otherwise the controller will refuse to
handle the endpoint?
There are indeed high-speed devices that have a bulk endpoint with
maxpacket set to 1024; I have used some. They work okay with EHCI
because the driver and the controller will accept the invalid value.
But probably they won't work with xHCI.
> I'm all for both checking and forcing maxpacket sizes in usb_parse_endpoint(), but
> is there a risk that we break some devices that used to work. For example full-speed
> bulk devices with maxpacket 4 that work fine under EHCI, but device can't handle
> a new maxpacket size set to 8?
I haven't run across that combination before, so I don't know. Maybe
the reason it worked okay until now is because those devices never need
to perform a bulk transfer containing more than 4 bytes?
In any case, making this sort of change would definitely break the
1024-byte maxpacket devices mentioned above.
> Or should we only warn in config.c if the maxpacket sizes are not according to specifications,
> and leave it to the host controller drivers to force new maxpacket values?
I think that would be a lot safer.
Alan Stern
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2020-01-02 15:31 ` Alan Stern
@ 2020-01-02 16:01 ` Mathias Nyman
2020-01-03 9:29 ` Felipe Balbi
0 siblings, 1 reply; 9+ messages in thread
From: Mathias Nyman @ 2020-01-02 16:01 UTC (permalink / raw)
To: Alan Stern; +Cc: Rene D. Obermueller, linux-usb
On 2.1.2020 17.31, Alan Stern wrote:
> On Thu, 2 Jan 2020, Mathias Nyman wrote:
>
>> On 24.12.2019 17.28, Alan Stern wrote:
>>> On Mon, 23 Dec 2019, Mathias Nyman wrote:
>>>
>>>> The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
>>>>
>>>> 12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
>>>>
>>>> For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
>>>> Host are not required to support other values. See USB2 spec section 5.8.3 for details
>>>>
>>>> Maybe forcing it to one of the allowed values could work.
>>>> Does the below hack help? (untested)?
>>>
>>> Is this the sort of thing we should handle in
>>> config.c:usb_parse_endpoint()?
>>>
>>> Even though 4 is not a valid maxpacket size for full-speed bulk
>>> endpoints, many host controllers and hubs will handle it okay. Much
>>> the same is true for devices that have a high-speed bulk endpoint with
>>> maxpacket set to 1024. Should we try to treat these two errors the
>>> same way?
>>
>> Makes sense.
>> Looks like config.c:usb_parse_endpoint() shows a warning if maxpacket size is incorrect for
>> high-speed bulk endpoints, but leaves the maxpacket size unchanged.
>> If xhci is used then the xhci driver will later force the maxpacket to 512
>
> Does the driver do this because otherwise the controller will refuse to
> handle the endpoint?
>
> There are indeed high-speed devices that have a bulk endpoint with
> maxpacket set to 1024; I have used some. They work okay with EHCI
> because the driver and the controller will accept the invalid value.
> But probably they won't work with xHCI.
Looks like high-speed bulk endpoint maxpacket was forced to 512 to handle cases where
wMaxPacketSize was smaller than 512. Some xHC controllers apparently couldn't handle that.
This is done in a patch from 2013:
e4f47e3675e6 USB: xHCI: override bogus bulk wMaxPacketSize values
>
>> I'm all for both checking and forcing maxpacket sizes in usb_parse_endpoint(), but
>> is there a risk that we break some devices that used to work. For example full-speed
>> bulk devices with maxpacket 4 that work fine under EHCI, but device can't handle
>> a new maxpacket size set to 8?
>
> I haven't run across that combination before, so I don't know. Maybe
> the reason it worked okay until now is because those devices never need
> to perform a bulk transfer containing more than 4 bytes?
>
> In any case, making this sort of change would definitely break the
> 1024-byte maxpacket devices mentioned above.
>
>> Or should we only warn in config.c if the maxpacket sizes are not according to specifications,
>> and leave it to the host controller drivers to force new maxpacket values?
>
> I think that would be a lot safer.
Ok, lets go with that
-Mathias
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)
2020-01-02 16:01 ` Mathias Nyman
@ 2020-01-03 9:29 ` Felipe Balbi
0 siblings, 0 replies; 9+ messages in thread
From: Felipe Balbi @ 2020-01-03 9:29 UTC (permalink / raw)
To: Mathias Nyman, Alan Stern; +Cc: Rene D. Obermueller, linux-usb
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
Hi,
Mathias Nyman <mathias.nyman@linux.intel.com> writes:
>>>>> Maybe forcing it to one of the allowed values could work.
>>>>> Does the below hack help? (untested)?
>>>>
>>>> Is this the sort of thing we should handle in
>>>> config.c:usb_parse_endpoint()?
>>>>
>>>> Even though 4 is not a valid maxpacket size for full-speed bulk
>>>> endpoints, many host controllers and hubs will handle it okay. Much
>>>> the same is true for devices that have a high-speed bulk endpoint with
>>>> maxpacket set to 1024. Should we try to treat these two errors the
>>>> same way?
>>>
>>> Makes sense.
>>> Looks like config.c:usb_parse_endpoint() shows a warning if maxpacket size is incorrect for
>>> high-speed bulk endpoints, but leaves the maxpacket size unchanged.
>>> If xhci is used then the xhci driver will later force the maxpacket to 512
>>
>> Does the driver do this because otherwise the controller will refuse to
>> handle the endpoint?
>>
>> There are indeed high-speed devices that have a bulk endpoint with
>> maxpacket set to 1024; I have used some. They work okay with EHCI
>> because the driver and the controller will accept the invalid value.
>> But probably they won't work with xHCI.
>
> Looks like high-speed bulk endpoint maxpacket was forced to 512 to handle cases where
> wMaxPacketSize was smaller than 512. Some xHC controllers apparently couldn't handle that.
yeah, that's part of the USB spec. High-speed bulk endpoints must have
wMaxPacketSize of 512. Similarly for Super-speed, it must be 1024.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-01-03 9:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-20 13:50 ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;) Rene D. Obermueller
2019-12-20 14:48 ` Mathias Nyman
[not found] ` <d65f140c-0854-62a5-f21e-5d92f0575635@gmail.com>
2019-12-23 12:14 ` Mathias Nyman
2019-12-23 22:15 ` Rene D. Obermueller
2019-12-24 15:28 ` Alan Stern
2020-01-02 11:20 ` Mathias Nyman
2020-01-02 15:31 ` Alan Stern
2020-01-02 16:01 ` Mathias Nyman
2020-01-03 9:29 ` Felipe Balbi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.