From: Omari Stephens <xsdg@xsdg.org>
To: linux-kernel@vger.kernel.org
Subject: In-kernel deadlock of some sort with 2.6.39.2
Date: Wed, 13 Jul 2011 20:08:46 +0000 [thread overview]
Message-ID: <4E1DFB4E.7050107@xsdg.org> (raw)
Please CC me on responses, since I'm not on lkml.
### Short version:
Under 2.6.39.2, one of my machines regularly gets into a state where
processes end up in uninterruptible waits that never end. One peculiar
thing that happens is that attempts to stat(1) or read certain files
from procfs never return.
I am pretty familiar with compiling and running my own kernels, but not
so familiar with troubleshooting when non-obvious things go wrong. Any
suggestions would be appreciated, even if it's "we might've fixed
something related in version XYZ, try that one"
I've uploaded my config here:
http://web.mit.edu/~xsdg/Public/stuff/kernel/broken_2.6.39.2_config.txt
### Detailed version:
On one of my machines, I recently compiled and installed 2.6.39.2
alongside a switch from the nv driver to nouveau. This was specifically
to solve an issue where FF7 nightly would cause high CPU usage in X just
by virtue of painting the screen.
The upgrade did fix my X issues, FF7 is as smooth as could be hoped on
this machine, but now FF periodically (but repeatably, after a reboot)
stops responding. According to top, the system is about 94% IO-wait.:
Cpu0 : 3.7%us, 2.4%sy, 0.0%ni, 0.0%id, 93.9%wa, 0.0%hi, 0.0%si,
0.0%st
Oddly, I noticed that running `ps` would halt uninterruptibly. After
some further debugging, I discovered that attempting to stat (not even
read) certain files in procfs will never return. For instance:
19:36:38> [xsdg{perl}@/proc/4950]
$find | sort | xargs stat
[...]
File: `./environ'
Size: 0 Blocks: 0 IO Block: 1024 regular empty file
Device: 3h/3d Inode: 6413606 Links: 1
Access: (0400/-r--------) Uid: ( 1000/ xsdg) Gid: ( 1000/ xsdg)
Access: 2011-07-13 19:26:15.829482661 +0000
Modify: 2011-07-13 19:26:15.829482661 +0000
Change: 2011-07-13 19:26:15.829482661 +0000
[sits here indefinitely]
By the magical powers of deduction:
19:36:50> [xsdg{perl}@/proc/4950]
$l exe
[sits here indefinitely]
Oddly, I can stat cmdline with no issues, but if I try to _read_ it,
then it blocks. As you might imagine, I have no idea what process 4950 is.
19:56:16> [xsdg{perl}@/proc/4950]
$stat cmdline
File: `cmdline'
Size: 0 Blocks: 0 IO Block: 1024 regular empty file
Device: 3h/3d Inode: 3553148 Links: 1
Access: (0444/-r--r--r--) Uid: ( 1000/ xsdg) Gid: ( 1000/ xsdg)
Access: 2011-07-12 18:13:35.481767937 +0000
Modify: 2011-07-12 18:13:35.481767937 +0000
Change: 2011-07-12 18:13:35.481767937 +0000
19:56:18> [xsdg{perl}@/proc/4950]
$cat cmdline
[sits here indefinitely]
--xsdg
http://blog.doppler-photo.net/
reply other threads:[~2011-07-13 20:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4E1DFB4E.7050107@xsdg.org \
--to=xsdg@xsdg.org \
--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