Messages in this thread | | | Date | Tue, 18 May 1999 17:39:17 +0100 (GMT) | From | Tim Waugh <> | Subject | Re: a badblocks command causes kerlnel OOPS (fwd) |
| |
On Mon, 17 May 1999, Jan Kara wrote:
> I forward it here so somebody else might track bug too..
That oops was resolved against the wrong System.map. Here's the original oops:
VFS: brelse: Trying to free free buffer VFS: brelse: Trying to free free buffer VFS: brelse: Trying to free free buffer Unable to handle kernel paging request at virtual address e02b7400 current->tss.cr3 = 04c75000, %cr3 = 04c75000 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c0123236>] EFLAGS: 00010213 eax: 20120000 ebx: 00000000 ecx: c008c560 edx: c4c77f9c esi: c008c560 edi: 08048000 ebp: c4c77eb0 esp: c4c77d04 ds: 0018 es: 0018 ss: 0018 Process badblocks (pid: 1036, process nr: 14, stackpage=c4c77000) Stack: 00000000 c0123881 c008c560 c008c560 c2276ea0 c01abd2b c01238ff c008c560 c008c560 00000000 c008c560 c0126925 c008c560 c5ac35a0 ffffffea 00000000 00002400 00000008 0804a974 00001000 00000000 c251b000 00000000 c009aec0 Call Trace: [<c0123881>] [<c01238ff>] [<c0126925>] [<c0127b70>] [<c0127d97>] [<c0127dbc>] [<c0128a6b>] [<c011085f>] [<c011093a>] [<c0116e51>] [<c0109f05>] [<c0108e3c>] [<c0121dc5>] [<c0121f7e>] [<c0108da0>] [<c010002b>] Code: ff 88 00 74 19 c0 8b 51 34 85 d2 74 18 8b 01 85 c0 74 09 89 Segmentation fault
Here's the ksymoops report, against the correct System.map (from Petrosyan):
Options used: -V (default) -o /lib/modules/2.2.9/ (default) -k /proc/ksyms (default) -l /proc/modules (default) -m /boot/System.map (specified) -c 1 (default)
Unable to handle kernel paging request at virtual address e02b7400 current->tss.cr3 = 04c75000, %cr3 = 04c75000 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c0123236>] EFLAGS: 00010213 eax: 20120000 ebx: 00000000 ecx: c008c560 edx: c4c77f9c esi: c008c560 edi: 08048000 ebp: c4c77eb0 esp: c4c77d04 ds: 0018 es: 0018 ss: 0018 Process badblocks (pid: 1036, process nr: 14, stackpage=c4c77000) Stack: 00000000 c0123881 c008c560 c008c560 c2276ea0 c01abd2b c01238ff c008c560 c008c560 00000000 c008c560 c0126925 c008c560 c5ac35a0 ffffffea 00000000 00002400 00000008 0804a974 00001000 00000000 c251b000 00000000 c009aec0 Call Trace: [<c0123881>] [<c01238ff>] [<c0126925>] [<c0127b70>] [<c0127d97>] [<c0127dbc>] [<c0128a6b>] [<c011085f>] [<c011093a>] [<c0116e51>] [<c0109f05>] [<c0108e3c>] [<c0121dc5>] [<c0121f7e>] [<c0108da0>] [<c010002b>] Code: ff 88 00 74 19 c0 8b 51 34 85 d2 74 18 8b 01 85 c0 74 09 89
>>EIP: c0123236 <remove_from_queues+96/148> Trace: c0123881 <refile_buffer+4d/b8> Trace: c01238ff <__brelse+13/54> Trace: c0126925 <block_read+499/4e0> Trace: c0127b70 <search_binary_handler+54/114> Trace: c0127d97 <do_execve+167/1cc> Trace: c0127dbc <do_execve+18c/1cc> Trace: c0128a6b <lookup_dentry+15f/1e8> Trace: c011085f <update_process_times+5b/64> Trace: c010002b <startup_32+2b/11e> Code: c0123236 <remove_from_queues+96/148> 00000000 <_EIP>: <=== Code: c0123236 <remove_from_queues+96/148> 0: ff 88 00 74 19 c0 decl 0xc0197400(%eax) <=== Code: c012323c <remove_from_queues+9c/148> 6: 8b 51 34 movl 0x34(%ecx),%edx Code: c012323f <remove_from_queues+9f/148> 9: 85 d2 testl %edx,%edx Code: c0123241 <remove_from_queues+a1/148> b: 74 18 je c012325b <remove_from_queues+bb/148> Code: c0123243 <remove_from_queues+a3/148> d: 8b 01 movl (%ecx),%eax Code: c0123245 <remove_from_queues+a5/148> f: 85 c0 testl %eax,%eax Code: c0123247 <remove_from_queues+a7/148> 11: 74 09 je c0123252 <remove_from_queues+b2/148> Code: c0123249 <remove_from_queues+a9/148> 13: 89 00 movl %eax,(%eax)
Petrosyan, can you get this to happen again by running badblocks? If so I can send you a patch that will help us to diagnose this more effectively.
Tim. */
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |