lkml.org 
[lkml]   [2010]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: -next March 3: Boot failure on x86 (Oops)
Hello,

On 03/04/2010 02:23 PM, Sachin Sant wrote:
>> Can you please feed the address to gdb and get the line number? Also,
>> is it reproducible on mainline?
>>
> I can recreate this with latest git as well (2.6.33-git9 [eaa5eec7..])
>
> Disassembly from 2.6.33-git9 code base follows :
>
> /usr/local/autobench/var/tmp/build/linux/mm/percpu.c:1137
> if (off >= 0)
> e91: 0f 89 fd 00 00 00 jns f94 <pcpu_alloc+0x2bd>
> /usr/local/autobench/var/tmp/build/linux/mm/percpu.c:1116
> }
>
> restart:
> /* search through normal chunks */
> for (slot = pcpu_size_to_slot(size); slot < pcpu_nr_slots; slot++) {
> list_for_each_entry(chunk, &pcpu_slot[slot], list) {
> e97: 8b 45 84 mov -0x7c(%ebp),%eax
> e9a: 8b 00 mov (%eax),%eax
> e9c: 89 45 84 mov %eax,-0x7c(%ebp)
> prefetch():
> /usr/local/autobench/var/tmp/build/linux/arch/x86/include/asm/processor.h:886
>
> e9f: 8b 55 84 mov -0x7c(%ebp),%edx
> ea2: 8b 02 mov (%edx),%eax
>
> ^^^^^^^^^^^^^^^^^^^ EIP corresponds to this line

Hmmm... this means that on one of the chunks, chunk->list.next was
NULL (BTW, the disassembly is from unlinked object, right?). The main
allocation code hasn't seen much change lately. The only changes are,

22b737f4c75197372d64afc6ed1bccd58c00e549 : just refactoring
833af8427be4b217b5bc522f61afdbd3f1d282c2 : possible but isn't very new

Another possibility could be that the data structure before it was
overrun and corrupted the list part. pcpu_chunk is allocated with
variable size array attached at the end, so maybe I screwed up
calculation somewhere? This could explain the difference between 64
and 32bits. If you add padding at the head of struct pcpu_chunk, say,
unsigned long pad[16], does the problem go away?

Thanks.

--
tejun


\
 
 \ /
  Last update: 2010-03-05 07:11    [W:0.065 / U:23.184 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site