>> slab.c : line 1072-1073 is
>> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>> 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)
...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.