From owner-freebsd-current@FreeBSD.ORG Sat Nov 29 05:08:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90EFA106564A for ; Sat, 29 Nov 2008 05:08:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 697FB8FC0C for ; Sat, 29 Nov 2008 05:08:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so1769056wfg.7 for ; Fri, 28 Nov 2008 21:08:27 -0800 (PST) Received: by 10.142.213.9 with SMTP id l9mr3065178wfg.287.1227934020691; Fri, 28 Nov 2008 20:47:00 -0800 (PST) Received: by 10.142.255.21 with HTTP; Fri, 28 Nov 2008 20:47:00 -0800 (PST) Message-ID: Date: Fri, 28 Nov 2008 20:47:00 -0800 From: "Peter Wemm" To: "Giorgos Keramidas" In-Reply-To: <87myfjma0k.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wseo731o.fsf@kobe.laptop> <87fxlcba7p.fsf@kobe.laptop> <87myfjma0k.fsf@kobe.laptop> Cc: freebsd-current@freebsd.org Subject: Re: tty problems in recent head? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 29 Nov 2008 05:08:27 -0000 On Fri, Nov 28, 2008 at 8:27 PM, Giorgos Keramidas wrote: > On Fri, 28 Nov 2008 09:06:50 +0200, Giorgos Keramidas wrote: >> On Fri, 28 Nov 2008 08:55:15 +0200, Giorgos Keramidas wrote: >>> I just restored my laptop after a bit of 'fun' with a broken disk, and >>> rebuilt all my ports. Something in head/ @ svn rev 185370 seems to >>> cause problems to screen & xterm. >>> >>> Exiting an xterm window causes xterm processes to be stuck in 'RUN' and >>> consume a lot of CPU: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >>> 11211 keramida 1 106 0 7624K 4360K CPU0 0 0:46 51.86% xterm >>> 11169 keramida 1 106 0 7624K 4504K RUN 1 1:12 49.66% xterm >>> 11201 keramida 1 106 0 7624K 4360K RUN 1 0:47 49.07% xterm >>> 11180 keramida 1 106 0 7624K 4360K RUN 1 1:07 48.88% xterm >>> ... >> >> Nevermind. This seems to be a problem only with xterm processes started >> under XFCE4. Running under startx and plain 'twm' doesn't have the same >> problem, so I'll have to look a bit more into this... > > The xterm processes that get stuck seem to be spinning near line 1854 of > sched_ule.c. Running `info threads' on a live kernel after xterm starts > spinning on a CPU shows: > > 129 Thread 100174 (PID=97493: xterm) sched_switch (td=0xc72fad80, > newtd=0xc7245000, flags=519) at /usr/src/sys/kern/sched_ule.c:1854 > > 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. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell