Jim Henderson wrote:
> 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.
Wow, it must have taken quite some effort
to patch a 2.2 kernel for ext3!
OK, assuming you really mean 2.4.14, there
is a patch floating around the list for that -
I had a compaq 6500 that would scribble
on the disk and then lock up hard at some
random point in time - but that behaviour
could be triggered immediatley by running
dbench - Look for the compaq patches from
Jens Axboe or better yet, lose 2.4.14 and go
straight to 2.4.16-pre1, since it has the ida
raid fixes, and ext3 support already.
cu
jjs
> 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/
-
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