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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:20 EST