On Fri, 28 Nov 2008 20:47:00 -0800, "Peter Wemm" <peter_at_wemm.org> wrote: > On Fri, Nov 28, 2008 at 8:27 PM, Giorgos Keramidas > <keramida_at_ceid.upatras.gr> wrote: >> Since this part of sched_ule.c hasn't changed in a while >> >> REV CHANGE AUTHOR >> --------------------------------------------------------------------------------------------------- >> 1848 171482 jeff cpu_switch(td, newtd, mtx); >> 1849 171482 jeff /* >> 1850 171482 jeff * We may return from cpu_switch on a different cpu. However, >> 1851 171482 jeff * we always return with td_lock pointing to the current cpu's >> 1852 171482 jeff * run queue lock. >> 1853 171482 jeff */ >> 1854 171482 jeff cpuid = PCPU_GET(cpuid); >> 1855 171482 jeff tdq = TDQ_CPU(cpuid); >> 1856 174629 jeff lock_profile_obtain_lock_success( >> 1857 174629 jeff &TDQ_LOCKPTR(tdq)->lock_object, 0, 0, __FILE__, __LINE__); >> 1858 145256 jkoshy #ifdef HWPMC_HOOKS >> 1859 145256 jkoshy if (PMC_PROC_IS_USING_PMCS(td->td_proc)) >> 1860 145256 jkoshy PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_IN); >> 1861 145256 jkoshy #endif >> >> any ideas why PCPU_GET() might spin like this? > > It isn't. The 'info' command is misleading you. It is merely the > next instruction after returning from cpu_switch(). Something is > effectively in a yield loop. Thanks. I went back to 2008-11-16 15:45 +0000 and I can still see xterm processes stuck after a while. Two potentially useful bits are: 1. My `/etc/make.conf' contained after the last restore from backups: : # Are these two really safe? : CFLAGS?= -O2 -fno-strict-aliasing -pipe : COPTFLAGS?= -O -pipe : : #NO_CPU_CFLAGS= # Don't add -march=<cpu> to CFLAGS automatically : #NO_CPU_COPTFLAGS= # Don't add -march=<cpu> to COPTFLAGS automatically I commented both out, to see if it changes things. If the same happens without -O2 optimizations, I'll keep going backwards to see if I can locate the commit that this started happening.Received on Sat Nov 29 2008 - 14:51:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC