Date: Sat, 17 Sep 2022 23:42:20 -0700 From: Mark Millard <marklmi@yahoo.com> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FYI: RPi4B's and such: VLI_SS_BULK_OUT_BUG quirk handling vs. VL805 (linux example) Message-ID: <D9B5E82D-2FC1-4484-9562-2A8FFEC3B997@yahoo.com> In-Reply-To: <6babc840-0efa-8e89-4273-1a835f06edb7@selasky.org> References: <34A55B2A-1351-4D9A-B5E1-536F32F5F559.ref@yahoo.com> <34A55B2A-1351-4D9A-B5E1-536F32F5F559@yahoo.com> <6babc840-0efa-8e89-4273-1a835f06edb7@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-17, at 23:05, Hans Petter Selasky <hps@selasky.org> wrote: > On 9/17/22 18:09, Mark Millard wrote: >> https://github.com/raspberrypi/linux/pull/5173 reports: >> QUOTE >> After several months back-and-forth with VIA, we have a candidate = root-cause for #4844 and a suggested fix. My known-bad pendrive now gets = written to endlessly without suffering data corruption. >> END QUOTE >> and: >> QUOTE >> usb: xhci: expand mitigations for VLI_SS_BULK_OUT_BUG quirk =E2=80=A6 = c9e051a >> The VL805 can cause data corruption if a SS Bulk OUT endpoint enters = a >> flow-control condition and there are TRBs in the transfer ring that = are >> not an integral size of wMaxPacket and the endpoint is behind one or = more >> hubs. >> This is frequently the case encountered when FAT32 filesystems are >> present on mass-storage devices with cluster sizes of 1 sector, and = the >> filesystem is being written to with an aggregate of small files. >> The initial implementation of this quirk separated TRBs that didn't >> adhere to this limitation into two - the first a multiple of = wMaxPacket >> and the second the 512-byte remainder - in an attempt to force TD >> fragments to align with packet boundaries. This reduced the incidence >> rate of data corruption but did not resolve it. >> The fix as recommended by VIA is to disable bursts if this sequence = of >> TRBs can occur. >> Limit turning off bursts to just USB mass-storage devices by = searching >> the device's configuration for an interface with a class type of >> USB_CLASS_MASS_STORAGE. >> Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> >> END QUOTE >> and the drivers/usb/host/xhci-mem.c change has the comments: >> /* >> * VL805 errata - Bulk OUT bursts to superspeed mass-storage >> * devices behind hub ports can cause data corruption with >> * non-wMaxPacket-multiple transfers. >> */ >> . . . >> /* >> * Slight hack - look at interface altsetting 0, which >> * should be the UMS bulk-only interface. If the class >> * matches, then we disable out bursts for all OUT >> * endpoints because endpoint assignments may change >> * between alternate settings. >> */ >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > Hi, >=20 > It doesn't make sense that this only applies to USB mass storage = devices. Doesn't it apply to all SuperSpeed USB BULK transfers? No clue. > What about other OS'es, do they also get a fix? >=20 I doubt that the raspberry pi folks will go around fixing non-linux kernels directly. I do see evidence of the XHCI_VLI_SS_BULK_OUT_BUG name existing in some other linux kernels and past adjustments by them to track past changes by the raspberry pi folks. However, https://elixir.bootlin.com/linux/latest/A/ident/XHCI_VLI_SS_BULK_OUT_BUG does not find the symbol so linux does not have it in general. (I'd not known of renaming or the like.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D9B5E82D-2FC1-4484-9562-2A8FFEC3B997>