Date: Sun, 27 Mar 2005 22:24:58 GMT From: Adam Kropelin <akropel1@rochester.rr.com> To: freebsd-gnats-submit@FreeBSD.org Subject: usb/79287: UHCI hang after interrupt transfer Message-ID: <200503272224.j2RMOw6U038745@www.freebsd.org> Resent-Message-ID: <200503272230.j2RMU3hM067131@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 79287 >Category: usb >Synopsis: UHCI hang after interrupt transfer >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 27 22:30:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Adam Kropelin >Release: 6.0-CURRENT >Organization: >Environment: FreeBSD p3.kroptech.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Mar 22 23:25:44 EST 2005 adk0212@p3.kroptech.com:/usr/src/sys/i386/compile/GENERIC.adk i386 >Description: My userspace HID driver (apcupsd) makes extensive use of ugen and the USB_DO_REQUEST ioctl. Some users are experiencing a hang where the driver process becomes unkillable and I've traced the problem to a USB_DO_REQUEST ioctl that never returns. The hang is very intermittent (it can happen after anywhere from tens to thousands of USB transfers) and seems to be timing dependent (enabling USB_DEBUG makes the condition much harder to trigger). I've managed to capture a USB_DEBUG trace that shows the failure condition. After thousands of proper transfers, I see this... kernel: usbd_start_next: pipe=0xc1a83c00, xfer=0 kernel: usb_transfer_complete: pipe=0xc1f6cb80 xfer=0xc1a9d400 status=0 actlen=5 kernel: usb_transfer_complete: repeat=1 new head=0xc1a9d400 kernel: usb0: host controller process error kernel: usb0: host controller halted kernel: usb0 regs: cmd=0080, sts=0031, intr=000f, frnum=0528, flbase=1f2c9000, sof=0040, portsc1=05a5, portsc2=0580 kernel: intrs=43840 kernel: QH(0xc1a93f80) at 1f167f80: hlink=1f167fa2 elink=00000001 kernel: usbd_free_xfer: 0xc1f1c800 kernel: usbd_alloc_xfer() = 0xc1f1c800 kernel: usbd_transfer: xfer=0xc1f1c800, flags=6, pipe=0xc1a83c00, running=0 kernel: usbd_dump_queue: pipe=0xc1a83c00 kernel: usb_allocmem: large alloc 100 kernel: usb_block_allocmem: size=4096 align=1 kernel: usb_block_allocmem: free list size=4096 kernel: usb_insert_transfer: pipe=0xc1a83c00 running=0 timeout=0 kernel: usb_freemem: large free kernel: usb_block_freemem: size=4096 kernel: usbd_free_xfer: 0xc1f1c800 kernel: usbd_alloc_xfer() = 0xc1f1c800 kernel: usbd_transfer: xfer=0xc1f1c800, flags=6, pipe=0xc1a83c00, running=1 kernel: usbd_dump_queue: pipe=0xc1a83c00 kernel: xfer=0xc1f1c800 kernel: usb_allocmem: large alloc 100 kernel: usb_block_allocmem: size=4096 align=1 kernel: usb_block_allocmem: free list size=4096 kernel: usb_insert_transfer: pipe=0xc1a83c00 running=1 timeout=0 kernel: usb_event_thread: woke up kernel: usb_discover ..after which only the usb_event_thread and usb_discover messages continue. I've tested 5.3-RELEASE as well as 6.0-CURRENT. FWIW, OpenBSD and NetBSD exhibit the same hang. Also FWIW, The USB rewrite from Hans Petter Selasky <hselasky at c2i dot net> does NOT exhibit the hang. I'm willing to test patches or do whatever level of debugging is required. A lot of users are hitting this hang and I'd like to get them up and running again with something less invasive than a complete subsystem rewrite. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503272224.j2RMOw6U038745>