2.2.16 general protection fault

• Next message: Arjan van de Ven: "Re: [Announce] BKL shifting into drivers and filesystems - beware"
• Previous message: Henning P. Schmiedehausen: "Re: Object Oriented Linux"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi.

Kernel 2.2.16, on a K6-2 400 refuses to boot, or rather, it dies
almost immediately with a gpf:

======================================================================
LILO Loading Linux
Linux version 2.2.16 (bb@zen) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #1 Sun Jul 16 17:59:57 CEST 2000
Detected 400920 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 799.54 BogoMIPS
Memory: 257996k/262144k available (860k kernel code, 416k reserved, 2792k data, 80k init)
general protection fault: 0000
CPU: 0
EIP: 0010:[<c011e853>]
EFLAGS: 00010286
eax: 0000009f ebx: cffff0d8 ecx: ffffffff edx: c04a1000
esi: 00000028 edi: ffffffff ebp: cfffffe0 esp: c01edf30
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c01ed000)
Stack: c01dbdc0 00000286 ffffffff 00000212 00000001 00000015 00000020 00000000
       c011ea43 c01dbdc0 00000015 00000000 0009e200 00000000 00000020 c011e0bc
       c01dbdc0 00000015 00000000 0009e200 00000000 00000e00 00000286 c0204d5d
Call Trace: [<c011ea43>] [<c011e0bc>] [<c01b14a0>] [<c01b2ede>] [<c0106000>] [<c0106000>] [<c0100176>]
Code: 89 07 8b 4c 24 10 8b 09 89 4c 24 10 83 ee 01 73 b8 c7 01 00
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing
======================================================================

The compiler is just one of many; gcc 2.7.2.3 leads to the same
result, as does egcs 1.1.2. This specific compile was one a second
machine, to see whether it's hardware screwing up the compile.

Finding the EIP an Call Trace values in System.map gives me:

[<c011e853>] c011e5b0 t kmem_cache_grow
             (c011e924 t kmem_report_alloc_err)

[<c011ea43>] c011e974 T kmem_cache_alloc
             (c011ea98 T kmem_cache_free)

[<c011e0bc>] c011df90 T kmem_cache_create
             (c011e4bc T kmem_cache_shrink)

[<c01b14a0>] c01aed00 T stext_lock
             (c01b1760 r tvecs)

[<c01b2ede>] c01b1760 r tvecs
             (c01b4bc0 r cprt

[<c0106000>] c0106000 T get_options

[<c0100176>] c0100176 t L6

Sprinkling a couple of printk's into kmem_cache_grow in mm/slab.c lets
me find out that, when control hits line 1121:

    if (!slabp->s_index) {
       *bufpp = objp;
       objp += sizeof(kmem_bufctl_t);
    } else
       *bufpp = &slabp->s_index[num];

slabp->s_index is 0xFFFFFFFF.

Is this a compiler problem, an assembler problem, a kernel problem, or
a hardware problem? How do I find out?

TIA,

Gabe

-- 
It's hard to be serious when you're naked.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

• Next message: Arjan van de Ven: "Re: [Announce] BKL shifting into drivers and filesystems - beware"
• Previous message: Henning P. Schmiedehausen: "Re: Object Oriented Linux"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:08 EST