Journal Oops

Posté par  .
Étiquettes : aucune
0
20
nov.
2003
mon kernel a fait un Oops ;(
apparament c'est la memoire défaillante!!

une idee ?


grep "Nov 18 13:01:00 ninoxe kernel:" /var/log/messages |ksymoops
ksymoops 2.4.8 on i686 2.4.21-0.13mdkenterprise. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-0.13mdkenterprise/ (default)
-m /boot/System.map-2.4.21-0.13mdkenterprise (default)

Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

Nov 18 13:01:00 ninoxe kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000028
Nov 18 13:01:00 ninoxe kernel: c01622ec
Nov 18 13:01:00 ninoxe kernel: *pde = 00000000
Nov 18 13:01:00 ninoxe kernel: Oops: 0000
Nov 18 13:01:00 ninoxe kernel: CPU: 0
Nov 18 13:01:00 ninoxe kernel: EIP: 0010:[ext2_commit_chunk+60/112] Not tainted
Nov 18 13:01:00 ninoxe kernel: EIP: 0010:[] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Nov 18 13:01:00 ninoxe kernel: EFLAGS: 00010282
Nov 18 13:01:00 ninoxe kernel: eax: 00000000 ebx: e7093820 ecx: e7093820 edx: 00000000
Nov 18 13:01:00 ninoxe kernel: esi: c1741520 edi: 00000000 ebp: e48bbea4 esp: e48bbe98
Nov 18 13:01:00 ninoxe kernel: ds: 0018 es: 0018 ss: 0018
Nov 18 13:01:00 ninoxe kernel: Process postdrop (pid: 4492, stackpage=e48bb000)
Nov 18 13:01:00 ninoxe kernel: Stack: ea363018 e8083727 ea36302b e48bbef8 c0162d35 c1741520 0000000c 0000002c
Nov 18 13:01:00 ninoxe kernel: 028bbef8 c100001c 00000000 0000002c 0000000c ea363fec 00000000 00000001
Nov 18 13:01:00 ninoxe kernel: c1741520 00000014 0000000b e808371c e7893820 ec448640 ec448640 e80836c0
Nov 18 13:01:00 ninoxe kernel: Call Trace: [ext2_add_link+565/672] [ext2_create+98/160] [vfs_create+136/272] [open_namei+1427/1552] [filp_open+53/96]
Nov 18 13:01:00 ninoxe kernel: Call Trace: [] [] [] [] []
Nov 18 13:01:00 ninoxe kernel: [] []
Nov 18 13:01:00 ninoxe kernel: Code: f6 40 28 10 75 09 f6 83 00 01 00 00 01 74 16 56 e8 ef af fd


>>EIP; c01622ec <show_vfsmnt+25c/380> <=====

>>ebx; e7093820 <_end+26c457f4/383b4034>
>>ecx; e7093820 <_end+26c457f4/383b4034>
>>esi; c1741520 <_end+12f34f4/383b4034>
>>ebp; e48bbea4 <_end+2446de78/383b4034>
>>esp; e48bbe98 <_end+2446de6c/383b4034>

Trace; c0162d35 <do_move_mount+15/220>
Trace; c0165942 <do_quotactl+2a2/390>
Trace; c01442f8 <.text.lock.shmem+109/181>
Trace; c0144913 <__constant_c_and_count_memset+93/a0>
Trace; c0139295 <.text.lock.filemap+264/27f>
Trace; c013962d <sys_mprotect+2d/2a0>
Trace; c0108fe3 <handle_signal+3/150>

Code; c01622ec <show_vfsmnt+25c/380>
00000000 <_EIP>:
Code; c01622ec <show_vfsmnt+25c/380> <=====
0: f6 40 28 10 testb $0x10,0x28(%eax) <=====
Code; c01622f0 <show_vfsmnt+260/380>
4: 75 09 jne f <_EIP+0xf>
Code; c01622f2 <show_vfsmnt+262/380>
6: f6 83 00 01 00 00 01 testb $0x1,0x100(%ebx)
Code; c01622f9 <show_vfsmnt+269/380>
d: 74 16 je 25 <_EIP+0x25>
Code; c01622fb <show_vfsmnt+26b/380>
f: 56 push %esi
Code; c01622fc <show_vfsmnt+26c/380>
10: e8 ef af fd 00 call fdb004 <_EIP+0xfdb004>


1 warning issued. Results may not be reliable.

  • # Re: Oops

    Posté par  . Évalué à 4.

    si tu veux t'en assurer et que tu as l'adsl, le cd1 de la fedora core compore un outil de test de la mémoire (dans le menu expert). Il utilise Mem86 (orthographe aproximative)

  • # Re: Oops

    Posté par  (site web personnel) . Évalué à 2.

    Tu crois vraiment que c'est un problème de mémoire (si tu veux en etre sur il y a toujours memtest86) ?

    Sachant que tu es sous mandrake, je dirais plutot un problème avec supermount, d'autant plus que le truc a oopsé dans le vfs. J'ai entendu dire que mandrake avait mis à jour supermount, tu devrais peut-etre essayer de mettre à jour ton noyau.

    • [^] # Re: Oops

      Posté par  . Évalué à 2.

      Pour utiliser Memtest86, pas besoin de la Mandrake, ça s'installe très bien dans ton bootloader favori, ou sur une disquette.

      Par contre, c'est quand même fort si un supermount défaillant peut mettre tout le système en rade. Bon, je pense que tout ce qui est compilé dans le kernel peut le faire ?

      • [^] # Re: Oops

        Posté par  (site web personnel) . Évalué à 2.

        Pour utiliser Memtest86, pas besoin de la Mandrake, ça s'installe très bien dans ton bootloader favori, ou sur une disquette.
        Je n'ai jamais fait une telle affirmation ;)

        Par contre, c'est quand même fort si un supermount défaillant peut mettre tout le système en rade. Bon, je pense que tout ce qui est compilé dans le kernel peut le faire ?
        Ben le système n'est pas vraiment en rade, puisque c'est juste un oops. Souvent, on trouve juste une entrée dans les logs et la machine continue de tourner plus ou moins normalement (ne pas confondre un kernel oops qui n'est pas fatal avec un kernel panic qui lui arrete tout). Les oops que j'ai ne m'empechent pas de redémarrer proprement la machine en général.

      • [^] # Re: Oops

        Posté par  (site web personnel) . Évalué à 3.

        "Par contre, c'est quand même fort si un supermount défaillant peut mettre tout le système en rade. "

        Faut dire que jusqu'a la 9.1, supermount etait une grosse merde(si si :). Il parait que ca marche mieux, il parait, je l'utilise pas(maintenant, un user+noauto est quand meme mieux quand on utilise gnome ou kde)

    • [^] # Re: Oops

      Posté par  . Évalué à 1.

      en fait j'ai eu plusieurs "Unable to handle kernel NULL pointer" aléatoires
      ce qui est un symptôme de la mémoire défaillante !
      pour memtest86 il plante chez moi ;(
      Me

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.