Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 21 Nov 2001 00:12:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 21 Nov 2001 00:12:04 -0500 Received: from vger.timpanogas.org ([207.109.151.240]:19586 "EHLO vger.timpanogas.org") by vger.kernel.org with ESMTP id ; Wed, 21 Nov 2001 00:11:57 -0500 Date: Tue, 20 Nov 2001 23:14:49 -0700 From: "Jeff V. Merkey" To: linux-kernel@vger.kernel.org Cc: jmerkey@timpanogas.org Subject: [VMBUG] 2.4.15-pre7 Severe VM Bugs in 2.4.15-pre7 Message-ID: <20011120231449.A3637@vger.timpanogas.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached oops results from using NWFS on 2.4.15-pre7 with the 3Ware adapter. I do not know what is happening here, but looks like some sort of severe memory corruption. In any event, a very nasty looking bug. I am looking through my code to see if I caused this, however, the oops indicates my code does not seem to be involved in this oops. I have noticed of late some severe stability issues with VM in 2.4.X and I noticed Linus addressing some problems with the compiler generating garbage instructions. I do not know if this is related. Please advise, and let me know if anyone wants me to run down further info. I do exercise the memory and IO subsystem a little more strenuously than the buffer cache and perhaps I am stressing the VM in a different way. Could also just simply be a bug I am causing. Jeff --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nwfs.oops" ksymoops 2.4.0 on i686 2.4.15-pre7. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.15-pre7/ (default) -m /boot/System.map-2.4.15-pre7 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Error (regular_file): read_system_map stat /boot/System.map-2.4.15-pre7 failed Nov 20 09:58:50 scimitar kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Nov 20 09:58:50 scimitar kernel: c0172f1b Nov 20 09:58:50 scimitar kernel: *pde = 00000000 Nov 20 09:58:50 scimitar kernel: Oops: 0000 Nov 20 09:58:50 scimitar kernel: CPU: 1 Nov 20 09:58:50 scimitar kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Nov 20 09:58:50 scimitar kernel: EFLAGS: 00010246 Nov 20 09:58:50 scimitar kernel: eax: 00000000 ebx: cea30000 ecx: cea30018 edx: 000002b8 Nov 20 09:58:50 scimitar kernel: esi: 00000000 edi: 00000000 ebp: 0000002f esp: cead5ab8 Nov 20 09:58:50 scimitar kernel: ds: 0018 es: 0018 ss: 0018 Nov 20 09:58:50 scimitar kernel: Process mount (pid: 720, stackpage=cead5000) Nov 20 09:58:50 scimitar kernel: Stack: cea30018 c0173e29 cea30018 00000080 00000009 cea30018 00000003 00000004 Nov 20 09:58:50 scimitar kernel: 000000ae 09c23fff 00000000 c1556600 00000000 00000000 00000009 c019b9bb Nov 20 09:58:50 scimitar kernel: cead5b28 00001000 cead5b5c 00001000 c030f4fc 00000009 c0172e39 c0172e7f Nov 20 09:58:50 scimitar kernel: Call Trace: [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] [] [] Nov 20 09:58:50 scimitar kernel: [] [] [] [] Nov 20 09:58:50 scimitar kernel: Code: 8b 50 08 2b 51 f0 89 50 08 8b 41 f4 ff 48 04 8b 41 f8 83 f8 >>EIP; c0172f1b <===== Trace; c0173e29 Trace; c019b9bb Trace; c0172e39 Trace; c0172e7f Trace; c019a64a Trace; c0124382 Trace; c014463c Trace; c013c560 Trace; c0295e70 Trace; c01124ba <__verify_write+3ba/8c0> Trace; c0176127 Trace; c0124d91 Trace; c0124da2 Trace; c0112320 <__verify_write+220/8c0> Trace; c010700c <__read_lock_failed+1290/2704> Trace; c0124804 Trace; c0112320 <__verify_write+220/8c0> Trace; c010700c <__read_lock_failed+1290/2704> Trace; c02949fb Trace; c014bf8c Trace; c014cf8f Trace; c013c560 Trace; c012d9e1 <__alloc_pages+41/180> Trace; c01241ba Trace; c0124214 Trace; c0124382 Trace; c012779c Trace; c01277c9 Trace; c01124ba <__verify_write+3ba/8c0> Trace; c0128742 Trace; c0183a39 Trace; c01277c9 Trace; c0154922 Trace; c01125f0 <__verify_write+4f0/8c0> Trace; c0294922 <__generic_copy_from_user+32/60> Trace; c0137fe1 Trace; c0138460 Trace; c013894f Trace; c0148f53 Trace; c0112320 <__verify_write+220/8c0> Trace; c010700c <__read_lock_failed+1290/2704> Trace; c01491ec Trace; c014905c Trace; c01492b0 Trace; c0106f1b <__read_lock_failed+119f/2704> Code; c0172f1b 00000000 <_EIP>: Code; c0172f1b <===== 0: 8b 50 08 mov 0x8(%eax),%edx <===== Code; c0172f1e 3: 2b 51 f0 sub 0xfffffff0(%ecx),%edx Code; c0172f21 6: 89 50 08 mov %edx,0x8(%eax) Code; c0172f24 9: 8b 41 f4 mov 0xfffffff4(%ecx),%eax Code; c0172f27 c: ff 48 04 decl 0x4(%eax) Code; c0172f2a f: 8b 41 f8 mov 0xfffffff8(%ecx),%eax Code; c0172f2d 12: 83 f8 00 cmp $0x0,%eax 2 warnings and 1 error issued. Results may not be reliable. --EVF5PPMfhYS0aIcm-- - 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/