From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 04:02:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85D1216A47B; Sun, 8 Jul 2007 04:02:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3B09C13C455; Sun, 8 Jul 2007 04:02:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6841Lak099270; Sat, 7 Jul 2007 22:01:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Jul 2007 22:02:03 -0600 (MDT) Message-Id: <20070707.220203.776519881.imp@bsdimp.com> To: xistence@0x58.com From: "M. Warner Losh" In-Reply-To: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> References: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 07 Jul 2007 22:01:21 -0600 (MDT) Cc: usb@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: device rue causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 08 Jul 2007 04:02:44 -0000 In message: <9496044C-3275-4D9C-8FFF-FD1FCE1F6728@0x58.com> Bert JW Regeer writes: : I have a USB 10/100 FastEthernet device, that is identified as a : RealTek device. On 6.2-RELEASE it works without any issues, and some : older versions of CURRENT it worked perfectly as well. I csup'ed to : CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it : failed: : panic (fmt=0xc0a94933 "Trying sleep, but thread marked as sleeping prohibited") : _sleep (ident=0xc2322c00...) at /usr/src/sys/kern/kern_synch.c:201 : usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:333 : usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:406 : usbd_do_request_flags_pipe ... at /usr/src/sys/dev/usb/usbdi.c:1098 : usbd_do_request_flags ...at /usr/src/sys/dev/usb/usbdi.c:1068 : usbd_do_request at /usr/src/sys/dev/usb/usbdi.c:1060 : rue_read_mem at /usr/src/sys/dev/usb/if_rue.c:227 : rue_csr_read_1 at /usr/src/sys/dev/usb/if_rue.c:276 : rue_miibus_readreg at /usr/src/sys/dev/usb/if_rue.c:376 ... : ruephy_service at miibus_if.h:26 /* Likely wrong */ : mii_tick at /usr/src/sys/dev/mii/mii.c:390 : rue_tick at /usr/src/sys/dev/usb/if_rue.c:935 : softclock at /usr/src/sys/kern/kern_timeout.c:281 ... This driver needs to be re-written ala aue, axe, kue and udav to use a taskqueue for the mii ticking. It appears to be the only usb driver in the tree to still do stuff directly in a callout. This context can't sleep... Warner