From owner-freebsd-current@FreeBSD.ORG Fri Jun 4 12:47:07 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 E834716A4CE for ; Fri, 4 Jun 2004 12:47:07 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D09A743D45 for ; Fri, 4 Jun 2004 12:47:07 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 52140 invoked by uid 1000); 4 Jun 2004 19:46:51 -0000 Date: Fri, 4 Jun 2004 12:46:51 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406041108.33170.jhb@FreeBSD.org> Message-ID: <20040604123934.D52021@root.org> References: <714DBA6C-B565-11D8-B32B-000393AB07D8@verizon.net> <20040604105118.kpsgwcg4skgsgso0@www.sweetdreamsracing.biz> <200406041108.33170.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: reboot or shutdown not working with -current 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: Fri, 04 Jun 2004 19:47:08 -0000 On Fri, 4 Jun 2004, John Baldwin wrote: > > > Index: acpi_cpu.c > > > =================================================================== > > > RCS file: /usr/cvs/src/sys/dev/acpica/acpi_cpu.c,v > > > retrieving revision 1.36 > > > diff -u -r1.36 acpi_cpu.c > > > --- acpi_cpu.c 7 May 2004 05:22:37 -0000 1.36 > > > +++ acpi_cpu.c 4 Jun 2004 14:44:33 -0000 > > > @@ -376,8 +376,7 @@ > > > > > > /* Wait for all processors to exit acpi_cpu_idle(). */ > > > smp_rendezvous(NULL, NULL, NULL, NULL); > > > - while (cpu_idle_busy > 0) > > > - DELAY(1); > > > + DELAY(1); > > > > > > return_VALUE (0); > > > } > > > > > Yes, because the real bug is above. Disabling interrupt preemption just masks > it. The gory details are that almost all (in fact on UP, 100%) of context > switches away from the idlethread are due to interrupts. When interrupt > preemption is enabled, this means that idle threads are switched away from > before they've had a chance to decrement the cpu_idle_busy counter in > acpi_cpu_idle(). Thus, when the thread doing shutdown gets to this loop, it > never terminates because the idlethread of the CPU executing the shutdown > request never gets a chance to go back and decrement its idle_busy count. In > truth, you don't actually need the loop, once you do the rendezvous, any > other CPUs that are idle will wake up, exit acpi_cpu_idle() and re-enter > after finding no runnable jobs. I tracked this down after a couple of hours > on Wednesday but was very busy with ${REALJOB} work yesterday and haven't had > a chance to send an e-mail out about this. My goal with this originally was to drain all threads out of the idle handler before continuing the shutdown process. The assumption that changed with the ithread commit was that the idle thread gets to run sometime after an interrupt occurs. It's actually kind of tough to have a sched switch before any instructions get to execute after the "go to sleep" one since I profile the length of the sleep to figure out how deep a sleep to use the next cycle. This is to keep sporadically loaded machines responsive. So if a preemption can happen every sleep, I'll have to redo this approach and go with one that doesn't require profiling and executes no code after the sleep. -Nate