Hell all:
Problem: first run "find /" , eject and insert pcmcia network's card, the kernel will crash.
Kernel oops: at
linux/mm/slab.c->kmem_cache_grow.
if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
BUG(); <-- here.
Can I remove this check ?
-----------
Gnu C 2.95.4
Gnu make 3.79.1
util-linux 2.11n
mount 2.11n
modutils 2.4.15
e2fsprogs 1.27
pcmcia-cs 3.1.31
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded serial_cs serial isa-pnp pcnet_cs 8390 af_packet parport_pc lp parport usb-uhci usbcore ide-cd cdrom floppy agpgart ospm_thermal ospm_battery ospm_ec ospm_button ospm_ac_adapter ospm_processor ospm_system ospm_busmgr via82cxxx_audio ac97_codec uart401 sound soundcore rtc unix
--
thanks with regards!
hugang.
***********************************
Beijing Soul Technology Co.,Ltd.
Tel:010-68425741/42/43/44
Fax:010-68425745
email:[email protected]
web:http://www.soul.com.cn
***********************************
hugang wrote:
>
> Hell all:
>
> Problem: first run "find /" , eject and insert pcmcia network's card, the kernel will crash.
>
> Kernel oops: at
> linux/mm/slab.c->kmem_cache_grow.
> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
> BUG(); <-- here.
Known problem, I'm afraid. The PCMCIA Card Services layer
in a number of places is doing stuff from inside a timer
handler which it should not be.
> Can I remove this check ?
It's best not to, really. It'll probably appear to have
worked but your kernel could still fail in mysterious ways,
much later, very occasionally.
If you're using devfs, you could try disabling that. Not
that this is a devfs bug, but disabling devfs reduces
the number of functions which the buggy drivers call at
timer-interrupt time.
The bottom line is that we have a pcmcia_cs staffing shortage.
Somebody needs to go in, pull out the timers, use schedule_task().
-
Thank your. Your are right, I use devfs.
When I disable the devfs, I insert and eject pcmcia card , The linux is fine .
On Mon, 15 Apr 2002 00:38:05 -0700
Andrew Morton <[email protected]> wrote:
> hugang wrote:
> >
> > Hell all:
> >
> > Problem: first run "find /" , eject and insert pcmcia network's card, the kernel will crash.
> >
> > Kernel oops: at
> > linux/mm/slab.c->kmem_cache_grow.
> > if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
> > BUG(); <-- here.
>
> Known problem, I'm afraid. The PCMCIA Card Services layer
> in a number of places is doing stuff from inside a timer
> handler which it should not be.
>
> > Can I remove this check ?
>
> It's best not to, really. It'll probably appear to have
> worked but your kernel could still fail in mysterious ways,
> much later, very occasionally.
>
> If you're using devfs, you could try disabling that. Not
> that this is a devfs bug, but disabling devfs reduces
> the number of functions which the buggy drivers call at
> timer-interrupt time.
>
> The bottom line is that we have a pcmcia_cs staffing shortage.
> Somebody needs to go in, pull out the timers, use schedule_task().
>
> -
>
--
thanks with regards!
hugang.
***********************************
Beijing Soul Technology Co.,Ltd.
Tel:010-68425741/42/43/44
Fax:010-68425745
email:[email protected]
web:http://www.soul.com.cn
***********************************
> Problem: first run "find /" , eject and insert pcmcia network's card, the kernel will crash.
Which network card and what kernel revision
> Kernel oops: at
> linux/mm/slab.c->kmem_cache_grow.
> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
> BUG(); <-- here.
>
> Can I remove this check ?
The kernel realised it was being made to sleep in an interrupt. If you
remove the check it will crash anyway. If you did something like
if(..... as before ...)
{
flags&=~SLAB_LEVEL_MASK;
flags|=SLAB_ATOMIC;
printk(KERN_ERR "kmem: critical memory allocation level error.\n");
}
it ought to print a complaint and continue. Really however it wants fixing