This has happened twice now. The MySQL people told me to notify the developers of the problem: Redhat 7.0 256mb ram pIII 750mhz MySQL, being apparently the most stressed process on your system, was the one that caused the kernel to panic. However, this is not the fault of MySQL - no user process regardless of how buggy or malicious should ever be able to make the kernel panic. You should send the above information to the kernel developers - this will help them a great deal in fixing the bug. -- MySQL Development Team Oct 24 15:23:59 zephyr kernel: Unable to handle kernel paging request at virtual address 00d7e31c Oct 24 15:23:59 zephyr kernel: current->tss.cr3 = 05f3d000, %cr3 = 05f3d000 Oct 24 15:23:59 zephyr kernel: *pde = 00000000 Oct 24 15:23:59 zephyr kernel: Oops: 0000 Oct 24 15:23:59 zephyr kernel: CPU: 0 Oct 24 15:23:59 zephyr kernel: EIP: 0010:[kmem_cache_alloc+49/292] Oct 24 15:23:59 zephyr kernel: EFLAGS: 00010002 Oct 24 15:23:59 zephyr kernel: eax: cad7efe0 ebx: cad7efe0 ecx: 00d7e31c edx: c0502 580 Oct 24 15:23:59 zephyr kernel: esi: 00000000 edi: cfeef740 ebp: 00000282 esp: c2e01 d9c Oct 24 15:23:59 zephyr kernel: ds: 0018 es: 0018 ss: 0018 Oct 24 15:23:59 zephyr kernel: Process mysqld (pid: 23752, process nr: 200, stackpage=c2e 01000) Oct 24 15:23:59 zephyr kernel: Stack: 00000000 00001000 c012779d cfeef740 00000005 000000 00 00000000 c012782a Oct 24 15:23:59 zephyr kernel: 00000000 00001000 00001000 ca165000 00000806 c2e01d dc c2e01ddc c2e00000 Oct 24 15:23:59 zephyr kernel: c2e00000 00000000 c01283a1 ca165000 00001000 000000 00 00000000 00001000 Oct 24 15:23:59 zephyr kernel: Call Trace: [get_unused_buffer_head+85/160] [create_buffer s+66/408] [grow_buffers+85/236] [refill_freelist+10/56] [getblk+286/324] [ext2_alloc_bloc k+109/352] [block_getblk+305/624]
Closing - this bug related to very old kernels and doesn't contain any information thats useful for current bug engineering. Of course if mysql is crashing on an RH8/9 setup and someone finds this bug - please open a new bug