All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alessandro Suardi <alessandro.suardi@gmail.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: oops in free_block in 2.6.12-git5
Date: Wed, 6 Jul 2005 06:50:55 +0200	[thread overview]
Message-ID: <5a4c581d0507052150446a32fa@mail.gmail.com> (raw)

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

Hi all,

  my bittorrent box running 2.6.12-git5 (AMD K7-800,
  256MB RAM, fairly recently updated FC3) decided to
  oops  a few hours ago. On the console I had a very long
  trace before the actual lockup, but I didn't write it down
  (it had ide_dma_<xx>_request  and bh_<xx> calls as
  main part of the trace, though it took up all of my screen
  and more so I can't tell where the EIP was).

At reboot however I have an oops with EIP in free_block
 very likely happened after/during an updatedb run which
 very closely resembles this report that hit isofs in 2.6.9-rc2:

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1790.html

The only thing running on the box at that time was a
 download of a 8GB torrent with bittorrent from the
 FC3 bittorrent-4.1.1-2.1.fc3.rf package.

Attached the oops trace and the decoded oops
 after I edited the trace to remove the timed printks
 and ran it through ksymoops 2.4.11.

kernel isn't running CONFIG_DEBUG_SLAB but
 if you think this is a legitimate slab bug I'll later
 update to the current -git kernel and enable the
 slab debugging.

Thanks,

--alessandro

 "When it comes to luck / you make your own
  Tonight I've got dirt on my hands
  But I'm building me a new home"

    (Bruce Springsteen - "Lucky Town")

[-- Attachment #2: oops-02.txt.decoded --]
[-- Type: application/octet-stream, Size: 5536 bytes --]

ksymoops 2.4.11 on i686 2.6.12-git5.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.12-git5/ (default)
     -m /usr/src/linux/System.map (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
Jul  6 04:02:11 donkey kernel: Unable to handle kernel paging request at virtual address 2071fce4
Jul  6 04:02:11 donkey kernel: c013c8ef
Jul  6 04:02:11 donkey kernel: *pde = 00000000
Jul  6 04:02:11 donkey kernel: Oops: 0000 [#1]
Jul  6 04:02:11 donkey kernel: CPU:    0
Jul  6 04:02:11 donkey kernel: EIP:    0060:[<c013c8ef>]    Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
Jul  6 04:02:11 donkey kernel: EFLAGS: 00010016   (2.6.12-git5)
Jul  6 04:02:11 donkey kernel: eax: 00800000   ebx: 2071fce0   ecx: 00000000   edx: c1000000
Jul  6 04:02:11 donkey kernel: esi: cffef1e0   edi: 0000004f   ebp: cffa3ef0   esp: cffa3ed4
Jul  6 04:02:11 donkey kernel: ds: 007b   es: 007b   ss: 0068
Jul  6 04:02:11 donkey kernel: Stack: cffef1ec cffef1fc 2972c214 cffea210 cffea210 cffea200 2972c214 cffa3f08
Jul  6 04:02:11 donkey kernel:        c013cfbf cffef1e0 cffef6fc cffef1e0 00000003 cffa3f34 c013d074 cffa2000
Jul  6 04:02:11 donkey kernel:        cffef6fc cffa2000 cffa2000 cffef250 cffa3f34 c046ca80 00000297 c046ca84
Jul  6 04:02:11 donkey kernel: Call Trace:
Jul  6 04:02:11 donkey kernel:  [<c010316a>] show_stack+0x7a/0x90
Jul  6 04:02:11 donkey kernel:  [<c01032f6>] show_registers+0x156/0x1d0
Jul  6 04:02:11 donkey kernel:  [<c01034f4>] die+0xe4/0x170
Jul  6 04:02:11 donkey kernel:  [<c0110bd3>] do_page_fault+0x453/0x671
Jul  6 04:02:11 donkey kernel:  [<c0102d9f>] error_code+0x4f/0x54
Jul  6 04:02:11 donkey kernel:  [<c013cfbf>] drain_array_locked+0x5f/0xa0
Jul  6 04:02:11 donkey kernel:  [<c013d074>] cache_reap+0x74/0x1d0
Jul  6 04:02:11 donkey kernel:  [<c0125e54>] worker_thread+0x1c4/0x280
Jul  6 04:02:11 donkey kernel:  [<c0129ffb>] kthread+0x8b/0xc0
Jul  6 04:02:11 donkey kernel:  [<c0100d45>] kernel_thread_helper+0x5/0x10
Jul  6 04:02:11 donkey kernel: Code: 8b 55 e8 89 5e 1c 89 53 04 47 3b 7d ec 7d 6d 8b 45 f0 8b 15 90 cb 46 c0 8b 0c b8 8d 81 00 00 00 40 c1 e8 0c c1 e0 05 8b 5c 10 1c <8b> 53 04 8b 03 89 50 04 89 02 31 d2 2b 4b 0c c7 03 00 01 10 00


>>EIP; c013c8ef <free_block+6f/e0>   <=====

>>edx; c1000000 <pg0+b6d000/3fb6b400>
>>esi; cffef1e0 <pg0+fb5c1e0/3fb6b400>
>>ebp; cffa3ef0 <pg0+fb10ef0/3fb6b400>
>>esp; cffa3ed4 <pg0+fb10ed4/3fb6b400>

Trace; c010316a <show_stack+7a/90>
Trace; c01032f6 <show_registers+156/1d0>
Trace; c01034f4 <die+e4/170>
Trace; c0110bd3 <do_page_fault+453/671>
Trace; c0102d9f <error_code+4f/54>
Trace; c013cfbf <drain_array_locked+5f/a0>
Trace; c013d074 <cache_reap+74/1d0>
Trace; c0125e54 <worker_thread+1c4/280>
Trace; c0129ffb <kthread+8b/c0>
Trace; c0100d45 <kernel_thread_helper+5/10>

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

Code;  c013c8c4 <free_block+44/e0>
00000000 <_EIP>:
Code;  c013c8c4 <free_block+44/e0>
   0:   8b 55 e8                  mov    0xffffffe8(%ebp),%edx
Code;  c013c8c7 <free_block+47/e0>
   3:   89 5e 1c                  mov    %ebx,0x1c(%esi)
Code;  c013c8ca <free_block+4a/e0>
   6:   89 53 04                  mov    %edx,0x4(%ebx)
Code;  c013c8cd <free_block+4d/e0>
   9:   47                        inc    %edi
Code;  c013c8ce <free_block+4e/e0>
   a:   3b 7d ec                  cmp    0xffffffec(%ebp),%edi
Code;  c013c8d1 <free_block+51/e0>
   d:   7d 6d                     jge    7c <_EIP+0x7c>
Code;  c013c8d3 <free_block+53/e0>
   f:   8b 45 f0                  mov    0xfffffff0(%ebp),%eax
Code;  c013c8d6 <free_block+56/e0>
  12:   8b 15 90 cb 46 c0         mov    0xc046cb90,%edx
Code;  c013c8dc <free_block+5c/e0>
  18:   8b 0c b8                  mov    (%eax,%edi,4),%ecx
Code;  c013c8df <free_block+5f/e0>
  1b:   8d 81 00 00 00 40         lea    0x40000000(%ecx),%eax
Code;  c013c8e5 <free_block+65/e0>
  21:   c1 e8 0c                  shr    $0xc,%eax
Code;  c013c8e8 <free_block+68/e0>
  24:   c1 e0 05                  shl    $0x5,%eax
Code;  c013c8eb <free_block+6b/e0>
  27:   8b 5c 10 1c               mov    0x1c(%eax,%edx,1),%ebx

This decode from eip onwards should be reliable

Code;  c013c8ef <free_block+6f/e0>
00000000 <_EIP>:
Code;  c013c8ef <free_block+6f/e0>   <=====
   0:   8b 53 04                  mov    0x4(%ebx),%edx   <=====
Code;  c013c8f2 <free_block+72/e0>
   3:   8b 03                     mov    (%ebx),%eax
Code;  c013c8f4 <free_block+74/e0>
   5:   89 50 04                  mov    %edx,0x4(%eax)
Code;  c013c8f7 <free_block+77/e0>
   8:   89 02                     mov    %eax,(%edx)
Code;  c013c8f9 <free_block+79/e0>
   a:   31 d2                     xor    %edx,%edx
Code;  c013c8fb <free_block+7b/e0>
   c:   2b 4b 0c                  sub    0xc(%ebx),%ecx
Code;  c013c8fe <free_block+7e/e0>
   f:   c7 03 00 01 10 00         movl   $0x100100,(%ebx)


1 warning and 1 error issued.  Results may not be reliable.

[-- Attachment #3: oops-02.txt --]
[-- Type: text/plain, Size: 2864 bytes --]

Jul  6 04:02:11 donkey kernel: [198064.853894] Unable to handle kernel paging request at virtual address 2071fce4
Jul  6 04:02:11 donkey kernel: [198064.854464]  printing eip:
Jul  6 04:02:11 donkey kernel: [198064.854665] c013c8ef
Jul  6 04:02:11 donkey kernel: [198064.854828] *pde = 00000000
Jul  6 04:02:11 donkey kernel: [198064.855035] Oops: 0000 [#1]
Jul  6 04:02:11 donkey kernel: [198064.855242] PREEMPT
Jul  6 04:02:11 donkey kernel: [198064.855416] Modules linked in: nls_iso8859_1 parport_pc parport 8139too floppy
Jul  6 04:02:11 donkey kernel: [198064.856021] CPU:    0
Jul  6 04:02:11 donkey kernel: [198064.856023] EIP:    0060:[<c013c8ef>]    Not tainted VLI
Jul  6 04:02:11 donkey kernel: [198064.856027] EFLAGS: 00010016   (2.6.12-git5)
Jul  6 04:02:11 donkey kernel: [198064.856901] EIP is at free_block+0x6f/0xe0
Jul  6 04:02:11 donkey kernel: [198064.857202] eax: 00800000   ebx: 2071fce0   ecx: 00000000   edx: c1000000
Jul  6 04:02:11 donkey kernel: [198064.857691] esi: cffef1e0   edi: 0000004f   ebp: cffa3ef0   esp: cffa3ed4
Jul  6 04:02:11 donkey kernel: [198064.858177] ds: 007b   es: 007b   ss: 0068
Jul  6 04:02:11 donkey kernel: [198064.858476] Process events/0 (pid: 3, threadinfo=cffa2000 task=c127a020)
Jul  6 04:02:11 donkey kernel: [198064.858956] Stack: cffef1ec cffef1fc 2972c214 cffea210 cffea210 cffea200 2972c214 cffa3f08
Jul  6 04:02:11 donkey kernel: [198064.859678]        c013cfbf cffef1e0 cffef6fc cffef1e0 00000003 cffa3f34 c013d074 cffa2000
Jul  6 04:02:11 donkey kernel: [198064.860398]        cffef6fc cffa2000 cffa2000 cffef250 cffa3f34 c046ca80 00000297 c046ca84
Jul  6 04:02:11 donkey kernel: [198064.861118] Call Trace:
Jul  6 04:02:11 donkey kernel: [198064.861494]  [<c010316a>] show_stack+0x7a/0x90
Jul  6 04:02:11 donkey kernel: [198064.862016]  [<c01032f6>] show_registers+0x156/0x1d0
Jul  6 04:02:11 donkey kernel: [198064.862570]  [<c01034f4>] die+0xe4/0x170
Jul  6 04:02:11 donkey kernel: [198064.863049]  [<c0110bd3>] do_page_fault+0x453/0x671
Jul  6 04:02:11 donkey kernel: [198064.863604]  [<c0102d9f>] error_code+0x4f/0x54
Jul  6 04:02:11 donkey kernel: [198064.864120]  [<c013cfbf>] drain_array_locked+0x5f/0xa0
Jul  6 04:02:11 donkey kernel: [198064.864686]  [<c013d074>] cache_reap+0x74/0x1d0
Jul  6 04:02:11 donkey kernel: [198064.865209]  [<c0125e54>] worker_thread+0x1c4/0x280
Jul  6 04:02:11 donkey kernel: [198064.865762]  [<c0129ffb>] kthread+0x8b/0xc0
Jul  6 04:02:11 donkey kernel: [198064.866266]  [<c0100d45>] kernel_thread_helper+0x5/0x10
Jul  6 04:02:11 donkey kernel: [198064.866835] Code: 8b 55 e8 89 5e 1c 89 53 04 47 3b 7d ec 7d 6d 8b 45 f0 8b 15 90 cb 46 c0 8b 0c b8 8d 81 00 00 00 40 c1 e8 0c c1 e0 05 8b 5c 10 1c <8b> 53 04 8b 03 89 50 04 89 02 31 d2 2b 4b 0c c7 03 00 01 10 00
Jul  6 04:02:11 donkey kernel: [198064.955135]  <6>note: events/0[3] exited with preempt_count 1

                 reply	other threads:[~2005-07-06  6:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=5a4c581d0507052150446a32fa@mail.gmail.com \
    --to=alessandro.suardi@gmail.com \
    --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 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.