From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 16:36:24 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9C416A418; Wed, 3 Oct 2007 16:36:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 38E7B13C458; Wed, 3 Oct 2007 16:36:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l93GaNxL085495; Wed, 3 Oct 2007 12:36:23 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Nate Lawson Date: Wed, 3 Oct 2007 12:36:19 -0400 User-Agent: KMail/1.6.2 References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> <4703BD8D.1080501@root.org> In-Reply-To: <4703BD8D.1080501@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710031236.21309.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4461/Wed Oct 3 04:50:48 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior 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: Wed, 03 Oct 2007 16:36:24 -0000 On Wednesday 03 October 2007 12:04 pm, Nate Lawson wrote: > Jung-uk Kim wrote: > > On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote: > >> Attached is a patch (one for 6, one for 7) that shouldn't break > >> anything for most people and may fix some battery status issues > >> for others. It changes how we run tasks during boot. It seems > >> some hardware expects synchronous access but our taskq is not > >> running until after interrupts are enabled. This patch bounces > >> calls through a wrapper that executes the callback directly if > >> we're not booted yet. > > > > Sorry, I didn't test it but I have some questions. Why do you > > add a wrapper and pollute all > > AcpiOsQueueForExecution()/AcpiOsExecute() consumers? Isn't it > > more simpler to let the function determine to queue or not to > > queue? Why do you check cold and rebooting flags? If you wanted > > to check the taskqueue is ready, you could check taskqueue_acpi > > is NULL or not, instead. > > There are 2 different behaviors I'm trying to support and only the > caller knows which one they want: > > 1. Run a task at some point in the future but "soon" > 2. Queue a task to be run, definitely after boot is complete > > Notifies are in the first class. Initialization functions for the > various drivers are in the second. ACPI-CA is moving to making all > Notifies completely synchronous (i.e. they wait for the thread to > run). So if we go to the model you describe (#1), this will work > but suddenly the initialization of the drivers won't wait for boot. > It will be run right away. Understood. However, there are two conflicting Notify handler implemtations, i.e., 'synchronous' type with a semaphore (which is in newer unreleased ACPI-CA) and 'do not defer' type (which is in Linux kernel source): http://bugzilla.kernel.org/show_bug.cgi?id=5534 See the patches that are actually committed to Linux git tree: http://bugzilla.kernel.org/attachment.cgi?id=10429&action=view http://bugzilla.kernel.org/attachment.cgi?id=10430&action=view I believe the vendor didn't finalize the design yet. For now, we may have to try Linux way. Thanks, Jung-uk Kim