From owner-freebsd-usb@FreeBSD.ORG Mon Jun 29 12:01:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53280106567A for ; Mon, 29 Jun 2009 12:01:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id D2DBF8FC1D for ; Mon, 29 Jun 2009 12:01:13 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=O3UVhbpmjpYA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=gXSkF0O3-N4G6N4AOjcA:9 a=Aty7n2uorUGm9F2eCvWtYPmXXvAA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 526484476; Mon, 29 Jun 2009 14:01:11 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Mon, 29 Jun 2009 14:00:42 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4A48A5AD.9040508@embedded-brains.de> In-Reply-To: <4A48A5AD.9040508@embedded-brains.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291400.42941.hselasky@c2i.net> Cc: Subject: Re: Potential problem with USB_THREAD_SUSPEND()? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:01:15 -0000 On Monday 29 June 2009 13:29:49 Sebastian Huber wrote: > Hi, > > USB_THREAD_SUSPEND(p) is defined as {kproc|kthread}_suspend(p, 0). This > means that it will wait until the corresponding thread recognizes its > suspend request and suspends itself. It seems that > {kproc|kthread}_suspend_check() will be used nowhere in the USB system. > Thus the USB_THREAD_SUSPEND() will block forever in most cases? It is only > used in usb_proc_drain() during cold boot. > > Have a nice day! Thanks for your input. This execution path has been tested, but not with the latest 8-current, and is a dirty hack around the problem which appears if an USB controller fails to attach during boot, that we cannot kill created threads? If you want you can insert an error into the attach routine in /sys/dev/usb/controller/uhci.c for example, to verify that the code works. --HPS