From owner-freebsd-current@FreeBSD.ORG Sat Nov 29 04:28:14 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 14458106564A for ; Sat, 29 Nov 2008 04:28:14 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 92D988FC0A for ; Sat, 29 Nov 2008 04:28:13 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl164-98.kln.forthnet.gr [62.1.67.98]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id mAT4S4C6028209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 29 Nov 2008 06:28:10 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id mAT4S4rc037744 for ; Sat, 29 Nov 2008 06:28:04 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id mAT4S4mi037739; Sat, 29 Nov 2008 06:28:04 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: freebsd-current@freebsd.org In-Reply-To: <87fxlcba7p.fsf@kobe.laptop> (Giorgos Keramidas's message of "Fri, 28 Nov 2008 09:06:50 +0200") Date: Sat, 29 Nov 2008 06:27:55 +0200 Message-ID: <87myfjma0k.fsf@kobe.laptop> References: <87wseo731o.fsf@kobe.laptop> <87fxlcba7p.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: mAT4S4C6028209 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.011, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.39, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No 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 04:28:14 -0000 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?