Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

Hi,

The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped
by "ifconfig down" or detached.

As discussed in the previous message, this is due to infinite loop in
usbd_ar_pipe(); xfers with USBD_NOT_STARTED remain in a queue forever
because upm_abort [= xhci_device_bulk_abort() etc.] cannot remove them.

I guess that this can happen for host controllers in which up_serialise
is true for bulk transfers [it does not occur for dwctwo(4), in which
up_serialise == false for bulk transfers]. For such adapters, IMO,
usbd_start_next(pipe) should be called whenever some xfer is removed
from pipe->up_queue.

Actually, the freeze seems to be fixed by the attached patch.
Can I commit the patch? Or, am I missing something?

Thanks,
rin
----
Index: usbdi.c
===================================================================
RCS file: /home/netbsd/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.181
diff -p -u -r1.181 usbdi.c
--- sys/dev/usb/usbdi.c	10 Jan 2019 22:13:07 -0000	1.181
+++ sys/dev/usb/usbdi.c	12 Feb 2019 14:07:35 -0000
@@ -1013,7 +1013,7 @@ usb_transfer_complete(struct usbd_xfer *
 		if (erred && pipe->up_iface != NULL)	/* not control pipe */
 			pipe->up_running = 0;
 	}
-	if (pipe->up_running && pipe->up_serialise)
+	if (pipe->up_serialise)
 		usbd_start_next(pipe);
 }
 
----

On 2019/02/09 22:28, sc dying wrote:
> On Sat, Feb 9, 2019 at 8:18 AM Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote:
> > Hi,
> >
> > On 2019/02/08 23:16, sc dying wrote:
> > > On 2019/01/31 05:51, Rin Okuyama wrote:
> > > > By the way, I find that the system hangs silently by
> > > > "ifconfig mueN down" or detaching LAN7500 from USB port when
> > > > multiple outstanding requests are enabled. This does not occur
> > > > when MUE_TX_LIST_CNT = MUE_RX_LIST_CNT = 1. Do you have any ideas
> > > > to fix it?
> > >
> > > My axen dongle locks up if AXEN_RX_LIST_CNT > 1
> > > when ifconfig down on amd64 8.99.34.
> > >
> > > db{0}> bt
> > > breakpoint() at netbsd:breakpoint+0x5
> > > comintr() at netbsd:comintr+0x861
> > > Xhandle_ioapic_edge4() at netbsd:Xhandle_ioapic_edge4+0x66
> > > --- interrupt ---
> > > xhci_device_bulk_abort() at netbsd:xhci_device_bulk_abort+0x1c
> > > usbd_ar_pipe() at netbsd:usbd_ar_pipe+0x1e9
> > > usbd_abort_pipe() at netbsd:usbd_abort_pipe+0x27
> > > axen_stop() at netbsd:axen_stop+0xc4
> > > axen_ioctl() at netbsd:axen_ioctl+0x1d9
> > > doifioctl() at netbsd:doifioctl+0xa99
> > > sys_ioctl() at netbsd:sys_ioctl+0x11c
> > > syscall() at netbsd:syscall+0xb4
> > > --- syscall (number 54) ---
> > > 732731d1a88a:
> > >
> > > Looks like kernel goes infinite loop in usbd_ar_pipe by some reason.
> > > It tries to abort NOT_STARTED xfers.
> >
> > Can you tell me how to reproduce this failure?
> > "ifconfig down" works for me on RPI3B+.
>
> I tested on intel 3000 series CPU + Ivebridge
> with kernel from my local tree.
> But I found it does not happen with the lastest kernel from
> https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/amd64/binary/kernel/netbsd-GENERIC.gz.