MySQL SCHMIERT AB mit: "Unable to handle kernel paging request at virtual address"
am 16.10.2006 12:04:15 von papaya74Hallo zusammen,
seit heute morgen um 4.11 Uhr kommt unsere MySQL DB nicht mehr hoch und
produziert folgenden Fehler im syslog:
Oct 16 09:32:12 petruchka kernel: Unable to handle kernel paging
request at virtual address 00850010
Oct 16 09:32:12 petruchka kernel: printing eip:
Oct 16 09:32:12 petruchka kernel: c0143600
Oct 16 09:32:12 petruchka kernel: *pde = 00000000
Oct 16 09:32:12 petruchka kernel: Oops: 0000
Oct 16 09:32:12 petruchka kernel: CPU: 0
Oct 16 09:32:12 petruchka kernel: EIP: 0010:[dnotify_flush+48/96]
Not tainted
Oct 16 09:32:12 petruchka kernel: EFLAGS: 00010206
Oct 16 09:32:12 petruchka kernel: eax: 00004000 ebx: 00850000 ecx:
ec0259c0 edx: ec025ac4
Oct 16 09:32:12 petruchka kernel: esi: e9acb340 edi: ec9e0740 ebp:
bf3feefc esp: ec0cdf8c
Oct 16 09:32:12 petruchka kernel: ds: 0018 es: 0018 ss: 0018
Oct 16 09:32:12 petruchka kernel: Process mysqld (pid: 403,
stackpage=ec0cd000)
Oct 16 09:32:12 petruchka kernel: Stack: e9acb340 00000000 ec9e0740
c012ef27 e9acb340 ec9e0740 e9acb340 43196008
Oct 16 09:32:12 petruchka kernel: 00000050 c012ef83 e9acb340
ec9e0740 ec0cc000 c0106d03 00000050 402f78c0
Oct 16 09:32:12 petruchka kernel: 402f78c0 43196008 00000050
bf3feefc 00000006 0000002b 0000002b 00000006
Oct 16 09:32:12 petruchka kernel: Call Trace: [filp_close+71/96]
[sys_close+67/96] [system_call+51/56]
Oct 16 09:32:12 petruchka kernel:
Oct 16 09:32:12 petruchka kernel: Code: 39 7b 10 75 f3 39 73 0c 75 ee
8b 03 89 02 51 e8 8c ff ff ff
Oct 16 09:32:12 petruchka mysqld[363]: mysqld got signal 11;
Oct 16 09:32:12 petruchka mysqld[363]: This could be because you hit a
bug. It is also possible that this binary
Oct 16 09:32:12 petruchka mysqld[363]: or one of the libraries it was
linked against is corrupt, improperly built,
Oct 16 09:32:12 petruchka mysqld[363]: or misconfigured. This error can
also be caused by malfunctioning hardware.
Oct 16 09:32:12 petruchka mysqld[363]: We will try our best to scrape
up some info that will hopefully help diagnose
Oct 16 09:32:12 petruchka mysqld[363]: the problem, but since we have
already crashed, something is definitely wrong
Oct 16 09:32:12 petruchka mysqld[363]: and this may fail.
Oct 16 09:32:12 petruchka mysqld[363]:
Oct 16 09:32:12 petruchka mysqld[363]: key_buffer_size=33554432
Oct 16 09:32:12 petruchka mysqld[363]: read_buffer_size=131072
Oct 16 09:32:12 petruchka mysqld[363]: max_used_connections=1
Oct 16 09:32:12 petruchka mysqld[363]: max_connections=100
Oct 16 09:32:12 petruchka mysqld[363]: threads_connected=2
Oct 16 09:32:12 petruchka mysqld[363]: It is possible that mysqld could
use up to
Oct 16 09:32:12 petruchka mysqld[363]: key_buffer_size +
(read_buffer_size + sort_buffer_size)*max_connections = 250367 K
Oct 16 09:32:12 petruchka mysqld[363]: bytes of memory
Oct 16 09:32:12 petruchka mysqld[363]: Hope that's ok; if not, decrease
some variables in the equation.
Oct 16 09:32:12 petruchka mysqld[363]:
Oct 16 09:32:12 petruchka mysqld[363]: thd=0x84bfe18
Oct 16 09:32:12 petruchka mysqld[363]: Attempting backtrace. You can
use the following information to find out
Oct 16 09:32:12 petruchka mysqld[363]: where mysqld died. If you see no
messages after this, something went
Oct 16 09:32:12 petruchka mysqld[363]: terribly wrong...
Oct 16 09:32:12 petruchka mysqld[363]: Cannot determine thread,
fp=0xbf1ff5c8, backtrace may not be correct.
Oct 16 09:32:12 petruchka mysqld[363]: Stack range sanity check OK,
backtrace follows:
Oct 16 09:32:12 petruchka mysqld[363]: 0x810e48b
Oct 16 09:32:12 petruchka mysqld[363]: 0x40048825
Oct 16 09:32:12 petruchka mysqld[363]: 0x40048abb
Oct 16 09:32:12 petruchka mysqld[363]: 0x8108b51
Oct 16 09:32:12 petruchka mysqld[363]: 0x811a913
Oct 16 09:32:12 petruchka mysqld[363]: 0x811a208
Oct 16 09:32:12 petruchka mysqld[363]: 0x40042e51
Oct 16 09:32:12 petruchka mysqld[363]: 0x4029f8aa
Oct 16 09:32:12 petruchka mysqld[363]: New value of fp=(nil) failed
sanity check, terminating stack trace!
Oct 16 09:32:12 petruchka mysqld[363]: Please read
http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
Oct 16 09:32:12 petruchka mysqld[363]: stack trace is much more helpful
in diagnosing the problem, so please do
Oct 16 09:32:12 petruchka mysqld[363]: resolve it
Oct 16 09:32:12 petruchka mysqld[363]: Trying to get some variables.
Oct 16 09:32:12 petruchka mysqld[363]: Some pointers may be invalid and
cause the dump to abort...
Oct 16 09:32:12 petruchka mysqld[363]: thd->query at (nil) is invalid
pointer
Oct 16 09:32:12 petruchka mysqld[363]: thd->thread_id=5
Oct 16 09:32:12 petruchka mysqld[363]: The manual page at
http://www.mysql.com/doc/en/Crashing.html contains
Oct 16 09:32:12 petruchka mysqld[363]: information that should help you
find out what is causing the crash.
Ein 'myisamchk --silent --force */*.MYI' wie unter
http://dev.mysql.com/doc/refman/4.1/en/crashing.html beschrieben endet
mit einem "Segmentation fault".
Leider bin ich kein MySQL - Profi, aber ich weiss, hier liegt irgendwas
im Argen.
Hat jemand eine Idee, woher der Fehler kommt, und wie man ihn beheben
kann ?
System Specs:
============
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i386)
Linux version 2.4.20 (root@debian) (gcc version 2.95.4 20011002 (Debian
prerelease))
Vielen Dank,
Harry Jung