Date: Fri, 3 Sep 2004 14:21:48 GMT From: John Baldwin <jhb@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 60954 for review Message-ID: <200409031421.i83ELmY4039417@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=60954 Change 60954 by jhb@jhb_slimer on 2004/09/03 14:21:38 Revert jeff's last hack to this file and restore the previous behavior but in a more optimal fashion. Previously (as in 4.x and 5.2) we waited to return from lapic_ipi_wait() until the IPI was delivered. Jeff changed it to just return immediately and only wait for a short time on the next IPI. While spinwait IPIs like TLB shootdowns and rendezvous ensure that the IPI is delivered before another one is sent, one-shot IPI's like roundrobin, signal, hardclock, and statclock forwards do not wait. So instead, change this code to just wait as long as it needs to until the previous IPI is cleared. My quad xeon can't do a -j4 kernel build without triggering this panic right now, so hopefully this will fix that. Affected files ... .. //depot/projects/smpng/sys/i386/i386/local_apic.c#10 edit Differences ... ==== //depot/projects/smpng/sys/i386/i386/local_apic.c#10 (text+ko) ==== @@ -693,8 +693,8 @@ intr_restore(eflags); } +#ifdef DETECT_DEADLOCK #define BEFORE_SPIN 1000000 -#ifdef DETECT_DEADLOCK #define AFTER_SPIN 1000 #endif @@ -725,9 +725,16 @@ destfield = dest; } +#ifdef DETECT_DEADLOCK + /* Check for an earlier stuck IPI. */ /* Wait for an earlier IPI to finish. */ if (!lapic_ipi_wait(BEFORE_SPIN)) panic("APIC: Previous IPI is stuck"); +#else + /* Wait for an earlier IPI to finish. */ + if (!lapic_ipi_wait(-1)) + panic("APIC: Previous IPI is stuck"); +#endif lapic_ipi_raw(icrlo, destfield);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409031421.i83ELmY4039417>