From: Andrew Morton <akpm@osdl.org>
To: Jesse Barnes <jbarnes@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.5-rc1-mm2
Date: Wed, 31 Mar 2004 12:06:34 -0800 [thread overview]
Message-ID: <20040331120634.39c959fd.akpm@osdl.org> (raw)
In-Reply-To: <200403311102.58136.jbarnes@sgi.com>
Jesse Barnes <jbarnes@sgi.com> wrote:
>
> On Tuesday 30 March 2004 11:44 am, Jesse Barnes wrote:
> > It looks like there's a bug in the sysrq implementation in the sn_serial
> > driver. Once the initial console is opened, sysrq no longer works. All
> > I've determined so far is that both CPUs in my box are in cpu_idle
> > somewhere... Anyway, I'll keep looking.
>
> Ah, now sysrq is working (just had to configure it correctly).
great.
> I've seen two
> backtraces in the hangs I've seen. The one I just reproduced looks like this:
>
> Enabling local filesystem quotas: [ OK ]
> Enabling swap space: [ OK ]
> INIT: Entering runlevel: 3
> Entering non-interactive startup
> Starting sysstat: [ OK ]
> Setting network parameters: ^[SYSSysRq : Show State
> [ bunch of kernel daemon traces ]
> ...
> S10network S a0000001000d8cf0 0 1143 1104 1156 (NOTLB)
>
> Call Trace:
> [<a0000001000c4200>] schedule+0xda0/0x1360
> sp=e00000387a27fdc0 bsp=e00000387a2791b8
> [<a0000001000d8cf0>] sys_wait4+0x450/0x660
> sp=e00000387a27fdd0 bsp=e00000387a2790f0
> [<a000000100011a60>] ia64_ret_from_syscall+0x0/0x20
> sp=e00000387a27fe30 bsp=e00000387a2790b8
> initlog S a0000001000e8650 0 1156 1143 1157 (NOTLB)
>
> Call Trace:
> [<a0000001000c4200>] schedule+0xda0/0x1360
> sp=e00000387af47ce0 bsp=e00000387af411a0
> [<a0000001000e8650>] schedule_timeout+0x190/0x1a0
> sp=e00000387af47cf0 bsp=e00000387af41168
> [<a00000010072eb70>] unix_wait_for_peer+0x210/0x220
> sp=e00000387af47d30 bsp=e00000387af41130
> [<a00000010072ee30>] unix_stream_connect+0x2b0/0xd00
> sp=e00000387af47d90 bsp=e00000387af41098
> [<a0000001006285f0>] sys_connect+0xf0/0x140
> sp=e00000387af47da0 bsp=e00000387af41020
> [<a000000100011a60>] ia64_ret_from_syscall+0x0/0x20
> sp=e00000387af47e30 bsp=e00000387af41020
> sysctl Z a0000001000d7330 0 1157 1156 (L-TLB)
>
> Call Trace:
> [<a0000001000c4200>] schedule+0xda0/0x1360
> sp=e00000347a5a7e20 bsp=e00000347a5a1078
> [<a0000001000d7330>] do_exit+0x490/0x500
> sp=e00000347a5a7e30 bsp=e00000347a5a1018
> [<a0000001000d77b0>] do_group_exit+0x290/0x360
> sp=e00000347a5a7e30 bsp=e00000347a5a0fe0
> [<a000000100011a60>] ia64_ret_from_syscall+0x0/0x20
> sp=e00000347a5a7e30 bsp=e00000347a5a0fc8
>
> and the CPU is in cpu_idle (somewhere, either default_idle or somewhere
> along that call path). The other failure was also a hang, and it looked
> like an infinite number of page faults was being generated, something
> like
>
> ...
> [<a0000001001233c0>] __free_pages+0x60/0x140
> sp=e0000030148ebb80 bsp=e0000030148e5388
> [<a00000010012b670>] slab_destroy+0x2f0/0x3e0
> sp=e0000030148ebb80 bsp=e0000030148e5338
> [<a000000100130120>] reap_timer_fnc+0x480/0x680
> sp=e0000030148ebb80 bsp=e0000030148e5268
> [<a0000001000e7ee0>] run_timer_softirq+0x380/0x5c0
> sp=e0000030148ebb90 bsp=e0000030148e51e0
> [<a0000001000dbd10>] __do_softirq+0x1d0/0x1e0
> sp=e0000030148ebbb0 bsp=e0000030148e5160
> [<a0000001000dbda0>] do_softirq+0x80/0xe0
> sp=e0000030148ebbb0 bsp=e0000030148e5100
> [<a000000100018300>] ia64_handle_irq+0x180/0x1c0
> sp=e0000030148ebbb0 bsp=e0000030148e50c0
> [<a000000100011c00>] ia64_leave_kernel+0x0/0x280
> sp=e0000030148ebbb0 bsp=e0000030148e50c0
> [<a000000100019d20>] default_idle+0xe0/0x180
>
So are we to assume that this is the offending process? That the periodic
slab reaping code has screwed up?
next prev parent reply other threads:[~2004-03-31 20:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 4:14 2.6.5-rc1-mm2 Andrew Morton
2004-03-18 16:01 ` 2.6.5-rc1-mm2 John Cherry
2004-03-18 20:31 ` USB: gphoto2 hangs, device disconnection oddity (was Re: 2.6.5-rc1-mm2) Sean Neakums
2004-03-19 9:27 ` 2.6.5-rc1-mm2 Marc-Christian Petersen
2004-03-30 19:27 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-03-30 19:36 ` 2.6.5-rc1-mm2 Andrew Morton
2004-03-30 19:44 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-03-31 19:02 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-03-31 20:06 ` Andrew Morton [this message]
2004-03-31 23:15 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-03-31 23:56 ` 2.6.5-rc1-mm2 Andrew Morton
2004-03-31 23:58 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-04-01 0:16 ` 2.6.5-rc1-mm2 Jesse Barnes
2004-04-01 19:28 ` 2.6.5-rc1-mm2 Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040331120634.39c959fd.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=jbarnes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®