mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Magnus Määttä" <novell@kiruna.se>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.18-rc6-mm1
Date: Sat, 9 Sep 2006 14:45:32 +0200	[thread overview]
Message-ID: <200609091445.32744.novell@kiruna.se> (raw)

Hi Andrew,

Sorry, forgot to CC lkml when I sent the first one.

Andrew Morton wrote:
> 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> - autofs4 mounting of NFS is still sick.

I got this oops on my machine when I ran df on another one which have 
mounted a few NFS shares from my machine. I got 5 more pretty much 
identical ones within 10 seconds after the first one (haven't seen 
any more after these though). Also, dmesg is filled with, about a 
gazillion of these:
[15164.017991] RPC request reserved 9136 but used 9268
[15164.037431] RPC request reserved 9136 but used 9268
[15164.052988] RPC request reserved 9136 but used 9268

Files are also getting corrupted when transfered from my machine, but 
using my machine as client works fine.

oops here:

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
BUG: unable to handle kernel NULL pointer dereference at virtual 
address 00000000
c04ad300
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c04ad300>]    Tainted: P      VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
esi: e5299070   edi: ffff84de   ebp: e52a0fb0   esp: e52a0f70
ds: 007b   es: 007b   ss: 0068
Stack: 00200046 eb499aa0 00000001 eb499a84 00000000 e52a0f9c c04eaa1b 
eb499a84
       00000001 e8843620 e529904c e52a0fb0 c012d70b 00000002 ffff84de 
ffff84de
       e52a0fe0 c02784ba e5299000 e52a0fc4 00000000 fffffeff ffffffff 
fffffef8
Call Trace:
 [<c01041bf>] show_trace_log_lvl+0x2f/0x50
 [<c01042a7>] show_stack_log_lvl+0x97/0xc0
 [<c0104532>] show_registers+0x1f2/0x2a0
 [<c01047dd>] die+0x12d/0x240
 [<c011735c>] do_page_fault+0x3ac/0x650
 [<c04eaeef>] error_code+0x3f/0x44
 [<c02784ba>] nfsd+0x18a/0x2b0
 [<c0103fb7>] kernel_thread_helper+0x7/0x10
Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 
04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 
<8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43


>>EIP; c04ad300 <svc_process+40/6a0>   <=====

Trace; c01041bf <show_trace_log_lvl+2f/50>
Trace; c01042a7 <show_stack_log_lvl+97/c0>
Trace; c0104532 <show_registers+1f2/2a0>
Trace; c01047dd <die+12d/240>
Trace; c011735c <do_page_fault+3ac/650>
Trace; c04eaeef <error_code+3f/44>
Trace; c02784ba <nfsd+18a/2b0>
Trace; c0103fb7 <kernel_thread_helper+7/10>

This architecture has variable length instructions, decoding before 
eip
is unreliable, take these instructions with a pinch of salt.

Code;  c04ad2d5 <svc_process+15/6a0>
00000000 <_EIP>:
Code;  c04ad2d5 <svc_process+15/6a0>
   0:   89 45 e8                  mov    %eax,0xffffffe8(%ebp)
Code;  c04ad2d8 <svc_process+18/6a0>
   3:   8b 52 28                  mov    0x28(%edx),%edx
Code;  c04ad2db <svc_process+1b/6a0>
   6:   83 c6 70                  add    $0x70,%esi
Code;  c04ad2de <svc_process+1e/6a0>
   9:   89 55 e4                  mov    %edx,0xffffffe4(%ebp)
Code;  c04ad2e1 <svc_process+21/6a0>
   c:   8b 40 04                  mov    0x4(%eax),%eax
Code;  c04ad2e4 <svc_process+24/6a0>
   f:   83 f8 17                  cmp    $0x17,%eax
Code;  c04ad2e7 <svc_process+27/6a0>
  12:   0f 86 6d 04 00 00         jbe    485 <_EIP+0x485>
Code;  c04ad2ed <svc_process+2d/6a0>
  18:   8b 5d 08                  mov    0x8(%ebp),%ebx
Code;  c04ad2f0 <svc_process+30/6a0>
  1b:   8b 83 9c 04 00 00         mov    0x49c(%ebx),%eax
Code;  c04ad2f6 <svc_process+36/6a0>
  21:   c7 83 a0 04 00 00 01      movl   $0x1,0x4a0(%ebx)
Code;  c04ad2fd <svc_process+3d/6a0>
  28:   00 00 00 

This decode from eip onwards should be reliable

Code;  c04ad300 <svc_process+40/6a0>
00000000 <_EIP>:
Code;  c04ad300 <svc_process+40/6a0>   <=====
   0:   8b 00                     mov    (%eax),%eax   <=====
Code;  c04ad302 <svc_process+42/6a0>
   2:   89 04 24                  mov    %eax,(%esp)
Code;  c04ad305 <svc_process+45/6a0>
   5:   e8 06 d4 ca ff            call   ffcad410 <_EIP+0xffcad410>
Code;  c04ad30a <svc_process+4a/6a0>
   a:   c7 46 04 00 00 00 00      movl   $0x0,0x4(%esi)
Code;  c04ad311 <svc_process+51/6a0>
  11:   89 c1                     mov    %eax,%ecx
Code;  c04ad313 <svc_process+53/6a0>
  13:   89                        .byte 0x89
Code;  c04ad314 <svc_process+54/6a0>
  14:   43                        inc    %ebx

EIP: [<c04ad300>] svc_process+0x40/0x6a0 SS:ESP 0068:e52a0f70
Warning (Oops_read): Code line not seen, dumping what data is 
available


>>EIP; c04ad300 <svc_process+40/6a0>   <=====


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

             reply	other threads:[~2006-09-09 12:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-09 12:45 Magnus Määttä [this message]
2006-09-09 18:27 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-10  0:37   ` 2.6.18-rc6-mm1 Magnus Määttä
2006-09-10  5:35     ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-10 10:22       ` 2.6.18-rc6-mm1 Magnus Määttä
2006-09-13  4:54   ` 2.6.18-rc6-mm1 Neil Brown
2006-09-16 14:10     ` 2.6.18-rc6-mm1 Magnus Määttä
  -- strict thread matches above, loose matches on Subject: below --
2006-09-11 21:56 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11 22:35 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-11 12:41 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11 17:23 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-11  2:34 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11  5:14 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 11:49 ` 2.6.18-rc6-mm1 Andy Whitcroft
2006-09-08 12:07 ` 2.6.18-rc6-mm1 Frederik Deweerdt
2006-09-08 14:26 ` 2.6.18-rc6-mm1 Rafael J. Wysocki
2006-09-08 17:43 ` 2.6.18-rc6-mm1 Stefan Richter
2006-09-08 18:04   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 18:36     ` 2.6.18-rc6-mm1 Stefan Richter
2006-09-08 19:23 ` 2.6.18-rc6-mm1 Michal Piotrowski
2006-09-08 19:43   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 20:01     ` 2.6.18-rc6-mm1 Michal Piotrowski
2006-09-08 19:30 ` 2.6.18-rc6-mm1 thunder7
2006-09-08 19:44   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-09  9:04     ` 2.6.18-rc6-mm1 thunder7
2006-09-09 15:31       ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-09 22:02         ` 2.6.18-rc6-mm1 Jean Delvare
2006-09-10  6:30           ` 2.6.18-rc6-mm1 thunder7
2006-09-11 21:19 ` 2.6.18-rc6-mm1 Mark Haverkamp
2006-09-11 22:16   ` 2.6.18-rc6-mm1 Andrew Morton

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=200609091445.32744.novell@kiruna.se \
    --to=novell@kiruna.se \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®