lkml.org 
[lkml]   [2008]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
From
Date

On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote:
> On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" <jacliburn@bellsouth.net> wrote:
>
> > Zan Lynx wrote:
> >
> > > gnome-terminal gets stuck.
> >
> > I began seeing this very thing around 2.6.24 time. (Fedora 8, vanilla
> > kernel.) I could usually cause the gnome terminal to hang if I rapidly
> > resized the window while executing make check-headers.
> >
> > Over a couple of days I bisected it down to this commit:
> >
> > Commit: 37bb6cb4097e29ffee970065b74499cbf10603a3
> > Parent: d3d74453c34f8fd87674a8cf5b8a327c68f22e99
> > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > AuthorDate: Fri Jan 25 21:08:32 2008 +0100
> > Committer: Ingo Molnar <mingo@elte.hu>
> > CommitDate: Fri Jan 25 21:08:32 2008 +0100
> >
> > hrtimer: unlock hrtimer_wakeup
> >
> > hrtimer_wakeup creates a
> >
> > base->lock
> > rq->lock
> >
> > lock dependancy. Avoid this by switching to
> > HRTIMER_CB_IRQSAFE_NO_SOFTIRQ
> > which doesn't hold base->lock.
> >
> > This fully untangles hrtimer locks from the scheduler locks, and allows
> > hrtimer usage in the scheduler proper.
> >
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > ---
> > kernel/hrtimer.c | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> >
> > Reverting the commit seemed to fix the problem for me.
> >
> > Then I went away on a business trip Monday morning and returned Tuesday
> > night to a dead computer (won't POST), so I can't do any further
> > troubleshooting until I get it fixed.
>
> Useful, thanks.
>
> > Try reverting that patch and see if your gnome-terminal freezes go away.
>
> Here is a convenient patch against current mainline:
>
>
> --- a/kernel/hrtimer.c~revert-1
> +++ a/kernel/hrtimer.c
> @@ -1292,7 +1292,7 @@ void hrtimer_init_sleeper(struct hrtimer
> sl->timer.function = hrtimer_wakeup;
> sl->task = task;
> #ifdef CONFIG_HIGH_RES_TIMERS
> - sl->timer.cb_mode = HRTIMER_CB_IRQSAFE_NO_SOFTIRQ;
> + sl->timer.cb_mode = HRTIMER_CB_IRQSAFE_NO_RESTART;
> #endif
> }
>
> @@ -1303,8 +1303,6 @@ static int __sched do_nanosleep(struct h
> do {
> set_current_state(TASK_INTERRUPTIBLE);
> hrtimer_start(&t->timer, t->timer.expires, mode);
> - if (!hrtimer_active(&t->timer))
> - t->task = NULL;
>
> if (likely(t->task))
> schedule();

Bugger, I thought I had it nailed with:

---

commit 3588a085cd52ef080bf72df772378e1ba6bb292f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Feb 1 17:45:13 2008 +0100

hrtimer: fix hrtimer_init_sleeper() users

this patch:

commit 37bb6cb4097e29ffee970065b74499cbf10603a3
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Jan 25 21:08:32 2008 +0100

hrtimer: unlock hrtimer_wakeup

Broke hrtimer_init_sleeper() users. It forgot to fix up the futex
caller of this function to detect the failed queueing and messed up
the do_nanosleep() caller in that it could leak a TASK_INTERRUPTIBLE
state.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/kernel/futex.c b/kernel/futex.c
index db9824d..0edd314 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1252,6 +1252,8 @@ static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared,
t.timer.expires = *abs_time;

hrtimer_start(&t.timer, t.timer.expires, HRTIMER_MODE_ABS);
+ if (!hrtimer_active(&t.timer))
+ t.task = NULL;

/*
* the timer could have already expired, in which
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index bd5d6b5..1069998 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1315,6 +1315,8 @@ static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mod

} while (t->task && !signal_pending(current));

+ __set_current_state(TASK_RUNNING);
+
return t->task == NULL;
}

---
But apparently that doesn't do the magic for gnome-terminal (as this
patch is already in the .24-mm1 kernel reported broken). Any way I can
'easily' reproduce this issue?





\
 
 \ /
  Last update: 2008-02-07 20:51    [W:0.067 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site