Kamalesh Babulal wrote: > Pavel Emelyanov wrote: >> Kamalesh Babulal wrote: >> >> The creation of this cache consists of allocating ~30 >> bytes and creating a new kmem cache. This looks strange >> that one of these allocation falied... >> >> Could you please check what has happened with this patch: >> >> diff --git a/kernel/pid.c b/kernel/pid.c >> index d267775..9d594eb 100644 >> --- a/kernel/pid.c >> +++ b/kernel/pid.c >> @@ -458,15 +458,22 @@ static struct kmem_cache *create_pid_cac >> goto out; >> >> pcache = kmalloc(sizeof(struct pid_cache), GFP_KERNEL); >> - if (pcache == NULL) >> + if (pcache == NULL) { >> + printk("Can't alloc pcache size %d\n", >> + sizeof(struct pid_cache)); >> goto err_alloc; >> + } >> >> snprintf(pcache->name, sizeof(pcache->name), "pid_%d", nr_ids); >> cachep = kmem_cache_create(pcache->name, >> sizeof(struct pid) + (nr_ids - 1) * sizeof(struct upid), >> 0, SLAB_HWCACHE_ALIGN, NULL); >> - if (cachep == NULL) >> + if (cachep == NULL) { >> + printk("Can't create cachep size %d\n", >> + sizeof(struct pid) + >> + (nr_ids - 1) * sizeof(struct upid)); >> goto err_cachep; >> + } >> >> pcache->nr_ids = nr_ids; >> pcache->cachep = cachep; >> >> >> >>> Hi Andrew, >>> >>> Following Kernel panic is raised while booting up with >>> 2.6.23-rc3-mm1 kernel. >>> >>> ============================================================ >>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) >>> Initializing HighMem for node 0 (00038000:001fbe00) >>> Initializing HighMem for node 1 (00200000:003fbe00) >>> Initializing HighMem for node 2 (00400000:005fbe00) >>> Initializing HighMem for node 3 (00600000:007fbe00) >>> Memory: 32480436k/33554432k available (2146k kernel code, 278984k >>> reserved, 1203k data, 216k init, 31842304k highmem) >>> virtual kernel memory layout: >>> fixmap : 0xffe1a000 - 0xfffff000 (1940 kB) >>> pkmap : 0xffc00000 - 0xffe00000 (2048 kB) >>> vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB) >>> lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) >>> .init : 0xc134c000 - 0xc1382000 ( 216 kB) >>> .data : 0xc12189e1 - 0xc1345758 (1203 kB) >>> .text : 0xc1000000 - 0xc12189e1 (2146 kB) >>> Checking if this processor honours the WP bit even in supervisor >>> mode... Ok. >>> SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=16, CPUs=16, >>> Nodes=16 >>> Calibrating delay using timer specific routine.. 1401.55 BogoMIPS >>> (lpj=2803105) >>> Kernel panic - not syncing: Can't create pid_1 cachep >>> >>> >>> Thanks & Regards, >>> Kamalesh Babulal. > after applying the patch, kernel panic looks like this > =============================================================================== > > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Initializing HighMem for node 0 (00038000:001fbe00) > Initializing HighMem for node 1 (00200000:003fbe00) > Initializing HighMem for node 2 (00400000:005fbe00) > Initializing HighMem for node 3 (00600000:007fbe00) > Memory: 32479372k/33554432k available (2635k kernel code, 280048k > reserved, 1282k data, 216k init, 31842304k highmem) > virtual kernel memory layout: > fixmap : 0xffe1a000 - 0xfffff000 (1940 kB) > pkmap : 0xffc00000 - 0xffe00000 (2048 kB) > vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB) > lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) > .init : 0xc13da000 - 0xc1410000 ( 216 kB) > .data : 0xc1292f51 - 0xc13d3758 (1282 kB) > .text : 0xc1000000 - 0xc1292f51 (2635 kB) > Checking if this processor honours the WP bit even in supervisor > mode... Ok. > SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=16, CPUs=16, > Nodes=16 > Calibrating delay using timer specific routine.. 1401.55 BogoMIPS > (lpj=2803109) > Can't alloc pcache size 32 > Kernel panic - not syncing: Can't create pid_1 cachep > That's stupid. Could be a startup ordering problem, but I can't spot it. Please try setting CONFIG_SLUB=n, CONFIG_SLAB=y and then retest, thanks. Andrew after setting CONFIG_SLUB=n and CONFIG_SLAB, it hits a kernel Bug, and attaching the config file. Memory: 32479392k/33554432k available (2627k kernel code, 280028k reserved, 1274k data, 220k init, 31842304k highmem) virtual kernel memory layout: fixmap : 0xffe1a000 - 0xfffff000 (1940 kB) pkmap : 0xffc00000 - 0xffe00000 (2048 kB) vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc13d6000 - 0xc140d000 ( 220 kB) .data : 0xc1290e65 - 0xc13cf758 (1274 kB) .text : 0xc1000000 - 0xc1290e65 (2627 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1401.57 BogoMIPS (lpj=2803147) ------------[ cut here ]------------ kernel BUG at mm/slab.c:3320! invalid opcode: 0000 [#1] SMP kernel BUG at mm/slab.c:3320! invalid op Modules linked in: Pid: 0, comm: swapper Not tainted (2.6.23-rc3-mm1-autokern1 #1) EIP: 0060:[] EFLAGS: 00010046 CPU: 0 EIP is at ____cache_alloc_node+0x19/0xdd EAX: c1c00060 EBX: 00000003 ECX: 00000001 EDX: 000000d0 ESI: 00000000 EDI: c1c00060 EBP: 00000001 ESP: c13d1f88 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=c13d0000 task=c1350a60 task.ti=c13d0000) Stack: 00000246 000000d0 00000003 000000d0 00000246 c1c00060 c1057c4b 00000003 00099800 c1354bac 01c86007 c1028726 00000000 000080d0 00000282 c1c03620 00000001 00000003 00099800 c13c4000 01c86007 c13e77d3 c13d1fd0 c13d1fd0 Call Trace: [] kmem_cache_alloc+0x21/0xaa [] create_pid_cachep+0x59/0x123 [] pidmap_init+0x2c/0x6c [] start_kernel+0x1b4/0x208 [] unknown_bootoption+0x0/0x139 ======================= Code: 89 c7 0f 84 1e ff ff ff 89 f8 83 c4 0c 5b 5e 5f 5d c3 55 89 cd 57 56 53 57 57 89 c7 89 54 24 04 8b b4 88 c8 00 00 00 85 f6 75 04 <0f> 0b eb fe 8d 46 24 e8 43 85 23 00 8b 1e 39 f3 75 11 c7 46 34 EIP: [] ____cache_alloc_node+0x19/0xdd SS:ESP 0068:c13d1f88 Kernel panic - not syncing: Attempted to kill the idle task!