Re: [PATCH 0/4] usb: usbtmc: fix undersized high-speed bulk packets on xHCI

[Nicolai Buchwitz <nb@tipi-net.de>]

Hi Michal

On 21.10.2026 00:56, Michal Pecio wrote:
> [...]

>> So this looks like the better fix. How would we want it gated, a USB
>> core quirk flag per device, or per controller?
> 
> [Cc Mathias]
> 
> Good question. Do you need this fixed in stable?

Would be nice, as I've also seen other reports of this issue with
Rigol / Siglent test equipment. Otherwise I can carry it for a while
in our tree.

> 
> Depending on regression risk maybe we could get away with no quirk
> flag at all. That's what ehci and dwc2 seem to do, which means that
> hopefully no device specifies illegal packet size while using 512.

They do. dwc2 just takes usb_endpoint_maxp() as is, and ehci even does
it on purpose, see qh_make():

         /* The USB spec says that high speed bulk endpoints
          * always use 512 byte maxpacket.  But some device
          * vendors decided to ignore that, and MSFT is happy
          * to help them do so.  So now people expect to use
          * such nonconformant devices with Linux too; sigh.
          */

So I'd suspect that Windows takes it as is too.

> 
> Other possible risk is some device doesn't truly care (no transfer
> is ever large enough to matter) and works with 512, but setting its
> requested packet size (needlessly) breaks some xHCI controller.
> 
> Such devices seem not very likely to exist, though more likely than
> the former kind, so I will try to test whether such xHCI breakage is
> possible. Preliminary results are encouraging: although several of
> my HCs reject packet size of 1024 or corrupt data, 64 is accepted by
> all but one. I haven't checked for corruption yet.

Thanks for testing!

> 
> I will also see if I can figure out what Windows does in such case,
> because doing the same thing as Windows may be the safest bet.

Sounds good to me. Doing the same as ehci/dwc2 (and maybe Windows)
feels like the cleanest option. Happy to test whatever you come up
with on BCM2711 and RP1 xHCI with the three devices here.

I can also check on Windows, but I'll need to look up how, as I'm not
really familiar with Windows internals anymore.

Given Guido's reply and the USBTMC spec (the host "should not send a
zero-length packet" if the last payload is wMaxPacketSize), I'll drop
the usbtmc series and work around the Rigol ZLP issue in our test
software instead.

>> >> The Rigols still have one issue I can't work around. They split
>> >> replies over 500 bytes into several transfers, and a follow-on
>> >> transfer that ends exactly on a packet boundary never arrives. Raw
>> >> libusb shows the same, so I guess it's another firmware bug. Should
>> >> be fine for most use cases though.
>> >
>> > What exactly is the sequence of URBs you see vs would want to see?
>> 
>> The Rigols split anything over 500 bytes into two transfers:
>> 
>>    REQUEST_DEV_DEP_MSG_IN #1
>>    IN: 8 x 64 bytes (12 byte header + 500 data), then a ZLP
>>    REQUEST_DEV_DEP_MSG_IN #2
>>    IN: header + the rest
>> 
>> That works fine, unless the second transfer happens to end exactly on
>> a 64 byte boundary (e.g. 640 bytes). Then the device just never
>> answers request #2 and the first IN times out. I also tried leaving
>> the ZLP from #1 pending until after request #2. That fixes the
>> boundary case, but then the device randomly ignores request #2
>> instead (roughly 1 in 5). Raw libusb behaves the same, also with
>> maxpacket 64 in xHCI, so I'm pretty sure it's just another firmware
>> bug. What I'd want to see is simply the second transfer arriving :)
> 
> Doesn't look like any obvious xHCI problem to me. Did it also happen
> with those USB2 controllers that you used previously?

Yes, it's pre-existing and also is present on dwc2, which is what we 
used
before. Replies up to 500 + 480 bytes are fine, but as soon as the 
second
transfer ends on a 64 byte boundary it times out, and some of the
missing data shows up later as garbage in the next reply ("wrong
MsgID: 79 != 2", 79 being the 'O' of RIGOL). So that's a firmware bug,
which I can work around in our application if needed.

The only real blocker is the strict maxpacket handling in xHCI. If it
could be relaxed to what dwc2 (and ehci) already do, that would help a
lot!

> [...]

Thanks,
Nicolai