Problem upon startup with halted USB device on RaspberryPi 4

Mon Aug 14 11:11:20 CEST 2023

Am 13.08.23 um 19:37 schrieb Michal Suchánek:
> Hello,

Hi again,

thanks for your answers!

> On Sat, Aug 12, 2023 at 08:31:56PM +0200, Massimo Pegorer wrote:
>> Hi Harry,
>>
>> Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
>> Harry.Waschkeit at conplement.de> ha scritto:
>>
>>> Hi,
>>>
>>> I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE
>>> module (EM7455) is attached via an PCIe-to-USB adapter.
>>> The boot image I use gets built by Yocto with the help of poky
>>> (kirkstone) and meta-raspberry (beside a few other layers) which
>>> incorporates U-Boot 22.01.
>>>
>>> When I apply power to the board it will come up until scanning USB
>>> devices (for potential boot devices), but then throw a BUG end reset the
>>> board.
>>
>>
>> Do you need USB boot devices? If not, I would build U-Boot without USB
>> support.

Yeah, I am aware of that possibility, thanks for your hint anyway, but ...

> 
> That would be great workaround, However, enabling a device should not
> break the board. If that's the case the driver is clearly broken.
> 
> Also rPi typically uses USB keyboard for boot-time input which makes the
> workaround not so great.

... but as Michal pointed out, the rpi - at least rpi 400 - should be 
considered to regularly use USB devices for normal operation, so 
completely disabling USB is not really an option here.

My USB knowledge is too little to point the finger on the problem but my 
guess still is that U-Boot is only using a part of Linux's USB driver 
for bringing up devices, thereby omitting some of the error handling 
which would be done in the Linux kernel in some (maybe concurrent) way.

And given the bunch of boot messages "WARN halted endpoint." with the 
patch I mentioned, chances are that the patch is either not the right 
one or at least incomplete.
But the general approach to ignore halted endpoints appears completely 
reasonable to me when it avoids a hanging of boot looping system.
I cannot tell whether there should instead be some cleverer treatment to 
get such a device running ("Reset Endpoint" from what I read), though.

Regards,
Harry

