From owner-freebsd-current@FreeBSD.ORG Fri Jun 4 08:07:52 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 4810D16A4CE for ; Fri, 4 Jun 2004 08:07:52 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E81643D49 for ; Fri, 4 Jun 2004 08:07:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28330 invoked from network); 4 Jun 2004 15:07:49 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Jun 2004 15:07:49 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i54F7kUl081542; Fri, 4 Jun 2004 11:07:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 4 Jun 2004 11:08:33 -0400 User-Agent: KMail/1.6 References: <714DBA6C-B565-11D8-B32B-000393AB07D8@verizon.net> <200406041044.51779.jhb@FreeBSD.org> <20040604105118.kpsgwcg4skgsgso0@www.sweetdreamsracing.biz> In-Reply-To: <20040604105118.kpsgwcg4skgsgso0@www.sweetdreamsracing.biz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406041108.33170.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Kenneth Culver cc: njl@FreeBSD.org cc: Dan Nelson cc: David Gurvich 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 15:07:52 -0000 On Friday 04 June 2004 10:51 am, Kenneth Culver wrote: > Quoting John Baldwin : > > On Thursday 03 June 2004 11:04 am, Dan Nelson wrote: > >> In the last episode (Jun 03), David Gurvich said: > >> > Recent cvsup has caused system to hang on reboot or shutdown, > >> > occasionally hangs on startup with detection of optical drive on 2nd > >> > ide. Anyone know how to get system logs in this situation? > >> > Motherboard is ASUS A7N266-VM. System worked reasonably with APIC > >> > turned off 5/26/2004. > >> > >> Back out sys/i386/i386/intr_machdep.c rev 1.6. > > > > Or for the real fix, try this: > > > > 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); > > } > > > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > You know that the reboot problems go away when > /usr/src/sys/i386/i386/intr_machdep.c is reverted from 1.16 to 1.15 right? 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org