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
