On 2023-04-01, Paul Tagliamonte <paul...@gmail.com> wrote: > I've emailed a few lists, but so far everyone either looked the other > way quickly[0], didn't know, or didn't have time to help me out (fair > enough!)
I think it's mostly a mix of "don't know anything about it" and "know some things but not enough to give a useful reply". > I've been trying to take a library[1] I use on my Linux boxen, and coax > it into working on OpenBSD[2], and have been able to get a compiled .so > that looks good, with the exception of the USB transport. Given the This is probably the most informative reply from the previous times the subject came up: https://marc.info/?l=openbsd-tech&m=159420462501384&w=2 (I don't think anything changed in this area since then). > Either that or this is a common libusb 'gotcha' that everyone eventually > finds and patches that presents itself on OpenBSD by always locking up. OpenBSD's USB stack, especially regarding direct device access from userland, definitely has some issues that don't exist on other systems. FWIW I'm tending to run such devices on single-purpose Linux boxes now. > Everything is using USB3/xhci. That's the only bus on the system, and > this device communicates using USB3 in this case. > I've been able to set up the serial console, and get 'ddb' working well, > but I am having a hard time using it without poking myself on the sharp > bits. Is there a good way to explore the wedged system that isn't using > ddb off a serial line? Looks like 'ddb' can 'boot crash'; is there a > good workflow documented there? I don't have a kernel core handy to test but you can load a kernel into gdb (watch out for reorder_kernel; you will need to save the actual kernel that produced the core) and may be able to load the core (saved in /var/crash after booting following "boot crash") into gdb with 'target kvm $file'. Not sure if you will get better results from base or ports gdb ("egdb" binary) in this case; try the other if one doesn't work. Though I don't think it's very widely used so may have rotted. Generally I think either ddb or adding debug code seem more common, also dt(4) helps figure out some things. > 0) Is there a good place to have this conversation? I don't see > topical "usb subsystem interest group" mailing list(s) where this > may be less tedious to most of the readers. I tried ports@[7], but > I don't think that list was right either. I feel like a nunsense > posting on all these lists right now. Here or maybe tech@. Though this (libusb/direct device access from userland) is not an area in which anyone is particularly active.
