On Sat, Jul 16, 2022 at 07:08:03PM +0200, Brian Durant wrote: > > On 7/16/22 6:26 PM, Alexandre Ratchov wrote: > > On Sat, Jul 16, 2022 at 05:37:35PM +0200, Brian Durant wrote: > > > On 7/16/22 3:54 PM, Alexandre Ratchov wrote: > > > > On Sat, Jul 16, 2022 at 03:36:18PM +0200, Brian Durant wrote: > > > > > # mixerctl -f /dev/audioctl1 > > > > > mixerctl: /dev/audioctl1: Device not configured > > > > > > > > > > # dmesg > > > > forgot to mention: connect and power on the audio interface first ;-) > > > It was. This time I waited until boot was complete, before connecting the > > > USB cable... > > > > > ... > > > > > uhub3: port 1, set config 0 at addr 6 failed > > > uhub3: device problem, disabling port 1 > > > > > sorry, I missed these lines, this is when you connected the device, > > right? > > > > The device doesn't even attach, so not surprising it doesn't work. I > > don't know what could cause this maybe weak power? > > > > Do you have an external power source, if not could you try with it? > I think so, I was multitasking at the time... Interesting and even more > interesting. Yes, the power supply that came with the unit is plugged in and > functioning on the UMC404HD. I had a UMC202HD lying around the house, that I > just tried, which is powered through the USB cable and that works fine with > OpenBSD. Only the powered UMC404HD had issues. >
This reminds me a very basic MIDI keyboard (single usb1.1 bulk pipe) that caused the same "port disabled" problem on all of my machines. It managed to attach once every ~20 times though. IIRC, the host didn't manage to reload the the device descriptor. I tried to add delays at various places, tweak descriptor size, retry many times but this didn't help. It seems that the host did something that locks the device before the initial request to reload the descriptor. The device had a "programming mode" (hold a switch during attach), in which it always attached; this mode the keyboard was not usable, so probably not initialized. Interestingly, all the "port disabled" problems I encountered the last decade were caused by audio/MIDI equipment. The only specificity of the audio equipment is that it has big analog circuits that may consume more power and may take more time to settle. Cranking the relevant delay in usbd_new_device() didn't help. Cc'ing mpi@, just in case this rings a bell.
