Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Thu, 2008-02-07 at 19:26 -0600, Jay Cliburn wrote: > On Thu, 07 Feb 2008 21:24:47 +0100 > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > The trace isn't from me; it's from Zan. He's running -mm, I'm not, if > that makes a difference. > > > > > Call Trace: > > [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 > > [] schedule_timeout+0x95/0xd0 > > [tty_poll+145/160] tty_poll+0x91/0xa0 > > [] tty_poll+0x91/0xa0 > > [do_sys_poll+617/880] do_sys_poll+0x269/0x370 > > [] do_sys_poll+0x269/0x370 > > [__pollwait+0/304] __pollwait+0x0/0x130 > > [] __pollwait+0x0/0x130 > > Now that my computer is back on the air again, I'll be happy to help > track this down. Just tell me what to do. First would be to see if you could get a sysrq-t dump of the blocked process. I'm curious if yours would point to the same spot. Also, could you describe how to reproduce it, given that you managed to have it reproducable enough to bisect, I'd say you have a good case. I installed gnome-terminal, started it and wiggled it about while doing find / - that didn't manage to get it to lock up - but I'll try again if that is the right way. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Thu, 07 Feb 2008 21:24:47 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-02-07 at 20:49 +0100, Peter Zijlstra wrote: > > On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote: > > > On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" > > > <[EMAIL PROTECTED]> 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. > > Weird, .24 proper doesn't have that patch. Yeah, my reference to "around 2.6.24 time" was simply a gross demarcation along the passage of time rather than an indictment of 2.6.24 itself. I began noticing gnome-terminal hangs during kernel builds a couple of weeks ago, but I ignored them, thinking it'd be fixed with a Fedora package update. When that didn't happen, I began looking for the culprit in the kernel in earnest this past Saturday. > What exact fedora kernel was that (so I can look at it). I didn't use a Fedora kernel; I bisected Linus' git current as of Saturday Feb 2, using 2.6.24 as the "good" side of the bisect. It took the better part of two days to whittle down the throng, but by Sunday night I'd settled on the 37bb6cb4 hrtimer commit. My last act before going to bed that night was to reset the bisect, revert the commit, and rebuild. I couldn't get gnome-terminal to hang using that rebuilt kernel. The next morning I went out of town for a couple of days, only to return to find my workstation dead after some weather-related power outages. I just got it back online tonight. > Which is even weirder, because the provided trace indicates > schedule_timeout() The trace isn't from me; it's from Zan. He's running -mm, I'm not, if that makes a difference. > > Call Trace: > [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 > [] schedule_timeout+0x95/0xd0 > [tty_poll+145/160] tty_poll+0x91/0xa0 > [] tty_poll+0x91/0xa0 > [do_sys_poll+617/880] do_sys_poll+0x269/0x370 > [] do_sys_poll+0x269/0x370 > [__pollwait+0/304] __pollwait+0x0/0x130 > [] __pollwait+0x0/0x130 Now that my computer is back on the air again, I'll be happy to help track this down. Just tell me what to do. Jay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Thu, 2008-02-07 at 20:49 +0100, Peter Zijlstra wrote: > On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote: > > On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" <[EMAIL PROTECTED]> > > 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. Weird, .24 proper doesn't have that patch. What exact fedora kernel was that (so I can look at it). > > > Over a couple of days I bisected it down to this commit: > > > > > > Commit: 37bb6cb4097e29ffee970065b74499cbf10603a3 > > > Parent: d3d74453c34f8fd87674a8cf5b8a327c68f22e99 > > > Author: Peter Zijlstra <[EMAIL PROTECTED]> > > > AuthorDate: Fri Jan 25 21:08:32 2008 +0100 > > > Committer: Ingo Molnar <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED]> > > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > > > --- > > > kernel/hrtimer.c |4 +++- > > > 1 files changed, 3 insertions(+), 1 deletions(-) Which is even weirder, because the provided trace indicates schedule_timeout() Call Trace: [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 [] schedule_timeout+0x95/0xd0 [tty_poll+145/160] tty_poll+0x91/0xa0 [] tty_poll+0x91/0xa0 [do_sys_poll+617/880] do_sys_poll+0x269/0x370 [] do_sys_poll+0x269/0x370 [__pollwait+0/304] __pollwait+0x0/0x130 [] __pollwait+0x0/0x130 [ weird trace format this ] which uses the other timer API, and should not be affected by hrtimer_wakeup(). /me puzzled... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote:
> On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > AuthorDate: Fri Jan 25 21:08:32 2008 +0100
> > Committer: Ingo Molnar <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> > ---
> > 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 <[EMAIL PROTECTED]>
Date: Fri Feb 1 17:45:13 2008 +0100
hrtimer: fix hrtimer_init_sleeper() users
this patch:
commit 37bb6cb4097e29ffee970065b74499cbf10603a3
Author: Peter Zijlstra <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> AuthorDate: Fri Jan 25 21:08:32 2008 +0100
> Committer: Ingo Molnar <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> 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();
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
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 <[EMAIL PROTECTED]> AuthorDate: Fri Jan 25 21:08:32 2008 +0100 Committer: Ingo Molnar <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- 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. Try reverting that patch and see if your gnome-terminal freezes go away. Jay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Wed, 2008-02-06 at 19:44 +, Alan Cox wrote: > On Wed, 06 Feb 2008 12:38:42 -0700 > Zan Lynx <[EMAIL PROTECTED]> wrote: > > > This doesn't happen often so it is rather hard to nail down, but I am > > fairly sure it didn't happen before I started running the 2.6.24 MM > > series kernels. > > Do you have the -mm1 hot fixes applied if its occuring in 2.6.24-mm1 ? All of them except stop-c_p_a-corrupting-the-pds.patch but I don't think that matters since the patch description says it affects x86_32 and this system is x86_64. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Wed, 06 Feb 2008 12:38:42 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote: > This doesn't happen often so it is rather hard to nail down, but I am > fairly sure it didn't happen before I started running the 2.6.24 MM > series kernels. Do you have the -mm1 hot fixes applied if its occuring in 2.6.24-mm1 ? Otherwise tty_poll/wakeup hasn't changed much. It is about to change big time so I'm glad the bug has popped up before I submit the patches ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
This doesn't happen often so it is rather hard to nail down, but I am fairly sure it didn't happen before I started running the 2.6.24 MM series kernels. gnome-terminal gets stuck. It stops processing X events or anything else. It can be kicked out by strace'ing it or connecting with GDB, and the bug does not seem to ever happen while being traced. It just happened again and I did a sysrq-t to see where (sysrq output for gnome-terminal below). It gets stuck in tty_poll. Have there been changes to TTY stuff recently? I'd try to bisect but this only happens roughly twice a week. Feb 6 12:25:09 localhost kernel: [22779.484008] gnome-termina S 810001009ec0 0 7794 1 Feb 6 12:25:09 localhost kernel: [22779.484008] 81001649db08 0092 00020001 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086dec0 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086ad80 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] Call Trace: Feb 6 12:25:09 localhost kernel: [22779.484008] [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [tty_poll+145/160] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [do_sys_poll+617/880] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [__pollwait+0/304] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [thread_return+98/1306] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [lockdep_sys_exit_thunk+53/103] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [sys_poll+46/144] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [system_call_after_swapgs+123/128] system_call_after_swapgs+0x7b/0x80 Feb 6 12:25:09 localhost kernel: [22779.484008] [] system_call_after_swapgs+0x7b/0x80 Kernel .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Mon Feb 4 15:04:58 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_S
