From owner-freebsd-questions@FreeBSD.ORG Thu May 29 22:04:25 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DE9A37B401 for ; Thu, 29 May 2003 22:04:25 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 345B543F3F for ; Thu, 29 May 2003 22:04:24 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([129.44.60.214]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030530050423.GQYG12592.out001.verizon.net@mac.com>; Fri, 30 May 2003 00:04:23 -0500 Message-ID: <3ED6E65A.7000509@mac.com> Date: Fri, 30 May 2003 01:04:26 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anurag Chaudhary References: In-Reply-To: X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [129.44.60.214] at Fri, 30 May 2003 00:04:23 -0500 cc: freebsd-questions@freebsd.org Subject: Re: nanosleep crashed my kernel X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2003 05:04:25 -0000 Anurag Chaudhary wrote: > I used nanosleep() in my device driver, but it crashed the kernel saying > pagefault in kernel mode. > Can anybody please suggest some other method to be used in a kld to sleep When you put the kernel to sleep, what were you expecting to wake it up? :-) A literal answer would be an interrupt, but in many contexts, such as device drivers, tend to block receipt of new interrupts while servicing the existing one. Regardless, there is a critical design methodology involved: you shouldn't ever block or busy-wait in the kernel, at least if you can possibly avoid it. Look into continuations and performing a context swap to a runnable process until the next interrupt happens and your device driver can make more progress. -- -Chuck