Messages in this thread | | | Date | Sat, 20 Dec 2003 23:51:39 +0100 | From | Oliver Teuber <> | Subject | Re: 4 Oops with 2.4.23 |
| |
Marcelo Tosatti schrieb:
>On Fri, 19 Dec 2003, Oliver Teuber wrote: > > > >>Hans Reiser schrieb: >> >> >> >>>Vladimir Saveliev wrote: >>> >>> >>> >>>>>hi >>>>> >>>>>i had 4 Oops while running 2.4.23. >>>>> >>>>>all 4 Oops occured at the same address. >>>>> >>>>>two traces attached ... >>>>> >>>>>ksymoops 2.4.9 on i686 2.4.23. Options used >>>>> -v /usr/src/linux/vmlinux (specified) >>>>> -k /proc/ksyms (default) >>>>> -l /proc/modules (default) >>>>> -o /lib/modules/2.4.23/ (default) >>>>> -m /usr/src/linux/System.map (default) >>>>> >>>>>Reading Oops report from the terminal >>>>>Oops: 0000 >>>>>CPU: 0 >>>>>EIP: 0010:[<c0119780>] Not tainted >>>>>Using defaults from ksymoops -t elf32-i386 -a i386 >>>>>EFLAGS: 00010086 >>>>>eax: c83a643c ebx: 00000000 ecx: 00000001 edx: 00000001 >>>>>esi: ce6d2980 edi: c83a643c ebp: cdb61a6c esp: cdb61a54 >>>>>ds: 0018 es: 0018 ss: 0018 >>>>>Process lpd (pid: 4136, stackpage=cdb61000) >>>>>Stack: 00000001 00000286 00000001 c41c1680 ce6d2980 00000000 00000046 >>>>>c02282d4 >>>>> cfca1400 00000000 00000202 c41c1680 c022789b c41c1680 c8c9b180 >>>>>c02288d1 >>>>> ce6d2980 cfca1560 fffffffd c022c7cb ce6d2980 cdb61af0 00000001 >>>>>c033aa88 >>>>>Call Trace: [<c02282d4>] [<c022789b>] [<c02288d1>] [<c022c7cb>] >>>>>[<c0120bb1>] >>>>> [<c010aa19>] [<c010cf18>] [<d094c782>] [<d094cbe4>] [<d094c3c0>] >>>>>[<d094d048>] >>>>> [<d094ead2>] [<d094f0f2>] [<d095e82f>] [<d093d719>] [<d095e83d>] >>>>>[<d0955057>] >>>>> [<d093ebd0>] [<d095e83d>] [<c0150356>] [<c013e224>] [<c013cd7d>] >>>>>[<c013ce0b>] >>>>> [<c0108f27>] >>>>>Code: 8b 13 0f 18 02 39 c3 74 76 8d b4 26 00 00 00 00 8b 4b fc 8b >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>EIP; c0119780 <__wake_up+20/b0> <===== >>>>>>> >>>>>>>eax; c83a643c <_end+80372e8/1057bf0c> >>>>>>>esi; ce6d2980 <_end+e36382c/1057bf0c> >>>>>>>edi; c83a643c <_end+80372e8/1057bf0c> >>>>>>>ebp; cdb61a6c <_end+d7f2918/1057bf0c> >>>>>>>esp; cdb61a54 <_end+d7f2900/1057bf0c> >>>>>>> >>>>>>> >>>>>>> >>>>>Trace; c02282d4 <sock_def_write_space+64/90> >>>>>Trace; c022789b <sock_wfree+3b/40> >>>>>Trace; c02288d1 <__kfree_skb+41/100> >>>>>Trace; c022c7cb <net_tx_action+2b/b0> >>>>>Trace; c0120bb1 <do_softirq+51/a0> >>>>>Trace; c010aa19 <do_IRQ+99/b0> >>>>>Trace; c010cf18 <call_do_IRQ+5/d> >>>>>Trace; d094c782 <[reiserfs]comp_keys+362/3f0> >>>>>Trace; d094cbe4 <[reiserfs]is_tree_node+64/70> >>>>>Trace; d094c3c0 <[reiserfs]__constant_memcpy+c0/120> >>>>>Trace; d094d048 <[reiserfs]search_for_position_by_key+f8/4c0> >>>>>Trace; d094ead2 <[reiserfs]reiserfs_cut_from_item+222/4b0> >>>>>Trace; d094f0f2 <[reiserfs]reiserfs_do_truncate+322/580> >>>>>Trace; d095e82f <[reiserfs].rodata.end+5ab0/5ca1> >>>>>Trace; d093d719 <[reiserfs]reiserfs_truncate_file+e9/230> >>>>>Trace; d095e83d <[reiserfs].rodata.end+5abe/5ca1> >>>>>Trace; d0955057 <[reiserfs]journal_end+27/30> >>>>>Trace; d093ebd0 <[reiserfs]reiserfs_file_release+3a0/450> >>>>> >>>>> >>>> >>>> >>>I would prefer that you first determine the likely cause of his >>>needing to use fsck.... Did he ever use write caching, command >>>queueing, what exactly is the nature of the on-disk corruptio >>> >>> >>i don't think that this oops is related to reiserfs. i am not a kernel >>hacker but >>every oops occurred in wake_up called from <sock_def_write_space+64/90> ?! >> >>attached is a system description created with hwinfo from suse. >> >>the system is in production but i can originate an fsck to see if the >>filesystem >>is damaged. >> >> > >Oliver, > >Can you run the setup on a ext2 filesystem? > > > hi
there is one external raid subsystem attached to the server.
server:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 29494432 8175704 21318728 28% / /dev/sda1 309655092 74835000 219090452 26% /array1 /dev/sda2 265932584 27000232 225423696 11% /array2 tmpfs 127744 0 127744 0% /dev/shm
ext3 is used on sda1 and sda2.
i will try to re-install the server on monday to use ext2 on /
the server-crash occurres often while our users try to print via the printer-spooler on that server. the printer- spooler is part of an apple mac fileserver named helios.
printing via the spooler -> network and filesystem load ...
any other things i could do to spot the problem/bug?
please take a look at this oops too ... (i have two more oops with the same eip)
ksymoops 2.4.9 on i686 2.4.23. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.23/ (default) -m /usr/src/linux/System.map (default)
Reading Oops report from the terminal Oops: 0000 CPU: 0 EIP: 0010:[<c0119780>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: c86ef23c ebx: 00000000 ecx: 00000001 edx: 00000001 esi: ce074e80 edi: c86ef23c ebp: cee19f40 esp: cee19f28 ds: 0018 es: 0018 ss: 0018 Process if (pid: 4571, stackpage=cee19000) Stack: 00000001 00000286 00000001 cd876c80 ce074e80 00000000 00000046 c02282d4 00001000 00000000 00000202 cd876c80 c022789b cd876c80 cb01ca80 c02288d1 ce074e80 cfcbcd60 fffffffd c022c7cb ce074e80 cee19fc4 00000001 c033aa88 Call Trace: [<c02282d4>] [<c022789b>] [<c02288d1>] [<c022c7cb>] [<c0120bb1>] [<c010aa19>] [<c010cf18>] Code: 8b 13 0f 18 02 39 c3 74 76 8d b4 26 00 00 00 00 8b 4b fc 8b
>>EIP; c0119780 <__wake_up+20/b0> <=====
>>eax; c86ef23c <_end+83800e8/1057bf0c> >>esi; ce074e80 <_end+dd05d2c/1057bf0c> >>edi; c86ef23c <_end+83800e8/1057bf0c> >>ebp; cee19f40 <_end+eaaadec/1057bf0c> >>esp; cee19f28 <_end+eaaadd4/1057bf0c>
Trace; c02282d4 <sock_def_write_space+64/90> Trace; c022789b <sock_wfree+3b/40> Trace; c02288d1 <__kfree_skb+41/100> Trace; c022c7cb <net_tx_action+2b/b0> Trace; c0120bb1 <do_softirq+51/a0> Trace; c010aa19 <do_IRQ+99/b0> Trace; c010cf18 <call_do_IRQ+5/d>
Code; c0119780 <__wake_up+20/b0> 00000000 <_EIP>: Code; c0119780 <__wake_up+20/b0> <===== 0: 8b 13 mov (%ebx),%edx <===== Code; c0119782 <__wake_up+22/b0> 2: 0f 18 02 prefetchnta (%edx) Code; c0119785 <__wake_up+25/b0> 5: 39 c3 cmp %eax,%ebx Code; c0119787 <__wake_up+27/b0> 7: 74 76 je 7f <_EIP+0x7f> Code; c0119789 <__wake_up+29/b0> 9: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi Code; c0119790 <__wake_up+30/b0> 10: 8b 4b fc mov 0xfffffffc(%ebx),%ecx Code; c0119793 <__wake_up+33/b0> 13: 8b 00 mov (%eax),%eax
<0>Kernel panic: Aiee, killing interrupt handler!
- 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/
| |