> Thanks
> 
> Michal
> 
>>
>> Massimo
>>
>>> This continues as long as the modem is unplugged.
>>> The exact error message is:
>>>
>>> scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB
>>> anyway.
>>> Unexpected XHCI event TRB, skipping... (3af519b0 00000004 13000000
>>> 02008401)
>>> BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
>>> BUG!
>>> resetting ...
>>>
>>> Some internet research brought up a patch (1) for
>>> drivers/usb/host/xhci-ring.c where halted devices simply get ignored
>>> during enumeration:
>>>
>>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>>> index acf437104a..6d995f446e 100644
>>> --- a/drivers/usb/host/xhci-ring.c
>>> +++ b/drivers/usb/host/xhci-ring.c
>>> @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl,
>>> struct xhci_ring *ep_ring,
>>> puts("WARN waiting for error on ep to be cleared\n");
>>> return -EINVAL;
>>> case EP_STATE_HALTED:
>>> - puts("WARN halted endpoint, queueing URB anyway.\n");
>>> + puts("WARN halted endpoint.\n");
>>> + return -EPIPE;
>>> case EP_STATE_STOPPED:
>>> case EP_STATE_RUNNING:
>>> debug("EP STATE RUNNING.\n");
>>>
>>> The driver file itself stems from the Linux sources, so I'm pretty sure
>>> that it is correct in that context.
>>> Even though I'm not really into USB stuff and therefore I cannot not
>>> really follow the discussion for the proposed change, in my eyes the
>>> patch could be reasonable for U-Boot nevertheless given that a) in my
>>> experience driver code is often used in a simplified way in U-Boot
>>> compared to Linux kernel, and b) it's all about board start-up only and
>>> not about full OS use with all bells, whistles and full error handling.
>>>
>>> Of course, I might be wrong while missing some important other use or
>>> corner cases, so I wanted to check here :-)
>>>
>>> At least, what I can say: with this patch I see a bunch of these warning
>>> messages but the board comes up and is usable in the end by Linux.
>>>
>>> fwiw: my internet search also showed another patch labelled in the first
>>> place "[PATCH] pi4: fix crash when issuing usb reset" (2) that didn't
>>> make it into the particular U-Boot 22.01 but was integrated right after
>>> that version in commit "Prepare v2022.04" with hash
>>> e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 (3).
>>> As I first hoped I could address my problem by just adding this patch I
>>> got promptly disappointed. The only thing I gained was to now get
>>> endless error messages followed by retries until I power-cycled the
>>> board (causing to start all over):
>>>
>>> USB XHCI 1.00
>>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB
>>> anyway.
>>> Unexpected XHCI event TRB, skipping... (3afd6b30 00000004 13000000
>>> 02008401)
>>> XHCI abort timeout
>>> WARN halted endpoint, queueing URB anyway.
>>> Unexpected XHCI event TRB, skipping... (3afd6b40 00000004 13000000
>>> 02008401)
>>> XHCI abort timeout
>>> WARN halted endpoint, queueing URB anyway.
>>> Unexpected XHCI event TRB, skipping... (3afd6b50 00000004 13000000
>>> 02008401)
>>> XHCI abort timeout
>>> WARN halted endpoint, queueing URB anyway.
>>> [...]
>>>
>>> To me it means that this specific PCIe-to-USB bridge might misbehave
>>> somehow,
>>> but the final question is: what are the odds to get that patch into
>>> official U-boot, or any other fix/quirk to make my hardware combo working?
>>>
>>> And also interesting: if I cannot hope for an upstream change, what
>>> potential risks I would have to accept when keeping my patch?
>>>
>>> Regards,
>>> Harry
>>>
>>> (1)
>>>
>>> https://linux-usb.vger.kernel.narkive.com/VW4VTVDU/patch-usb-host-xhci-fix-halted-endpoint-handling
>>> (2)
>>> https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51465@denx.de/T/
>>> (3)
>>>
>>> https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2
>>>
>>> --
>>> i.A. Harry Waschkeit
>>> Senior Embedded Engineer
>>> conplement AG
>>> Südwestpark 92
>>> 90449 Nürnberg
>>>
>>> Handelsregister: HRB 22863
>>> Registergericht: Nürnberg
>>> Vertreten durch: Britta Waligora und Thomas Wahle
>>> Vorsitzender des Aufsichtsrates: Lorenz von Schröder
>>>
>>>

-- 

#GernePerDu #CallMeByMyFirstName*

i.A. Harry Waschkeit*
Senior Embedded Engineer

*conplement AG*
Südwestpark 92
90449 Nürnberg

  Telefon IconTelefon: +49 911 25 50 976-862
Handy IconMobil:    +49 173 38 29 258

_harry.waschkeit at conplement.de
_www.conplement.de<http://www.conplement.de/>

Bild mit conplement Logo mit Claim Picture of conplement Logo with Claim
Ein Bild, um bei Klick auf das Bild zum Download eines Whitepapers zu
gelangen für das Thema "Remote-Updates für Embedded Linux Systeme"
Picture linked to a landing page to download the Whitepaper “Remote
Updates for Embedded Linux Systems”<https://hubs.ly/Q01tz75q0>

  Besuchen Sie uns auf Social Media:

LinkedIn
Link<https://www.linkedin.com/company/conplement-ag/>         Instagram
Link<https://www.instagram.com/conplementag/?hl=de>         XING
Link<https://www.xing.com/companies/conplementag/updates>

Handelsregister: HRB 22863
Registergericht: Nürnberg
Vertreten durch: Britta Waligora und Thomas Wahle
Vorsitzender des Aufsichtsrates: Lorenz von Schröder

*E-Mail Disclaimer *
Der Inhalt dieser E-Mail einschließlich aller Anhänge ist vertraulich
und ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie
nicht der vorgesehene
Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten
Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig
ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in
Verbindung zu setzen sowie die Originalnachricht zu löschen und alle
Kopien hiervon zu vernichten.
Dafür vielen Dank im Voraus.