From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 01:07:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 964C216A4CE; Sat, 28 Aug 2004 01:07:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C6B43D66; Sat, 28 Aug 2004 01:07:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7S17Bln019853; Fri, 27 Aug 2004 19:07:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 27 Aug 2004 19:07:11 -0600 (MDT) Message-Id: <20040827.190711.77422828.imp@bsdimp.com> To: pjd@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040820090006.GX30151@darkness.comp.waw.pl> References: <20040820090006.GX30151@darkness.comp.waw.pl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: Bogus usage of tsleep(9) in USB. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2004 01:07:23 -0000 In message: <20040820090006.GX30151@darkness.comp.waw.pl> Pawel Jakub Dawidek writes: : There are many calls to tsleep(9) with no timeout in our USB code. : As you all know, it is not permitted and we have KASSERT() for this: : : KASSERT(timo != 0 || mtx_owned(&Giant) || mtx != NULL, : ("sleeping without a mutex")); : : ehci.c:2441: tsleep(&sc->sc_softwake, PZERO, "ehciab", 0); : ohci.c:2288: tsleep(&sc->sc_softwake, PZERO, "ohciab", 0); : ubser.c:882: tsleep(&sc->sc_opening, PRIBIO, "ubser_op", 0); : ucom.c:275: tsleep(&sc->sc_opening, PRIBIO, "ucomop", 0); : ugen.c:633: error = tsleep(sce, PZERO | PCATCH, "ugenri", 0); : ugen.c:697: error = tsleep(sce, PZERO | PCATCH, "ugenri", 0); : uhci.c:1982: tsleep(&sc->sc_softwake, PZERO, "uhciab", 0); : uhid.c:496: error = tsleep(&sc->sc_q, PZERO | PCATCH, "uhidrea", 0); : ums.c:639: error = tsleep(sc, PZERO | PCATCH, "umsrea", 0); : usb.c:456: tsleep(&usb_all_tasks, PWAIT, "usbtsk", 0); : usb.c:534: error = tsleep(&usb_events, PZERO | PCATCH, "usbrea", 0); : usbdi.c:342: tsleep(xfer, PRIBIO, "usbsyn", 0); : usbdi_util.c:435: error = tsleep(xfer, PZERO | PCATCH, lbl, 0); : usbdi_util.c:477: error = tsleep(xfer, PZERO | PCATCH, lbl, 0); : : I saw only panic on tsleep(9) from usbdi.c, so I know for sure we don't : hold Giant there. Most of the usb stack will be called with GIANT held, which is likely why you haven't seen more panics. I'd suspect that the panic you are seeing from usbdi() due to other bogosity. Warner