Latest working kernel version: Unsure Earliest failing kernel version: Unsure Distribution: Debian 3.0 Etch Hardware Environment: i386, AMD Athlon(TM) MP 2000+ Software Environment: Problem Description: ------------[ cut here ]------------ kernel BUG at mm/slab.c:3008! invalid opcode: 0000 [#1] SMP Pid: 18331, comm: check_snmp_int. Tainted: G M (2.6.24Leonard EIP: 0060:[<c014cb47>] EFLAGS: 00010046 CPU: 0 EIP is at cache_alloc_refill+0x101/0x478 EAX: 0000000a EBX: ffefdfff ECX: f7c09920 EDX: f7c0bc60 ESI: d8857020 EDI: 00000006 EBP: f7c05860 ESP: f7543d10 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process check_snmp_int. (pid: 18331, ti=f7542000 task=f70d5340 tas Stack: f78ffe4c 0000000a 000000d0 f7c09920 00000000 f7c0bc60 f7543 c019c467 f7901a60 c019c643 00000000 f7c09920 00000246 00000 00000000 f7c0b560 f7c11e00 c18cc114 c0177ef7 00000000 c015e Call Trace: [<c015ce15>] dput+0x16/0xe4 [<c019c467>] get_cnode+0x14/0x5b [<c019c643>] journal_mark_dirty+0x195/0x28a [<c014ca0c>] kmem_cache_alloc+0x34/0x6e [<c0177ef7>] proc_alloc_inode+0x12/0x55 [<c015ec96>] alloc_inode+0x12/0x14a [<c015ee0b>] iget_locked+0x3d/0x11b [<c018a28b>] reiserfs_update_sd_size+0x279/0x284 [<c0177fcc>] proc_get_inode+0xc/0xac [<c017bb08>] proc_lookup+0x79/0xe5 [<c0178554>] proc_root_lookup+0xe/0x26 [<c01555f8>] do_lookup+0xa3/0x140 [<c0156a56>] __link_path_walk+0x726/0xb31 [<c019dd38>] journal_end+0xb8/0xbf [<c0156ea5>] link_path_walk+0x44/0xb3 [<c014e0a5>] get_unused_fd_flags+0xc6/0xd0 [<c01571e0>] do_path_lookup+0x162/0x17d [<c0150434>] get_empty_filp+0xe7/0x13c [<c0157b38>] __path_lookup_intent_open+0x45/0x75 [<c0157bdc>] path_lookup_open+0x20/0x25 [<c0157cc0>] open_namei+0x6e/0x527 [<c014e2a1>] do_filp_open+0x25/0x39 [<c014e0a5>] get_unused_fd_flags+0xc6/0xd0 [<c014e2f1>] do_sys_open+0x3c/0x6d [<c014e35b>] sys_open+0x1c/0x1e [<c01025fe>] syscall_call+0x7/0xb ======================= Code: 24 14 8b 32 39 d6 75 17 8b 72 10 89 d0 83 c0 10 c7 42 40 01 EIP: [<c014cb47>] cache_alloc_refill+0x101/0x478 SS:ESP 0068:f7543 ---[ end trace 0b1a3b824b07dae7 ]--- Steps to reproduce: These crashes seem to be at random. I built this kernel from unmodified code from kernel.org. It's possible that this crash was actually the result of bad hardware, I don't really trust the hardware this kernel runs on at the moment, however, I thought I would post this bug report here just in case it is actually a bug. Please disregard it if not.
I had this bug as well, on a Opteron 185 server, with Mandriva and a 2.6.24.2 kernel : Apr 8 11:33:42 gorbatchev kernel: ------------[ cut here ]------------ Apr 8 11:33:42 gorbatchev kernel: kernel BUG at mm/slab.c:3008! Apr 8 11:33:42 gorbatchev kernel: invalid opcode: 0000 [#1] SMP Apr 8 11:33:42 gorbatchev kernel: Modules linked in: cpufreq_ondemand eeprom Apr 8 11:33:42 gorbatchev kernel: Apr 8 11:33:42 gorbatchev kernel: Pid: 24098, comm: poster.eur Not tainted (2.6.24.2 #5) Apr 8 11:33:42 gorbatchev kernel: EIP: 0060:[cache_alloc_refill+393/480] EFLAGS: 00010092 CPU: 0 Apr 8 11:33:42 gorbatchev kernel: EIP: 0060:[<c016be59>] EFLAGS: 00010092 CPU: 0 Apr 8 11:33:42 gorbatchev kernel: EIP is at cache_alloc_refill+0x189/0x1e0 Apr 8 11:33:42 gorbatchev kernel: EAX: 0000001e EBX: 00000037 ECX: f7c03540 EDX: f7c03540 Apr 8 11:33:42 gorbatchev kernel: ESI: f2999000 EDI: f7c11a80 EBP: f7c16800 ESP: f6c2bcc0 Apr 8 11:33:42 gorbatchev kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Apr 8 11:33:42 gorbatchev kernel: Process poster.eur (pid: 24098, ti=f6c2a000 task=f75d5030 task.ti=f6c2a000) Apr 8 11:33:42 gorbatchev kernel: Stack: c01b958d f7c11a88 00000004 000000d0 f7c03540 fffffff4 f7c03540 00000286 Apr 8 11:33:42 gorbatchev kernel: 000000d0 c016c0df fffffff4 f7801694 f7803dc8 f7801694 c0180beb f6c2bd88 Apr 8 11:33:42 gorbatchev kernel: fffffff4 f7801694 f7803dc8 f7803e38 c01765a5 f6c2bf40 f6c2bd88 00000000 Apr 8 11:33:42 gorbatchev kernel: Call Trace: pr 8 11:33:42 gorbatchev kernel: [reiserfs_find_entry+173/288] reiserfs_find_entry+0xad/0x120 Apr 8 11:33:42 gorbatchev kernel: [<c01b958d>] reiserfs_find_entry+0xad/0x120 Apr 8 11:33:42 gorbatchev kernel: [kmem_cache_alloc+95/144] kmem_cache_alloc+0x5f/0x90 Apr 8 11:33:42 gorbatchev kernel: [<c016c0df>] kmem_cache_alloc+0x5f/0x90 Apr 8 11:33:42 gorbatchev kernel: [d_alloc+27/368] d_alloc+0x1b/0x170 Apr 8 11:33:42 gorbatchev kernel: [<c0180beb>] d_alloc+0x1b/0x170 Apr 8 11:33:42 gorbatchev kernel: [real_lookup+165/288] real_lookup+0xa5/0x120 Apr 8 11:33:42 gorbatchev kernel: [<c01765a5>] real_lookup+0xa5/0x120 Apr 8 11:33:43 gorbatchev kernel: [do_lookup+144/208] do_lookup+0x90/0xd0 Apr 8 11:33:43 gorbatchev kernel: [<c0176870>] do_lookup+0x90/0xd0 Apr 8 11:33:43 gorbatchev kernel: [__link_path_walk+1561/3056] __link_path_walk+0x619/0xbf0 Apr 8 11:33:43 gorbatchev kernel: [<c0176ec9>] __link_path_walk+0x619/0xbf0 Apr 8 11:33:43 gorbatchev kernel: [link_path_walk+186/432] link_path_walk+0xba/0x1b0 Apr 8 11:33:43 gorbatchev kernel: [<c017755a>] link_path_walk+0xba/0x1b0 Apr 8 11:33:43 gorbatchev kernel: [copy_to_user+50/80] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [<c0212c62>] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [do_page_fault+314/1488] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [<c011b7fa>] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [vfs_follow_link+39/320] vfs_follow_link+0x27/0x140 Apr 8 11:33:43 gorbatchev kernel: [<c0179fb7>] vfs_follow_link+0x27/0x140 Apr 8 11:33:43 gorbatchev kernel: [proc_self_follow_link+74/80] proc_self_follow_link+0x4a/0x50 Apr 8 11:33:43 gorbatchev kernel: [<c01aa51a>] proc_self_follow_link+0x4a/0x50 Apr 8 11:33:43 gorbatchev kernel: [__link_path_walk+456/3056] __link_path_walk+0x1c8/0xbf0 Apr 8 11:33:43 gorbatchev kernel: [<c0176a78>] __link_path_walk+0x1c8/0xbf0 Apr 8 11:33:43 gorbatchev kernel: [prep_new_page+202/304] prep_new_page+0xca/0x130 Apr 8 11:33:43 gorbatchev kernel: [<c015260a>] prep_new_page+0xca/0x130 Apr 8 11:33:43 gorbatchev kernel: [link_path_walk+186/432] link_path_walk+0xba/0x1b0 Apr 8 11:33:43 gorbatchev kernel: [<c017755a>] link_path_walk+0xba/0x1b0 Apr 8 11:33:43 gorbatchev kernel: [copy_to_user+50/80] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [<c0212c62>] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [do_page_fault+314/1488] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [<c011b7fa>] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [do_path_lookup+190/416] do_path_lookup+0xbe/0x1a0 Apr 8 11:33:43 gorbatchev kernel: [<c01778ae>] do_path_lookup+0xbe/0x1a0 Apr 8 11:33:43 gorbatchev kernel: [__user_walk_fd+59/96] __user_walk_fd+0x3b/0x60 Apr 8 11:33:43 gorbatchev kernel: [<c0177d7b>] __user_walk_fd+0x3b/0x60 Apr 8 11:33:43 gorbatchev kernel: [sys_readlinkat+54/160] sys_readlinkat+0x36/0xa0 Apr 8 11:33:43 gorbatchev kernel: [<c01726e6>] sys_readlinkat+0x36/0xa0 Apr 8 11:33:43 gorbatchev kernel: [copy_to_user+50/80] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [<c0212c62>] copy_to_user+0x32/0x50 Apr 8 11:33:43 gorbatchev kernel: [do_page_fault+314/1488] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [<c011b7fa>] do_page_fault+0x13a/0x5d0 Apr 8 11:33:43 gorbatchev kernel: [sys_readlink+39/48] sys_readlink+0x27/0x30 Apr 8 11:33:43 gorbatchev kernel: [<c0172777>] sys_readlink+0x27/0x30 Apr 8 11:33:43 gorbatchev kernel: [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 Apr 8 11:33:43 gorbatchev kernel: [<c0102f66>] sysenter_past_esp+0x5f/0x85 Apr 8 11:33:43 gorbatchev kernel: ======================= Apr 8 11:33:43 gorbatchev kernel: Code: 85 14 83 c4 14 5b 5e 5f 5d c3 8b 77 10 8d 47 10 c7 47 34 01 00 00 00 39 c6 74 99 8b 54 24 10 8b 42 20 39 46 10 0f 82 18 ff ff ff <0f> 0b 90 8d 74 26 00 eb fe 0f 0b eb fe 8b 54 24 0c 8b 44 24 10 Apr 8 11:33:43 gorbatchev kernel: EIP: [cache_alloc_refill+393/480] cache_alloc_refill+0x189/0x1e0 SS:ESP 0068:f6c2bcc0 Apr 8 11:33:43 gorbatchev kernel: EIP: [<c016be59>] cache_alloc_refill+0x189/0x1e0 SS:ESP 0068:f6c2bcc0 Apr 8 11:33:43 gorbatchev kernel: ---[ end trace d87777229892e854 ]---
I have the same problem on ubuntu hardy with kernel 2.6.24-16-xen. There is another report: http://www.mail-archive.com/misdn-asterisk@lists.beronet.com/msg00567.html I also use asterisk misdn from the git repository. My crashes happen some time after the first call to asterisk which remains unanswered. In the mean time, sometimes processes seem to hang indefinitely without showing any activitiy in ps or top.
These traces contain no useful info alas - just indicating memory problems (in the asterisk case quite possibly linked to a driver bug) Closing this therefore. If the mIsdn related asterisk crashes are repeatable with a modern kernel and inbuilt mISDN please open a new bug for that and include info on the isdn hardware in use - thanks