From: Nathan Rossi <[email protected]>
The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and
are both affected by a known issue with the controller due to specific
behaviour when park mode is enabled in SuperSpeed host mode operation.
Under heavy USB traffic from multiple endpoints the controller will
sometimes incorrectly process transactions such that some transactions
are lost, or the controller may hang when processing transactions. When
the controller hangs it does not recover.
This issue is documented partially within the linux-imx vendor kernel
which references a Synopsys STAR number 9001415732 in commits [1] and
additional details in [2]. Those commits provide some additional
controller internal implementation specifics around the incorrect
behaviour of the SuperSpeed host controller operation when park mode is
enabled.
The summary of this issue is that the host controller can incorrectly
enter/exit park mode such that part of the controller is in a state
which behaves as if in park mode even though it is not. In this state
the controller incorrectly calculates the number of TRBs available which
results in incorrect access of the internal caches causing the overwrite
of pending requests in the cache which should have been processed but
are ignored. This can cause the controller to drop the requests or hang
waiting for the pending state of the dropped requests.
The workaround for this issue is to disable park mode for SuperSpeed
operation of the controller through the GUCTL1[17] bit. This is already
available as a quirk for the DWC3 controller and can be enabled via the
'snps,parkmode-disable-ss-quirk' device tree property.
It is possible to replicate this failure on an i.MX8MP EVK with a USB
Hub connecting 4 SuperSpeed USB flash drives. Performing continuous
small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block
devices will result in device errors initially and will eventually
result in the controller hanging.
[13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued?
[13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd
[13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
[13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2
[13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s
[13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
[13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
[13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command
[13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
[13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c
[2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b
Signed-off-by: Nathan Rossi <[email protected]>
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c9a610ba48..1264da6012 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -2072,6 +2072,7 @@ usb_dwc3_0: usb@38100000 {
phys = <&usb3_phy0>, <&usb3_phy0>;
phy-names = "usb2-phy", "usb3-phy";
snps,gfladj-refclk-lpm-sel-quirk;
+ snps,parkmode-disable-ss-quirk;
};
};
@@ -2114,6 +2115,7 @@ usb_dwc3_1: usb@38200000 {
phys = <&usb3_phy1>, <&usb3_phy1>;
phy-names = "usb2-phy", "usb3-phy";
snps,gfladj-refclk-lpm-sel-quirk;
+ snps,parkmode-disable-ss-quirk;
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 4b1ce9fc17..c6dc3ba0d4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1649,6 +1649,7 @@ usb_dwc3_0: usb@38100000 {
phys = <&usb3_phy0>, <&usb3_phy0>;
phy-names = "usb2-phy", "usb3-phy";
power-domains = <&pgc_otg1>;
+ snps,parkmode-disable-ss-quirk;
status = "disabled";
};
@@ -1680,6 +1681,7 @@ usb_dwc3_1: usb@38200000 {
phys = <&usb3_phy1>, <&usb3_phy1>;
phy-names = "usb2-phy", "usb3-phy";
power-domains = <&pgc_otg2>;
+ snps,parkmode-disable-ss-quirk;
status = "disabled";
};
---
2.42.0
Hi Nathan,
Thanks for your fix.
On Thu, Nov 2, 2023 at 5:24 AM Nathan Rossi <[email protected]> wrote:
>
> From: Nathan Rossi <[email protected]>
>
> The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and
> are both affected by a known issue with the controller due to specific
> behaviour when park mode is enabled in SuperSpeed host mode operation.
>
> Under heavy USB traffic from multiple endpoints the controller will
> sometimes incorrectly process transactions such that some transactions
> are lost, or the controller may hang when processing transactions. When
> the controller hangs it does not recover.
>
> This issue is documented partially within the linux-imx vendor kernel
> which references a Synopsys STAR number 9001415732 in commits [1] and
> additional details in [2]. Those commits provide some additional
> controller internal implementation specifics around the incorrect
> behaviour of the SuperSpeed host controller operation when park mode is
> enabled.
>
> The summary of this issue is that the host controller can incorrectly
> enter/exit park mode such that part of the controller is in a state
> which behaves as if in park mode even though it is not. In this state
> the controller incorrectly calculates the number of TRBs available which
> results in incorrect access of the internal caches causing the overwrite
> of pending requests in the cache which should have been processed but
> are ignored. This can cause the controller to drop the requests or hang
> waiting for the pending state of the dropped requests.
>
> The workaround for this issue is to disable park mode for SuperSpeed
> operation of the controller through the GUCTL1[17] bit. This is already
> available as a quirk for the DWC3 controller and can be enabled via the
> 'snps,parkmode-disable-ss-quirk' device tree property.
>
> It is possible to replicate this failure on an i.MX8MP EVK with a USB
> Hub connecting 4 SuperSpeed USB flash drives. Performing continuous
> small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block
> devices will result in device errors initially and will eventually
> result in the controller hanging.
>
> [13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued?
> [13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd
> [13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
> [13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
> [13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2
> [13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
> [13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s
> [13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
> [13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
> [13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command
> [13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
> [13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
>
> [1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c
> [2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b
It is a shame that NXP fixed it only in their vendor tree and kept
mainline with the issue.
This deserves a Fixes tag so that it can be backported to stable kernels.
Reviewed-by: Fabio Estevam <[email protected]>
Thanks
On Sun, 5 Nov 2023 at 08:30, Fabio Estevam <[email protected]> wrote:
>
> Hi Nathan,
>
> Thanks for your fix.
>
> On Thu, Nov 2, 2023 at 5:24 AM Nathan Rossi <[email protected]> wrote:
> >
> > From: Nathan Rossi <[email protected]>
> >
> > The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and
> > are both affected by a known issue with the controller due to specific
> > behaviour when park mode is enabled in SuperSpeed host mode operation.
> >
> > Under heavy USB traffic from multiple endpoints the controller will
> > sometimes incorrectly process transactions such that some transactions
> > are lost, or the controller may hang when processing transactions. When
> > the controller hangs it does not recover.
> >
> > This issue is documented partially within the linux-imx vendor kernel
> > which references a Synopsys STAR number 9001415732 in commits [1] and
> > additional details in [2]. Those commits provide some additional
> > controller internal implementation specifics around the incorrect
> > behaviour of the SuperSpeed host controller operation when park mode is
> > enabled.
> >
> > The summary of this issue is that the host controller can incorrectly
> > enter/exit park mode such that part of the controller is in a state
> > which behaves as if in park mode even though it is not. In this state
> > the controller incorrectly calculates the number of TRBs available which
> > results in incorrect access of the internal caches causing the overwrite
> > of pending requests in the cache which should have been processed but
> > are ignored. This can cause the controller to drop the requests or hang
> > waiting for the pending state of the dropped requests.
> >
> > The workaround for this issue is to disable park mode for SuperSpeed
> > operation of the controller through the GUCTL1[17] bit. This is already
> > available as a quirk for the DWC3 controller and can be enabled via the
> > 'snps,parkmode-disable-ss-quirk' device tree property.
> >
> > It is possible to replicate this failure on an i.MX8MP EVK with a USB
> > Hub connecting 4 SuperSpeed USB flash drives. Performing continuous
> > small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block
> > devices will result in device errors initially and will eventually
> > result in the controller hanging.
> >
> > [13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued?
> > [13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd
> > [13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
> > [13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
> > [13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2
> > [13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
> > [13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s
> > [13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
> > [13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
> > [13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command
> > [13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
> > [13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
> >
> > [1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c
> > [2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b
>
> It is a shame that NXP fixed it only in their vendor tree and kept
> mainline with the issue.
>
> This deserves a Fixes tag so that it can be backported to stable kernels.
The two commits that would need to be applied against would be:
Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes")
Fixes: ad37549cb5dc ("arm64: dts: imx8mq: add USB nodes")
The imx8mq one is a bit tricky since that commit occurred in the v5.1
kernel which is before the parkmode support was added to the dwc3
driver (added in v5.7, but was backported to stable kernels all the
way to v5.4). However since there is no active stable 5.1-5.3 kernels
this should be fine?
If those commits are the correct Fixes target let me know and I can
resend this change as v2 with the Fixes and your reviewed-by.
Thanks,
Nathan
>
> Reviewed-by: Fabio Estevam <[email protected]>
>
> Thanks
Hi Nathan,
On Sun, Nov 5, 2023 at 10:11 PM Nathan Rossi <[email protected]> wrote:
> The two commits that would need to be applied against would be:
>
> Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes")
> Fixes: ad37549cb5dc ("arm64: dts: imx8mq: add USB nodes")
>
> The imx8mq one is a bit tricky since that commit occurred in the v5.1
> kernel which is before the parkmode support was added to the dwc3
> driver (added in v5.7, but was backported to stable kernels all the
> way to v5.4). However since there is no active stable 5.1-5.3 kernels
> this should be fine?
Yes, they look good to me, thanks.