Hi folks! I can reliably bring OpenBSD 7.2 to a crawl (and eventually reboot) when plugging a USB3 device into my Raspberry Pi 4B's second USB3 port. At that point anything that I type on the console takes ages to echo, yet when I unplug the device from the port suddenly everything is back to normal and anything I had typed appears immediately. If I don't unplug the USB3 device then after about 90 seconds or so the RPi reboots. (In case you wondered: the RPi's first USB3 port has no issues whatsoever.)
Interestingly the system load does not go up while everything is slow
(at least according to uptime), pings to the machine however end up in
request timeouts.
Here's what I've tested so far:
- Tested this with plugging in a powered USB3 hub and a USB3 external
disk, both lead to the freeze.
- Tested RPi's second USB3 port with Raspbian, works flawlessly.
- Ran OpenBSD in VirtualBox and attached the same USB3 devices to
multiple USB3 ports, again without problems.
- Updated system to current.
- Compiled sys/arch/arm64/conf/GENERIC.MP kernel with debug flags
XHCI_DEBUG, USB_DEBUG, and UHUB_DEBUG and created a configuration
with config -p (actually I'm not sure if profiling is needed here).
- Captured dmesg output after connecting USB3 disk to first port and
disconnecting it after 10 secs.
- Rebooted.
- Captured dmesg output after connecting the same disk to second port
and disconnecting it after 10 secs.
- Rebooted.
- Captured dmesg output after connecting the same disk to second port
until machine reboots.
The dmesg logs (all three are attached) don't reveal anything obvious,
they're pretty much the same, other than different port numbers and
addresses. The only real difference is in a message from xhci with a
different change value ("xhci0: port=2 change=0x04" (port 1) vs. "xhci0:
port=3 change=0x08" (port 2)), but I'm guessing that this has something
to do with this being a different port.
My layman's root cause analysis so far:
- It's probably not the RPi hardware, otherwise it shouldn't work on
Raspbian.
- It's probably not OpenBSD's xhci / usb / uhub implementation,
otherwise it shouldn't work in the VM.
Unfortunately I don't have a second RPi to verify whether my board is
damaged, but things working fine on Raspbian seems to indicate that the
hardware itself is alright. That's why I decided to post this here on
the arm mailing list because now I'm thinking that it has to be
something that's specific to arm64 and / or RPi. (Obviously this might
just not be that easy to conclude would love to hear what else it
could be.)
Please excuse any dumb questions or naive assumptions, this is my first
time running OpenBSD (or any BSD for that matter) and my first time
working with an RPi, so all of this is fairly new to me. But I'm
certainly excited to find out more and figure this out, hopefully with
your help, and I'm not afraid to get my hands dirty. :-P
My question at this point is: how do I proceed from here? How can I
further isolate the issue? I could turn on more kernel debug statements,
maybe generate some kernel dumps? Hit it with ddb? How do I figure out
what causes the system to slow down?
Thanks so much for reading this wall of text!
Cheers,
Torben
PS: By way of introduction ... my first browser was Netscape 2 when web
sites were still gray. ;-) Back in the day I worked with various Linux
distros, privately (Slackware (from CD!), SuSE, Debian) and
professionally (Red Hat Enterprise Linux). Never got around to BSD, but
now that I've tried out OpenBSD I'm really loving it. Everything seems
so pure and well thought-out, reduced to the max ... it's exciting. :)
dmesg-port1
Description: Binary data
dmesg-port2
Description: Binary data
dmesg-port2-until-reboot
Description: Binary data
