There is an in-interrupt, non-atomic allocation somewhere either in
cardbus/pci socket land, or the tulip driver. I think it occurs
something in the pci_enable_device callchain... This is definitely a
bug, but not one worthy of killing the kernel.
The attached patch, against 2.4.0-test4-pre6, simply prints a warning
and forces atomic allocation, instead of forcing an oops. Other drivers
and areas of the kernel might be affected by the BUG() call in
mm/slab.c, too.
Jeff
-- Jeff Garzik | Building 1024 | Yossarian lives. MandrakeSoft, Inc. |
Index: mm/slab.c =================================================================== RCS file: /g/cvslan/linux_2_3/mm/slab.c,v retrieving revision 1.1.1.19 retrieving revision 1.1.1.19.4.1 diff -u -r1.1.1.19 -r1.1.1.19.4.1 --- mm/slab.c 2000/07/13 01:48:49 1.1.1.19 +++ mm/slab.c 2000/07/14 01:06:56 1.1.1.19.4.1 @@ -1038,8 +1038,11 @@ * in kmem_cache_alloc(). If a caller is seriously mis-behaving they * will eventually be caught here (where it matters). */ - if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC) - BUG(); + if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC) { + printk (KERN_WARNING "BUG: in interrupt without SLAB_ATOMIC\n"); + flags |= SLAB_ATOMIC; + local_flags |= SLAB_ATOMIC; + } ctor_flags = SLAB_CTOR_CONSTRUCTOR; local_flags = (flags & SLAB_LEVEL_MASK);
- 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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:18 EST