From owner-freebsd-usb@FreeBSD.ORG Wed Mar 16 00:32:57 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D59416A4CE for ; Wed, 16 Mar 2005 00:32:57 +0000 (GMT) Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D3743D5D for ; Wed, 16 Mar 2005 00:32:56 +0000 (GMT) (envelope-from akropel1@rochester.rr.com) Received: from mail.kroptech.com (cpe-24-93-20-125.rochester.res.rr.com [24.93.20.125])j2G0Wrpl029919 for ; Tue, 15 Mar 2005 19:32:53 -0500 (EST) Received: from pia (pia.kroptech.com [192.168.200.3]) by mail.kroptech.com (Postfix) with SMTP id 4D96811376E for ; Tue, 15 Mar 2005 19:37:03 -0500 (EST) Message-ID: <07f701c529bf$b0f05540$03c8a8c0@kroptech.com> From: "Adam Kropelin" To: Date: Tue, 15 Mar 2005 19:32:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: ugen & uhci hang on 5.3-RELEASE and 6.0-CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 00:32:57 -0000 I'm the maintainer of the BSD USB driver for the apcupsd (APC UPS daemon) project. The driver makes extensive use of ugen and the USB_DO_REQUEST ioctl. Some users are experiencing a hang where the apcupsd 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 and it seems to stem from a uhci error. 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. It appears that the hcd detects an error, another transfer is dispatched and never completes. apcupsd is unkillable at this point (sitting in kse_release). I've tested 5.3-RELEASE as well as 6.0-CURRENT. Any ideas? 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. --Adam