Re: 2.4.22-pre lockups (now decoded oops for pre10)

From: Stephan von Krawczynski (skraw_at_ithnet.com)
Date: 08/07/03

Next message: Tigran Aivazian: "Re: Loading Pentium III microcode under Linux - catch 22!"

Previous message: Alan Cox: "Re: pivot_root solved by patch to 2.4.22-pre7"
In reply to: Marcelo Tosatti: "Re: 2.4.22-pre lockups (now decoded oops for pre10)"
Next in thread: Stephan von Krawczynski: "Re: 2.4.22-pre lockups (now decoded oops for pre10)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Thu, 7 Aug 2003 17:52:13 +0200
To: Marcelo Tosatti <marcelo@conectiva.com.br>

On Thu, 7 Aug 2003 09:45:36 -0300 (BRT)
Marcelo Tosatti <marcelo@conectiva.com.br> wrote:

> The decoded oops should be sufficient.

Well, how about this one:

ksymoops 2.4.8 on i686 2.4.22-rc1. Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.22-rc1/ (default)
     -m /boot/System.map-2.4.22-rc1 (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.

Unable to handle kernel paging request at virtual address 63eabdb3
c0145f31
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0145f31>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00000000 ebx: 00000000 ecx: 00000061 edx: 63eabd93
esi: 00000000 edi: 00001000 ebp: 00000000 esp: c34f7e60
ds: 0018 es: 0018 ss: 0018
Process kupdated (pid: 7, stackpage=c34f7000)
Stack: 00000000 f7afb1f0 c0146018 00000000 c01312e9 00000000 c1849dd0 00001000
       00001000 00000803 c014823a c1849dd0 00001000 00000000 f79b7fa4 00001e18
       c0148428 f79b7fa4 00001e18 00001000 e9640000 00000000 00000803 00001000
Call Trace: [<c0146018>] [<c01312e9>] [<c014823a>] [<c0148428>] [<c0145b36>]
  [<c0197328>] [<c019ceb9>] [<c019c4f5>] [<c0188e94>] [<c01498cb>] [<c014887c>]
  [<c0148be9>] [<c0105000>] [<c010592e>] [<c0148af0>]
Code: 8b 42 20 a3 30 c6 37 c0 8d 41 ff a3 34 c6 37 c0 c6 05 c0 bb

>>EIP; c0145f31 <get_unused_buffer_head+21/b0> <=====

>>esp; c34f7e60 <_end+314cc40/3852ee40>

Trace; c0146018 <create_buffers+28/100>
Trace; c01312e9 <find_or_create_page+109/110>
Trace; c014823a <grow_dev_page+7a/c0>
Trace; c0148428 <grow_buffers+98/110>
Trace; c0145b36 <getblk+46/80>
Trace; c0197328 <journal_getblk+28/30>
Trace; c019ceb9 <do_journal_end+139/bb0>
Trace; c019c4f5 <flush_old_commits+135/1d0>
Trace; c0188e94 <reiserfs_write_super+64/90>
Trace; c01498cb <sync_supers+14b/170>
Trace; c014887c <sync_old_buffers+3c/b0>
Trace; c0148be9 <kupdate+f9/130>
Trace; c0105000 <_stext+0/0>
Trace; c010592e <arch_kernel_thread+2e/40>
Trace; c0148af0 <kupdate+0/130>

Code; c0145f31 <get_unused_buffer_head+21/b0>
00000000 <_EIP>:
Code; c0145f31 <get_unused_buffer_head+21/b0> <=====
   0: 8b 42 20 mov 0x20(%edx),%eax <=====
Code; c0145f34 <get_unused_buffer_head+24/b0>
   3: a3 30 c6 37 c0 mov %eax,0xc037c630
Code; c0145f39 <get_unused_buffer_head+29/b0>
   8: 8d 41 ff lea 0xffffffff(%ecx),%eax
Code; c0145f3c <get_unused_buffer_head+2c/b0>
   b: a3 34 c6 37 c0 mov %eax,0xc037c634
Code; c0145f41 <get_unused_buffer_head+31/b0>
  10: c6 05 c0 bb 00 00 00 movb $0x0,0xbbc0

1 warning issued. Results may not be reliable.

After that I received this one:

NMI Watchdog detected LOCKUP on CPU1, eip c011a747, registers:
CPU: 1
EIP: 0010:[<c011a747>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000082
eax: cef0b8dc ebx: cef0b894 ecx: 00000001 edx: 00000003
esi: 00000008 edi: cef0b8dc ebp: ec8efe48 esp: ec8efe28
ds: 0018 es: 0018 ss: 0018
Process tar (pid: 13603, stackpage=ec8ef000)
Stack: 00000000 cef0b894 00000000 00000282 00000003 cef0b894 00000008 cef0b8dc
       00000000 c01c4f41 00000000 cef0b894 00000000 0001679d cef0b894 00001000
       c0146c87 00000000 cef0b894 cef0b894 00000004 cef0b894 ec8ee000 00000001
Call Trace: [<c01c4f41>] [<c0146c87>] [<c013ae92>] [<c0119630>] [<c0130d7e>]
  [<c017ff50>] [<c013146f>] [<c0131751>] [<c0131d50>] [<c0131ffc>] [<c0131d50>]
  [<c014328b>] [<c010782f>]
Code: 7e f9 e9 d9 ec ff ff 80 38 00 f3 90 7e f9 e9 5d ed ff ff 80

>>EIP; c011a747 <.text.lock.sched+3f/178> <=====

>>eax; cef0b8dc <_end+eb606bc/3852ee40>
>>ebx; cef0b894 <_end+eb60674/3852ee40>
>>edi; cef0b8dc <_end+eb606bc/3852ee40>
>>ebp; ec8efe48 <_end+2c544c28/3852ee40>
>>esp; ec8efe28 <_end+2c544c08/3852ee40>

Trace; c01c4f41 <submit_bh+a1/c0>
Trace; c0146c87 <block_read_full_page+2d7/2f0>
Trace; c013ae92 <__alloc_pages+42/190>
Trace; c0119630 <wait_for_completion+70/b0>
Trace; c0130d7e <page_cache_read+be/e0>
Trace; c017ff50 <reiserfs_get_block+0/1490>
Trace; c013146f <generic_file_readahead+af/1a0>
Trace; c0131751 <do_generic_file_read+1c1/470>
Trace; c0131d50 <file_read_actor+0/110>
Trace; c0131ffc <generic_file_read+19c/1b0>
Trace; c0131d50 <file_read_actor+0/110>
Trace; c014328b <sys_read+9b/180>
Trace; c010782f <system_call+33/38>

Code; c011a747 <.text.lock.sched+3f/178>
00000000 <_EIP>:
Code; c011a747 <.text.lock.sched+3f/178> <=====
   0: 7e f9 jle fffffffb <_EIP+0xfffffffb> <=====
Code; c011a749 <.text.lock.sched+41/178>
   2: e9 d9 ec ff ff jmp ffffece0 <_EIP+0xffffece0>
Code; c011a74e <.text.lock.sched+46/178>
   7: 80 38 00 cmpb $0x0,(%eax)
Code; c011a751 <.text.lock.sched+49/178>
   a: f3 90 repz nop
Code; c011a753 <.text.lock.sched+4b/178>
   c: 7e f9 jle 7 <_EIP+0x7>
Code; c011a755 <.text.lock.sched+4d/178>
   e: e9 5d ed ff ff jmp ffffed70 <_EIP+0xffffed70>
Code; c011a75a <.text.lock.sched+52/178>
  13: 80 00 00 addb $0x0,(%eax)

1 warning issued. Results may not be reliable.

There were no I/O errors or any other spectacular things happening. It just
died while I was sitting right next to it during the verify run of tar.

Regards,
Stephan
-
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/

Next message: Tigran Aivazian: "Re: Loading Pentium III microcode under Linux - catch 22!"

Previous message: Alan Cox: "Re: pivot_root solved by patch to 2.4.22-pre7"
In reply to: Marcelo Tosatti: "Re: 2.4.22-pre lockups (now decoded oops for pre10)"
Next in thread: Stephan von Krawczynski: "Re: 2.4.22-pre lockups (now decoded oops for pre10)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Relevant Pages

bug: hid module crashed
... Warning: You did not tell me where to find symbol information. ... assume that the log matches the kernel and modules that are running ... If the current kernel and/or modules do not match the log, ... Trace; f899c23e ...
(Linux-Kernel)
Bug Report: 2.4.22 3ware hang on dying drive
... Warning: You did not tell me where to find symbol information. ... assume that the log matches the kernel and modules that are running ... If the current kernel and/or modules do not match the log, ...
(Linux-Kernel)
2.6.0test3mm2oops in mm/filemap:1930
... Warning: You did not tell me where to find symbol information. ... assume that the log matches the kernel and modules that are running ... If the current kernel and/or modules do not match the log, ...
(Linux-Kernel)
Re: [PATCH] Re: More than 2Gb problem (dvb related) ?
... Warning: You did not tell me where to find symbol information. ... If the current kernel and/or modules do not match the log, ... map, modules, ksyms etc. ksymoops -h explains the options. ...
(Linux-Kernel)
Freeze on 2.4 kernels.
... We tried with the standard kernel with the only ... Warning: You did not tell me where to find symbol information. ... assume that the log matches the kernel and modules that are running ... Warning: mismatch on symbol ip_conntrack_destroyed, ...
(Linux-Kernel)