tty problems in recent head?
Peter Wemm
peter at wemm.org
Fri Nov 28 21:08:27 PST 2008
On Fri, Nov 28, 2008 at 8:27 PM, Giorgos Keramidas
<keramida at ceid.upatras.gr> wrote:
> On Fri, 28 Nov 2008 09:06:50 +0200, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
>> On Fri, 28 Nov 2008 08:55:15 +0200, Giorgos Keramidas <keramida at ceid.upatras.gr> 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 at wemm.org; peter at FreeBSD.org; peter at 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
More information about the freebsd-current
mailing list