xhci|audio (dma?) bug. RPI4

[adr <adr%sdf.org@localhost>]

Testing the new port of emacspeak I've encountered what seems to
be a bug in the xhci driver, I supposed related with dma. Opening
the audio device several times simultaneously as emacspeak does
heavily to play desktop icons makes the system eventually become
useless. It doesn't create a core dump nor enters the debugger.
The system just freeze. Connecting a serial console I finally got
some info:

[...]
[ 1007.8152401] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1007.8152401] umass0: BBB bulk-out clear stall failed, TIMEOUT
[ 1012.8353090] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1027.8655150] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1043.8957351] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1058.9259413] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1073.9561394] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1083.9962641] xhci0: xhci_set_dequeue: endpoint 0x2: timed out
[ 1089.0163262] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1099.0564513] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1099.0564513] umass0: BBB reset failed, TIMEOUT
[ 1104.0765134] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1114.1166382] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1114.1166382] umass0: BBB bulk-in clear stall failed, TIMEOUT
[ 1119.1367006] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1129.1768254] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[ 1129.1768254] umass0: BBB bulk-out clear stall failed, TIMEOUT
[ 1134.1968876] xhci0: xhci_set_dequeue: endpoint 0x0: timed out
[...]

Note that is not just the usb subsystem, I can't interact with the
system using the serial console anymore, the kernel messages are
sent to the console, that's all. First I thought that this could
be connected with the use of a usb disk for the os' filesystems,
and so be a xhci bug only, but this only happens when using emacspeak.
Using emacs alone doesn't trigger this situation. I'm not using a
usb audio card. That's why I suppose this could be a dma related
bug.

Using pulsaudio prevents this to happen (now pulseaudio is doing
the multiplexing), but then errors of this type occur:

$ paplay /usr/pkg/share/emacs/site-lisp/emacspeak/sounds/pan-chimes/warn-user.wav
ftruncate() failed: No space left on device
W: [(null)] caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.

But at least the system doesn't go down.

I've tested with other arm boards with no usb3 host controller and
I haven't found any problem jet. I could blow some dust off an old
HP laptop and give it I try, but I'm not eager to start compiling
for x86-64 and deal with whatever problems this machine could have
booting netbsd.  Could someone with another usb3 capable machine
give it a try? This could be an rpi4 only bug. I've seen changes
in the xhci code making isochronous transfers work.  Could this be
a side effect?

Regards.
adr