From: Stephan von Krawczynski <skraw@ithnet.com>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: andrea@suse.de, linux-kernel@vger.kernel.org, green@namesys.com
Subject: Re: 2.4.22-pre lockups (now decoded oops for pre10)
Date: Thu, 7 Aug 2003 17:52:13 +0200 [thread overview]
Message-ID: <20030807175213.63a56f9b.skraw@ithnet.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0308070942540.6582-100000@logos.cnet>
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:
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.
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
next prev parent reply other threads:[~2003-08-07 15:54 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.55L.0307251040240.12645@freak.distro.conectiva>
[not found] ` <20030725174517.5b21116d.skraw@ithnet.com>
[not found] ` <Pine.LNX.4.55L.0307251545090.14733@freak.distro.conectiva>
2003-08-02 12:27 ` 2.4.22-pre lockups (decoded oops for pre8) Stephan von Krawczynski
2003-08-03 7:25 ` Willy Tarreau
2003-08-03 9:40 ` Stephan von Krawczynski
2003-08-05 16:40 ` Marcelo Tosatti
2003-08-06 2:37 ` Stephan von Krawczynski
2003-08-06 7:41 ` 2.4.22-pre lockups (now decoded oops for pre10) Stephan von Krawczynski
2003-08-06 8:58 ` Oleg Drokin
2003-08-06 9:09 ` Willy Tarreau
2003-08-06 9:36 ` Stephan von Krawczynski
2003-08-06 12:45 ` Willy Tarreau
2003-08-18 14:23 ` Andrea Arcangeli
2003-08-06 18:15 ` Marcelo Tosatti
2003-08-07 2:14 ` Stephan von Krawczynski
2003-08-07 5:35 ` Oleg Drokin
2003-08-07 12:45 ` Marcelo Tosatti
[not found] ` <3F325198.2010301@namesys.com>
2003-08-07 13:32 ` Stephan von Krawczynski
2003-08-18 20:29 ` Mike Fedyk
2003-08-18 20:39 ` Stephan von Krawczynski
2003-08-18 21:05 ` [grammar] " Matt Gibson
2003-08-18 21:09 ` Mike Fedyk
2003-08-07 15:52 ` Stephan von Krawczynski [this message]
[not found] <20030808002918.723abb08.skraw@ithnet.com>
2003-08-08 14:54 ` Marcelo Tosatti
2003-08-08 15:05 ` Stephan von Krawczynski
2003-08-08 15:33 ` Marcelo Tosatti
2003-08-10 21:35 ` Stephan von Krawczynski
2003-08-10 23:23 ` Neil Brown
2003-08-11 9:33 ` Stephan von Krawczynski
2003-08-18 20:43 ` Mike Fedyk
2003-08-13 10:55 ` Stephan von Krawczynski
2003-08-13 14:53 ` Marcelo Tosatti
2003-08-13 14:59 ` Oleg Drokin
2003-08-13 15:12 ` Stephan von Krawczynski
2003-08-13 15:30 ` Oleg Drokin
2003-08-13 16:04 ` Stephan von Krawczynski
2003-08-13 16:34 ` Oleg Drokin
2003-08-13 22:19 ` Stephan von Krawczynski
2003-08-14 8:45 ` Oleg Drokin
2003-08-14 17:26 ` Marcelo Tosatti
2003-08-14 17:42 ` Stephan von Krawczynski
2003-08-15 2:08 ` Chris Mason
2003-08-15 9:40 ` Stephan von Krawczynski
2003-08-15 10:28 ` Stephan von Krawczynski
2003-08-15 12:55 ` Chris Mason
2003-08-15 10:13 ` Stephan von Krawczynski
2003-08-15 10:31 ` Oleg Drokin
2003-08-18 15:06 ` Andrea Arcangeli
2003-08-18 20:19 ` Stephan von Krawczynski
2003-08-18 20:58 ` Mike Fedyk
2003-08-18 22:31 ` Andrea Arcangeli
2003-08-19 1:12 ` Mike Fedyk
2003-08-19 7:12 ` Stephan von Krawczynski
2003-08-19 13:10 ` Alan Cox
2003-08-19 14:18 ` Stephan von Krawczynski
2003-08-19 18:00 ` Mike Fedyk
2003-08-19 21:58 ` Stephan von Krawczynski
2003-08-19 13:27 ` Andrea Arcangeli
2003-08-13 15:21 ` Jim Gifford
2003-08-13 17:08 ` Marcelo Tosatti
2003-08-10 14:23 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030807175213.63a56f9b.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=andrea@suse.de \
--cc=green@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.