Date: Sat, 29 Nov 2008 17:51:31 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: "Peter Wemm" <peter@wemm.org> Cc: freebsd-current@freebsd.org Subject: Re: tty problems in recent head? Message-ID: <87wsempm2k.fsf@kobe.laptop> In-Reply-To: <e7db6d980811282047o5a7ed4cerc466db6d51e616a4@mail.gmail.com> (Peter Wemm's message of "Fri, 28 Nov 2008 20:47:00 -0800") References: <87wseo731o.fsf@kobe.laptop> <87fxlcba7p.fsf@kobe.laptop> <87myfjma0k.fsf@kobe.laptop> <e7db6d980811282047o5a7ed4cerc466db6d51e616a4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Nov 2008 20:47:00 -0800, "Peter Wemm" <peter@wemm.org> wrote: > On Fri, Nov 28, 2008 at 8:27 PM, Giorgos Keramidas > <keramida@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87wsempm2k.fsf>