Problem upon startup with halted USB device on RaspberryPi 4

Problem upon startup with halted USB device on RaspberryPi 4

[Harry Waschkeit]

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.
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

Problem upon startup with halted USB device on RaspberryPi 4

[Harry Waschkeit]

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.
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

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Massimo Pegorer]

Hi Harry,

Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
Harry.Waschkeit@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.

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
>
>

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Michal Suchánek]

Hello,

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@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.

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.

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
> >
> >

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Harry Waschkeit]

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@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@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.

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Massimo Pegorer]

Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit <
Harry.Waschkeit@conplement.de> ha scritto:

> 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@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.
>

Of course, mine is just a workaround, nothing more. To make hardware combo
working, and just for specific use case (if I properly understood). Not for
typical
usage of rPi. About the driver: can be broken, or the root cause can be the
PCIe-to-USB bridge misbehaving, or both.

> Also rPi typically uses USB keyboard for boot-time input which makes the
> > workaround not so great.


For U-Boot booting phase, or later on for Linux or other OS boot phase? I do
not know too much about this specific board.


> ... 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.
>

Disabling USB support in U-Boot (via defconfig) would not affect Linux (or
other OS) USB functions in any way, if this is what you are concerning about
with "completely disabling USB".

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.
>

I suggest to address this email also directly to maintainers:

./scripts/get_maintainer.pl drivers/usb/host/xhci-ring.c
Bin Meng <bmeng.cn@gmail.com> (maintainer:USB xHCI)
Marek Vasut <marex@denx.de> (maintainer:USB)
u-boot@lists.denx.de (open list)

Regards,
Massimo

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@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.
>
>
>

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Harry Waschkeit]

Am 15.08.23 um 13:49 schrieb Massimo Pegorer:
> 
> 
> Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit 
> <Harry.Waschkeit@conplement.de <mailto:Harry.Waschkeit@conplement.de>> 
> ha scritto:
> 
>     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@conplement.de
>     <mailto:Harry.Waschkeit@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.
> 
> 
> Of course, mine is just a workaround, nothing more. To make hardware combo
> working, and just for specific use case (if I properly understood). Not 
> for typical
> usage of rPi. About the driver: can be broken, or the root cause can be the
> PCIe-to-USB bridge misbehaving, or both.
> 
>      > Also rPi typically uses USB keyboard for boot-time input which
>     makes the
>      > workaround not so great.
> 
> 
> For U-Boot booting phase, or later on for Linux or other OS boot phase? I do
> not know too much about this specific board.
> 
>     ... 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.
> 
> 
> Disabling USB support in U-Boot (via defconfig) would not affect Linux (or
> other OS) USB functions in any way, if this is what you are concerning about
> with "completely disabling USB".
> 
>     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.
> 
> 
> I suggest to address this email also directly to maintainers:
> 
> ./scripts/get_maintainer.pl <http://get_maintainer.pl> 
> drivers/usb/host/xhci-ring.c
> Bin Meng <bmeng.cn@gmail.com <mailto:bmeng.cn@gmail.com>> 
> (maintainer:USB xHCI)
> Marek Vasut <marex@denx.de <mailto:marex@denx.de>> (maintainer:USB)
> u-boot@lists.denx.de <mailto:u-boot@lists.denx.de> (open list)

yes, thanks for the hint, I should have done this right from the start ...

@Bin and @Marek: even though I decided to deactivate USB in my u-boot 
for the time being, could you please have a look at my observations and 
give me your thoughts about whether and how this problem will be 
addressed in future?

Thanks in advance! :-)

Regards,
Harry

> Regards,
> Massimo
> 
>     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 <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/ <https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51465@denx.de/T/>
>      >>> (3)
>      >>>
>      >>>
>     https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 <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