Oops in 2.6.25

Oops in 2.6.25

[Wolf Wiegand]

[-- Attachment #1: Type: text/plain, Size: 5732 bytes --]

Hi,

(please CC me in replies)

my current kernel just threw an error, see output from ksymoops below.
I've been using this version for quite some time now, this is the first
time this has happened. There have been no hardware changes lately. The
hardware itself is nothing special, it's a somewhat dusty Thinkpad. 

I hope I have included all relevant information, please contact me if
more information is needed.

Cheers,

Wolf


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

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Pid: 7266, comm: convert Not tainted (2.6.25 #2)
EIP: 0060:[<c013bc09>] EFLAGS: 00210006 CPU: 0
Using defaults from ksymoops -t elf32-i386 -a i386
EAX: 00001000 EBX: 00001000 ECX: 00000000 EDX: 00000000
ESI: d2ce7bf8 EDI: d2ce7bfc EBP: 00002b4f ESP: d8c4beb0
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Stack: 02d60000 ffffffe5 d2ce7b04 00000000 c015161c d8c4bf34 00002b4f d2ce7b60
       01000003 d2ce7bf8 001200d2 00000000 02d60000 00000000 d8c4bf28 00002b4f
       c0151ef3 00000001 d8c4bf00 d2ce7b60 00000000 c0538bd0 b75ff004 d2cc03b0
Call Trace:
 [<c015161c>] shmem_getpage+0x58/0x852
 [<c0151ef3>] shmem_fault+0x79/0xa1
 [<c0145df3>] __do_fault+0x50/0x31b
 [<c0147a75>] handle_mm_fault+0x246/0x535
 [<c01125d5>] do_page_fault+0x205/0x520
 [<c01123d0>] do_page_fault+0x0/0x520
 [<c0427072>] error_code+0x6a/0x70
 [<c0420000>] e100_probe+0x495/0x5b6
Code: 5b 5b 5e 5f 5d c3 55 89 d5 57 56 89 c6 53 8d 78 04 fa b8 01 00 00 00 e8 6e 8b fd ff 89 ea 89 f8 e8 1d 35 10 00 85 c0 89 c3 74 59 <8b> 00 89 da 25 00 40 02 00 3d 00 40 02 00 75 03 8b 53 0c ff 42


>>EIP; c013bc09 <find_lock_page+25/a2>   <=====

Trace; c015161c <shmem_getpage+58/852>
Trace; c0151ef3 <shmem_fault+79/a1>
Trace; c0145df3 <__do_fault+50/31b>
Trace; c0147a75 <handle_mm_fault+246/535>
Trace; c01125d5 <do_page_fault+205/520>
Trace; c01123d0 <do_page_fault+0/520>
Trace; c0427072 <error_code+6a/70>
Trace; c0420000 <e100_probe+495/5b6>

ode;  c013bbde <pagecache_write_end+c3/c9>
00000000 <_EIP>:
Code;  c013bbde <pagecache_write_end+c3/c9>
   0:   5b                        pop    %ebx
Code;  c013bbdf <pagecache_write_end+c4/c9>
   1:   5b                        pop    %ebx
Code;  c013bbe0 <pagecache_write_end+c5/c9>
   2:   5e                        pop    %esi
Code;  c013bbe1 <pagecache_write_end+c6/c9>
   3:   5f                        pop    %edi
Code;  c013bbe2 <pagecache_write_end+c7/c9>
   4:   5d                        pop    %ebp
Code;  c013bbe3 <pagecache_write_end+c8/c9>
   5:   c3                        ret
Code;  c013bbe4 <find_lock_page+0/a2>
   6:   55                        push   %ebp
Code;  c013bbe5 <find_lock_page+1/a2>
   7:   89 d5                     mov    %edx,%ebp
Code;  c013bbe7 <find_lock_page+3/a2>
   9:   57                        push   %edi
Code;  c013bbe8 <find_lock_page+4/a2>
   a:   56                        push   %esi
Code;  c013bbe9 <find_lock_page+5/a2>
   b:   89 c6                     mov    %eax,%esi
Code;  c013bbeb <find_lock_page+7/a2>
   d:   53                        push   %ebx
Code;  c013bbec <find_lock_page+8/a2>
   e:   8d 78 04                  lea    0x4(%eax),%edi
Code;  c013bbef <find_lock_page+b/a2>
  11:   fa                        cli
Code;  c013bbf0 <find_lock_page+c/a2>
  12:   b8 01 00 00 00            mov    $0x1,%eax
Code;  c013bbf5 <find_lock_page+11/a2>
  17:   e8 6e 8b fd ff            call   fffd8b8a <_EIP+0xfffd8b8a>
Code;  c013bbfa <find_lock_page+16/a2>
  1c:   89 ea                     mov    %ebp,%edx
Code;  c013bbfc <find_lock_page+18/a2>
  1e:   89 f8                     mov    %edi,%eax
Code;  c013bbfe <find_lock_page+1a/a2>
  20:   e8 1d 35 10 00            call   103542 <_EIP+0x103542>
Code;  c013bc03 <find_lock_page+1f/a2>
  25:   85 c0                     test   %eax,%eax
Code;  c013bc05 <find_lock_page+21/a2>
  27:   89 c3                     mov    %eax,%ebx
Code;  c013bc07 <find_lock_page+23/a2>
  29:   74 59                     je     84 <_EIP+0x84>
Code;  c013bc09 <find_lock_page+25/a2>   <=====
  2b:   8b 00                     mov    (%eax),%eax   <=====
Code;  c013bc0b <find_lock_page+27/a2>
  2d:   89 da                     mov    %ebx,%edx
Code;  c013bc0d <find_lock_page+29/a2>
  2f:   25 00 40 02 00            and    $0x24000,%eax
Code;  c013bc12 <find_lock_page+2e/a2>
  34:   3d 00 40 02 00            cmp    $0x24000,%eax
Code;  c013bc17 <find_lock_page+33/a2>
  39:   75 03                     jne    3e <_EIP+0x3e>
Code;  c013bc19 <find_lock_page+35/a2>
  3b:   8b 53 0c                  mov    0xc(%ebx),%edx
Code;  c013bc1c <find_lock_page+38/a2>
  3e:   ff                        .byte 0xff
Code;  c013bc1d <find_lock_page+39/a2>
  3f:   42                        inc    %edx

EIP: [<c013bc09>] find_lock_page+0x25/0xa2 SS:ESP 0068:d8c4beb0
Warning (Oops_read): Code line not seen, dumping what data is available


>>EIP; c013bc09 <find_lock_page+25/a2>   <=====


2 warnings and 1 error issued.  Results may not be reliable.

-- 
Büroschimpfwort des Tages: Kontaktallergiker - meidet die Tratschrunden in der 
Kaffeeküche. (Sven-Lukas Müller)

[-- Attachment #2: config.gz --]
[-- Type: application/octet-stream, Size: 11738 bytes --]

Re: Oops in 2.6.25

[Hugh Dickins]

On Fri, 30 May 2008, Wolf Wiegand wrote:
> 
> my current kernel just threw an error, see output from ksymoops below.

(It's rather unusual to be using ksymoops on a 2.6 trace: I thought it
tended to mess up the trace more often than it helped, but perhaps I'm
wrong on that, the one below looks okay.  And I see you do build with
CONFIG_KALLSYMS=y, not trying to save space by omitting symbols, so
I'd expect you to have a good trace in your logs without ksymoops.)

> I've been using this version for quite some time now, this is the first
> time this has happened. There have been no hardware changes lately. The
> hardware itself is nothing special, it's a somewhat dusty Thinkpad. 

I'm afraid it looks like the dust has got into your RAM ;)

> Error (regular_file): read_ksyms stat /proc/ksyms failed
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod

Ah, yes, ksymoops isn't even looking in the right place (/proc/kallsyms)
for a 2.6 kernel: I think you can just forget about ksymoops next time.
If it's the Code decipherment you wanted, try scripts/decodecode from
the kernel tree - though I have seen that get confused.

> Pid: 7266, comm: convert Not tainted (2.6.25 #2)
> EIP: 0060:[<c013bc09>] EFLAGS: 00210006 CPU: 0
> Using defaults from ksymoops -t elf32-i386 -a i386
> EAX: 00001000 EBX: 00001000 ECX: 00000000 EDX: 00000000
> ESI: d2ce7bf8 EDI: d2ce7bfc EBP: 00002b4f ESP: d8c4beb0
>  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Stack: 02d60000 ffffffe5 d2ce7b04 00000000 c015161c d8c4bf34 00002b4f d2ce7b60
>        01000003 d2ce7bf8 001200d2 00000000 02d60000 00000000 d8c4bf28 00002b4f
>        c0151ef3 00000001 d8c4bf00 d2ce7b60 00000000 c0538bd0 b75ff004 d2cc03b0
> Call Trace:
>  [<c015161c>] shmem_getpage+0x58/0x852
>  [<c0151ef3>] shmem_fault+0x79/0xa1
>  [<c0145df3>] __do_fault+0x50/0x31b
>  [<c0147a75>] handle_mm_fault+0x246/0x535
>  [<c01125d5>] do_page_fault+0x205/0x520
>  [<c01123d0>] do_page_fault+0x0/0x520
>  [<c0427072>] error_code+0x6a/0x70
>  [<c0420000>] e100_probe+0x495/0x5b6
> Code: 5b 5b 5e 5f 5d c3 55 89 d5 57 56 89 c6 53 8d 78 04 fa b8 01 00 00 00 e8 6e 8b fd ff 89 ea 89 f8 e8 1d 35 10 00 85 c0 89 c3 74 59 <8b> 00 89 da 25 00 40 02 00 3d 00 40 02 00 75 03 8b 53 0c ff 42
> 
> >>EIP; c013bc09 <find_lock_page+25/a2>   <=====
> Trace; c015161c <shmem_getpage+58/852>
> Trace; c0151ef3 <shmem_fault+79/a1>
> Trace; c0145df3 <__do_fault+50/31b>
> Trace; c0147a75 <handle_mm_fault+246/535>
> Trace; c01125d5 <do_page_fault+205/520>
> Trace; c01123d0 <do_page_fault+0/520>
> Trace; c0427072 <error_code+6a/70>
> Trace; c0420000 <e100_probe+495/5b6>
> 
> Code;  c013bbfe <find_lock_page+1a/a2>
>   20:   e8 1d 35 10 00            call   103542 <_EIP+0x103542>

That's the call to radix_tree_lookup(), which should return
struct page *, or 0x00000000 when it doesn't find the page.

> Code;  c013bc03 <find_lock_page+1f/a2>
>   25:   85 c0                     test   %eax,%eax
> Code;  c013bc05 <find_lock_page+21/a2>
>   27:   89 c3                     mov    %eax,%ebx
> Code;  c013bc07 <find_lock_page+23/a2>
>   29:   74 59                     je     84 <_EIP+0x84>
> Code;  c013bc09 <find_lock_page+25/a2>   <=====
>   2b:   8b 00                     mov    (%eax),%eax   <=====

But in this case it's returned 0x00001000, see EAX or EBX above.
I don't think that's a kernel bug at all, just a single-bit
error in the RAM which held that radix tree node.

Hugh