linux-mips
[Top] [All Lists]

Re: kernel BUG at slab.c:1073!

To: ralf@oss.sgi.com
Subject: Re: kernel BUG at slab.c:1073!
From: Krishna Kondaka <krishna@Sanera.net>
Date: Wed, 24 Jul 2002 12:23:27 -0700 (PDT)
Cc: linux-mips@oss.sgi.com
Reply-to: Krishna Kondaka <krishna@Sanera.net>
Sender: owner-linux-mips@oss.sgi.com
>
>> slab.c : line 1072-1073 is        
>> 
>> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>>                 BUG();
>> 
>> The driver being loaded is a small proprietary driver. The init routine of
>> the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
>> that I can fix my driver to use GFP_ATOMIC if running in interrupt context.
>> 
>> My question is why is the "insmod" command running in interrupt context?
>
>Simple answer: it isn't, normally.  You should try to figure out who was
>calling kmalloc or the slab allocator; knowing the function will probably
>already solve the miracle.  All the addresses in the call trace that are
>in the range from 0xc0000000 and above are potencially modules addresses,
>so they're worth some closer examination.

well, my init code is some what like this -

int __init xxx_init(void)
{
        ...
        xxx_init_instance();
}

int xxx_init_instance()
{
        ...some code containing locks and unlocks()...
        xxx_inst = kmalloc(size, GFP_KERNEL);
}

So from this code, only xxx_init_instance should be calling kmalloc(). I will
check the caller and let you know.

>
>Aside, I urgently recommend an upgrade to a newer kernel.  2.4.9 is lacking
>more than half a year worth of bug fixes.  That can ruin your whole day ...

Unfortunately, it's not that easy. It will ruin more than a single day
for more than one person! We will very soon move to the version supplied by
monta vista based on 2.4.17.

Krishna

>
>  Ralf


<Prev in Thread] Current Thread [Next in Thread>