From: Jim Henderson <hendersj@mindspring.com>
To: linux-kernel@vger.kernel.org
Subject: PROBLEM: kernel BUG at filemap.c:791
Date: Sun, 25 Nov 2001 15:17:44 -0700 [thread overview]
Message-ID: <3C016E08.3C2D2537@mindspring.com> (raw)
After compiling a 2.2.14 kernel on one of my systems, I've started
receiving this problem. Kernel is patched with the ext3 filesystem
patches, however running without ext3 being used results in this problem
as well.
This can happen at any time, I've seen it during startup and after the
system has been running for a couple of days; it is reproducable, but
not at will (ie, it's a given that it will happen but unknown as to what
causes it). Previous kernels I've run (2.4.2 and 2.4.6) do not exhibit
this problem.
Here's the crash info with symbols resolved:
--- snip ---
ksymoops 2.4.0 on i486 2.4.6. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.14/ (specified)
-m /boot/System.map-2.4.14 (specified)
No modules in ksyms, skipping objects
kernel BUG at filemap.c:791!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0122938>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 0000001d ebx: c1133980 ecx: c0270660 edx: 00006181
esi: c0080134 edi: c11e3c00 ebp: 00000001 esp: c4ef5b50
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 365, stackpage=c4ef5000)
Stack: c022640b 00000317 00000000 c0080134 c01abbb4 c4cc96c0 00000001
00000002
c011a834 00000001 c02c65c0 00000000 c11444e0 24000001 0000000e
c4ef5bd4
c01082aa 0000000e c11e3c00 c4ef5bd4 c4ef5bd4 0000000e c02bcac0
c11444e0
Call Trace: [<c01abbb4>] [<c011a834>] [<c01082aa>] [<c010842d>]
[<c01ab6bc>]
[<c01176a0>] [<c0117473>] [<c010845c>] [<c011a740>] [<c019ec3a>]
[<c0117473>]
[<c010845c>] [<c019f2ea>] [<c019e75e>] [<c0117858>] [<c012ed26>]
[<c011778b>]
[<c01176a0>] [<c012f985>] [<c010845c>] [<c01ab8ba>] [<c01d8b6c>]
[<c01da75d>]
[<c020966f>] [<c02096cf>] [<c012fc95>] [<c0130640>] [<c0130b14>]
[<c0124db6>]
[<c0124e16>] [<c012e248>] [<c0124900>] [<c0161d4a>] [<c015fb74>]
[<c012f1aa>]
[<c0106ef3>]
Code: 0f 0b 5a 59 8d 43 28 8d 73 24 39 43 28 74 19 89 f0 5b b9 01
>>EIP; c0122938 <unlock_page+28/60> <=====
Trace; c01abbb4 <do_ida_intr+1f4/270>
Trace; c011a834 <timer_bh+24/250>
Trace; c01082aa <handle_IRQ_event+3a/70>
Trace; c010842d <do_IRQ+6d/b0>
Trace; c01ab6bc <do_ida_request+dc/2f0>
Trace; c01176a0 <tasklet_hi_action+50/80>
Trace; c0117473 <do_softirq+53/a0>
Trace; c010845c <do_IRQ+9c/b0>
Trace; c011a740 <update_process_times+20/b0>
Trace; c019ec3a <__make_request+fa/670>
Trace; c0117473 <do_softirq+53/a0>
Trace; c010845c <do_IRQ+9c/b0>
Trace; c019f2ea <generic_make_request+13a/150>
Trace; c019e75e <generic_unplug_device+1e/30>
Trace; c0117858 <__run_task_queue+48/60>
Trace; c012ed26 <__wait_on_buffer+56/90>
Trace; c011778b <bh_action+1b/50>
Trace; c01176a0 <tasklet_hi_action+50/80>
Trace; c012f985 <fsync_inode_data_buffers+e5/120>
Trace; c010845c <do_IRQ+9c/b0>
Trace; c01ab8ba <do_ida_request+2da/2f0>
Trace; c01d8b6c <__kfree_skb+dc/e0>
Trace; c01da75d <skb_free_datagram+1d/30>
Trace; c020966f <unix_dgram_recvmsg+9f/110>
Trace; c02096cf <unix_dgram_recvmsg+ff/110>
Trace; c012fc95 <__refile_buffer+55/60>
Trace; c0130640 <__block_commit_write+a0/c0>
Trace; c0130b14 <generic_commit_write+54/60>
Trace; c0124db6 <generic_file_write+4b6/590>
Trace; c0124e16 <generic_file_write+516/590>
Trace; c012e248 <do_readv_writev+1d8/260>
Trace; c0124900 <generic_file_write+0/590>
Trace; c0161d4a <ext2_update_inode+38a/3a0>
Trace; c015fb74 <ext2_fsync_inode+14/50>
Trace; c012f1aa <sys_fsync+5a/90>
Trace; c0106ef3 <system_call+33/40>
Code; c0122938 <unlock_page+28/60>
00000000 <_EIP>:
Code; c0122938 <unlock_page+28/60> <=====
0: 0f 0b ud2a <=====
Code; c012293a <unlock_page+2a/60>
2: 5a pop %edx
Code; c012293b <unlock_page+2b/60>
3: 59 pop %ecx
Code; c012293c <unlock_page+2c/60>
4: 8d 43 28 lea 0x28(%ebx),%eax
Code; c012293f <unlock_page+2f/60>
7: 8d 73 24 lea 0x24(%ebx),%esi
Code; c0122942 <unlock_page+32/60>
a: 39 43 28 cmp %eax,0x28(%ebx)
Code; c0122945 <unlock_page+35/60>
d: 74 19 je 28 <_EIP+0x28> c0122960
<unlock_page+50/60>
Code; c0122947 <unlock_page+37/60>
f: 89 f0 mov %esi,%eax
Code; c0122949 <unlock_page+39/60>
11: 5b pop %ebx
Code; c012294a <unlock_page+3a/60>
12: b9 01 00 00 00 mov $0x1,%ecx
<0>Kernel panic: Aiee, killing interrupt handler!
--- snip ---
The problem is reported in the unlock_page function in filemap.c with
this bit of code:
if (!test_and_clear_bit(PG_locked, &(page)->flags))
BUG();
Module-wise, the only options selected are for LAN drivers (not
including the one actually being used) and a SYM710 SCSI controller (for
an external CD-ROM drive that is powered off).
The following info comes from a stable 2.4.6 kernel procfs output (since
2.2.14 doesn't want to stay running long enough for me to get this info
from there):
CPU Info:
--- snip ---
processor : 0
vendor_id : AuthenticAMD
cpu family : 4
model : 14
model name : Am5x86-WT
stepping : 4
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu
bogomips : 66.35
--- snip ---
No SCSI drivers loaded, but a Compaq SMART controller is in use:
--- snip ---
ida0: Compaq SMART Controller
Board ID: 0x2040110e
Firmware Revision: 2.26
Controller Sig: 0x2ae7909f
Memory Address: 0x00000000
I/O Port: 0x5000
IRQ: 14
Logical drives: 1
Physical drives: 2
Current Q depth: 0
Max Q depth since init: 42
Logical Drive Info:
ida/c0d0: blksz=512 nr_blks=8217120
nr_allocs = 3961
nr_frees = 3961
--- snip ---
The system is an EISA system, Compaq Prosignia VS with 80 MB of RAM and
an AMD K5 processor, integrated AMD network adapter, Compaq SMART
controller.
The only other patch applied to this kernel is the one suggested in this
list for loopback device (loop.c to remove the deactivate_page(page)
calls which prevent the kernel from properly compiling.
I have a second system (Celeron 300A processor, 640 MB of RAM, and IDE
drives) that runs 2.2.14 with these same patches with no problems that
I've seen.
Please let me know if there's any other information needed to diagnose
this problem - this is the first time I've ever had a kernel crash, and
I hope I've included all the relevant information here. I don't
subscribe to the linux-kernel list, so all correspondence should be
copied to me directly as well if possible.
Thanks,
Jim
next reply other threads:[~2001-11-25 22:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-25 22:17 Jim Henderson [this message]
2001-11-25 23:10 ` PROBLEM: kernel BUG at filemap.c:791 J Sloan
2001-11-25 23:17 ` Jim Henderson
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=3C016E08.3C2D2537@mindspring.com \
--to=hendersj@mindspring.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