On Friday 04 June 2004 10:51 am, Kenneth Culver wrote: > Quoting John Baldwin <jhb_at_FreeBSD.org>: > > 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 > > _at__at_ -376,8 +376,7 _at__at_ > > > > /* 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 <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > _______________________________________________ > > freebsd-current_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe_at_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 <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Fri Jun 04 2004 - 06:07:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:56 UTC