I tried to re-attach the ure interface with /bin/netstart, but it hung. I didn’t think about starting it with ‚-x‘, so I couldn’t see where it stopped. I will do that next time.
Cannot see any vital info in /var/log/messages: Jan 13 13:20:30 dns2 /bsd: ure0: usb error on tx: IN_PROGRESS Jan 13 13:20:30 dns2 /bsd: usb_insert_transfer: xfer=0xffffff8003c6c360 not free Jan 13 13:20:30 dns2 /bsd: dwc2_softintr: xfer status = NOT_STARTED Jan 13 13:20:30 dns2 last message repeated 3 times Jan 13 13:49:37 dns2 slaacd[94415]: sendmsg: Network is down Jan 13 13:49:46 dns2 last message repeated 2 times Jan 13 14:04:12 dns2 syslogd[20278]: start Jan 13 14:04:12 dns2 /bsd: OpenBSD 7.8 (CUSTOM.MP) #0: Wed Dec 31 00:52:09 CET 2025 Thanks, Andy > Am 09.01.2026 um 21:49 schrieb Marcus Glocker <[email protected]>: > > OK, thanks for testing this. Then the device, or the controller, > stop operating, and the scheduled transfers remain NOT_STARTED. > > The NetBSD dwc2 driver will skip such transfers: > > TAILQ_FOREACH_SAFE(dxfer, &sc->sc_complete, xnext, next) { > if (!usbd_xfer_trycomplete(&dxfer->xfer)) > /* > * The hard interrput handler decided to > * complete the xfer, and put it on sc_complete > * to pass it to us in the soft interrupt > * handler, but in the time between hard > * interrupt and soft interrupt, the xfer was > * aborted or timed out and we lost the race. > */ > continue; > KASSERT(dxfer->xfer.ux_status == USBD_IN_PROGRESS); > > If this condition occurs, and you detach/re-attach the ure device, > will it start operating again, or does it remain broken? > >>> Am 28.12.2025 um 22:08 schrieb Marcus Glocker <[email protected]>: >>> >>> On Tue, Dec 23, 2025 at 10:11:00PM +0100, Schuh Andreas wrote: >>> >>>> Machine still panics with the patch: >>>> >>>> ddb{0}> show panic >>>> *cpu0: kernel diagnostic assertion "dxfer->xfer.status == >>>> USBD_IN_PROGRESS" fai >>>> led: file "/usr/src/sys/dev/usb/dwc2/dwc2.c", line 315 >>> >>> OK, pity. Then the xfer status must be something else than >>> USBD_CANCELLED, USBD_TIMEOUT, or USBD_IN_PROGRESS. Maybe USBD_STALLED. >>> Can you please try this diff? It's probably still not the solution to >>> the issue, but at least it should give us more clearness about the xfer >>> status. Again, it should prevent the panic, and print the xfer status >>> in your dmesg output. >>> >>> Thanks, >>> Marcus >>> >>> >>> Index: sys/dev/usb/dwc2/dwc2.c >>> =================================================================== >>> RCS file: /cvs/src/sys/dev/usb/dwc2/dwc2.c,v >>> diff -u -p -u -p -r1.68 dwc2.c >>> --- sys/dev/usb/dwc2/dwc2.c 18 Sep 2022 21:12:19 -0000 1.68 >>> +++ sys/dev/usb/dwc2/dwc2.c 28 Dec 2025 21:01:55 -0000 >>> @@ -305,6 +305,11 @@ dwc2_softintr(void *v) >>> */ >>> mtx_enter(&hsotg->lock); >>> TAILQ_FOREACH_SAFE(dxfer, &sc->sc_complete, xnext, next) { >>> + if (dxfer->xfer.status != USBD_IN_PROGRESS) { >>> + printf("%s: xfer status = %s\n", >>> + __func__, usbd_errstr(dxfer->xfer.status)); >>> + continue; >>> + } >>> KASSERT(dxfer->xfer.status == USBD_IN_PROGRESS); >>> KASSERT(dxfer->intr_status != USBD_CANCELLED); >>> KASSERT(dxfer->intr_status != USBD_TIMEOUT);
