From: Kevin Turner <acapnotic@users.sourceforge.net>
To: linux-kernel@vger.kernel.org
Subject: [2.4.1] system goes glacial, Reiser on /usr doesn't sync
Date: Tue, 20 Feb 2001 02:16:09 -0800 [thread overview]
Message-ID: <20010220021609.B11523@troglodyte.menefee> (raw)
Version:
Linux version 2.4.1-pre12 (gcc version 2.95.3 20010125 (prerelease))
Possible suspect players:
dpkg seems to trigger the bug
ReiserFS is the partition that doesn't sync
binfmt_misc shows up in the call traces.
Symptoms:
The system assumes glacial speeds. If you're *lucky*, you'll see one
widget re-paint in X before the next ice age. Ctrl-alt-delete is
unresponsive, as are attempts to start proccesses via the network or
joystick port. Keypresses to programs such as getty are not echoed.
All program output to console and network is stopped dead. If you leave
for a several-hour-long coffee break and come back to it, there's still
no evidence that you banged on the keyboard.
What does work: If not in X, I may switch between VTs. Keypresses are
echoed on VTs without running processes. And the machine still pings.
Occasionally (a few times a minute at most), you'll see the HDD LED
blink.
When it happens: Sometimes, not always, when accessing the package
database or updating installed packages with the Debian's "dpkg" tool.
When it *didn't* happen: before I switched to kernel 2.4.x.
Debugging information:
After I had about enough of this, I recompiled the kernel with
CONFIG_REISERFS_CHECK and Magic SysRq. ReiserFS gives no debugging
messages of any sort during these episodes. Magic SysRq, however, does
work.
Magic-tErminate clears everything up and the system resumes normal
operation.
Magic-Sync appears not to work, as "Ok" and "Done" don't appear. But
after Magic-E, they do show up. Logs show that one partition actually
sync'd before termination, the others didn't. The partition where it
stalled just so happens to be a ReiserFS partition (3.5.x format).
kernel: SysRq: Emergency Sync
kernel: Syncing device 03:01 ... OK
kernel: Syncing device 16:02 ... <6>SysRq: Terminate All Tasks
kernel: OK
kernel: Syncing device 16:01 ... OK
kernel: Syncing device 03:03 ... OK
03:01 - ext2 /
16:02 - ReiFS /usr (note: /var is a symlink to /usr/root-var)
16:01 - ext2 /home
03:03 - ext2 /other
In ReiserFS's defense, /usr and /var are the patitions that dpkg was
most likely to have open files on, so perhaps that was it.
When I asked magic about running processes, it said that, among other
things, there was one apt-get, one dpkg, and three instances of
dpkg-deb. Of those, dpkg was the only one in 'R' state, the others were
'S'. Here's the call trace:
dpkg R 00000000 0 9278 9152 9285 (NOTLB)
Call Trace: [__alloc_pages+372/720] [grow_buffers+62/364]
[refill_freelist+28/48] [refill_freelist+41/48] [getblk+242/264]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-621596/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-970133/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-750728/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-976628/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-918150/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-976370/96]
[binfmt_misc:__insmod_binfmt_misc_O/lib/modules/2.4.1-pre12/kernel/fs/bi+-1080871/96]
[permission+42/48] [vfs_link+141/192] [sys_link+202/300]
Why binfmt_misc? I'll be burned if I know. It is true that one of the
packages I was installing this run was related to binfmt_misc
("binfmt-support"), but that wasn't the case the previous times this bug
has happened. On the other hand, I don't have call traces for those
times.
Linux version 2.4.1-pre12 (gcc version 2.95.3 20010125 (prerelease))
dpkg version 1.3.8.1
arch is i586 (GenuineIntel Pentium MMX)
disks are IDE
48 MB RAM
swap > 200 MB
Motherboard: ABIT-TX5
Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
More logs are posted at:
http://olug.cs.oberlin.edu/~kturner/bugs/glacial-2.4.1.html
The kernel's configuration is at:
http://olug.cs.oberlin.edu/~kturner/bugs/config-2.4.1-pre12
And yes, I will try upgrading to a newer kernel. But since I can't
quite reproduce this on demand yet, I thought I'd report it now while
the logbits are fresh.
--
Kevin Turner <acapnotic@users.sourceforge.net> | OpenPGP encryption welcome here
I usually subscribe to lists I post to, but for LKML I'm making an exception =)
Please feel free to CC me on all follow-ups.
next reply other threads:[~2001-02-20 10:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010220011536.A10778@troglodyte.menefee>
2001-02-20 10:16 ` Kevin Turner [this message]
2001-02-20 10:30 ` [2.4.1] system goes glacial, Reiser on /usr doesn't sync Keith Owens
2001-02-20 11:33 ` David
2001-02-20 12:24 ` Kevin Turner
2001-02-20 16:25 ` Chris Mason
2001-02-20 12:34 ` Kevin Turner
2001-02-23 23:35 ` Dwayne C. Litzenberger
2001-02-24 2:21 ` Dwayne C. Litzenberger
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=20010220021609.B11523@troglodyte.menefee \
--to=acapnotic@users.sourceforge.net \
--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