From: Jeff Garzik <jgarzik@pobox.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: akpm@digeo.com
Subject: 2.5.60-BK reproducible oops, during LTP run
Date: Wed, 12 Feb 2003 14:32:36 -0500 [thread overview]
Message-ID: <3E4AA154.7070307@pobox.com> (raw)
I have reproduced the BUG in fs/buffer.c:2533 twice now. Test
conditions exactly the same, fsx-linux in one window, LTP in another window.
The machine stays alive for pings and sysrq's, but I cannot ssh into it
nor login at the console. sysrq-s initiates a sync of the root
filesystem on the ATA disk but never finishes. other sysrq's and pings
continues to work after the sysrq-s invocation.
Call trace from BUG, each time I hit it:
EIP in submit_bh
ll_rw_block
journal_commit_transaction
schedule
default_wake_function
kjournald
commit_timeout
kjournald
kernel_thread_helper
sysrq-t bits (I note truncate and sys_sync as common elements):
* shows that LTP test "ftest08" is running
* fsx-linux stack trace: io_schedule, __wait_on_buffer,
free_hot_cold_page, autoremove_wake_function, autoremovce_wake_function,
journal_invalidatepage, ext2_invalidatepage, do_invalidatepage,
truncate_complete_page, truncate_inode_pages, vmtruncate, inode_setattr,
ext3_setattr, notify_change, do_truncate, do_sys_ftruncate,
sys_ftruncate, syscall_call
* ftest08 stack trace, process 0: sys_wait4, do_fork,
default_wake_function, default_wake_function, sycall_call
* ftest08 trace, proc 1: __down, default_wake_function, __down_failed,
.text.ock.read_write, sys_llseek, sys_sync, syscall_call
* ftest08 trace, proc 2: do_readv_writev, __down, default_wake_function,
__down_failed, .text.lock.read_write, sys_llseek, syscall_call
* ftest08 trace, proc 3: sleep_on, default_wake_function,
log_wait_commit, journal_stop, journal_force_commit, write_inode,
__sync_single_inode, sync_sb_inodes, sync_inodes_sb, sync_inodes,
sys_sync, syscall_call
* ftest08 trace, proc 4: do_writepages, __down, default_wake_function,
__down_failed, .text.lock.read_write, sync_blockdev, sys_llseek,
sys_sync, syscall_call
* ftest08 trace, proc 5: sleep_on, default_wake_function,
log_wait_commit, journal_stop, journal_force_commit, ext3_force_commit,
ext3_sync_file, sys_fsync, syscall_call
sysrq-m bits:
free pages: 5552kB (0kB highmem)
active: 48451, inactive: 9478 dirty:10 writeback:0 free:1388
DMA free: 2368kB, min 128kB, low:256kB, high:384kB, active:3776kB,
inactive:6688kB
Normal free: 3184kB min:1020 low:2040 high:3060 active:190028 inactive:31224
swap cache: add 93, delete 92, find 24/26, race 0+0
free swap: 2096776kB
63472 pages of RAM
1471 reserved pages
27697 pages shared
1 pages swap cached
hardware bits:
via c3 cpu
gcc 3.2.2
kernel 2.5.60-bk2
one 40GB ATA/100 drive, running at ATA/100
256 MB RAM
next reply other threads:[~2003-02-12 19:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-12 19:32 Jeff Garzik [this message]
2003-02-13 7:07 ` 2.5.60-BK reproducible oops, during LTP run Andrew Morton
2003-02-13 7:25 ` Jeff Garzik
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=3E4AA154.7070307@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@digeo.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