View previous topic :: View next topic |
Author |
Message |
Obelix Tux's lil' helper
Joined: 22 Aug 2011 Posts: 100
|
Posted: Fri Oct 19, 2012 5:42 am Post subject: [solved] NULL Pointer Exception im Kernel |
|
|
Guten Morgen,
jetzt weiß ich, warum ich gestern zum booten des Servers hinlaufen und ausschalten musste (ich war inzwischen noch ein paar mal dort)
Code: | [ 162.499182] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 253299697
[ 167.715199] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[ 167.715350] IP: [<ffffffff811c30bc>] ext4_ext_remove_space+0x9fc/0xe20
[ 167.715456] PGD 469395067 PUD 3524a0067 PMD 0
[ 167.715639] Oops: 0000 [#1] SMP
[ 167.715781] CPU 2
[ 167.715830] Modules linked in: sha256_generic blowfish_generic blowfish_x86_64 blowfish_common dm_crypt vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
[ 167.716178]
[ 167.716178] Pid: 2570, comm: mount Tainted: G IO 3.4.9-gentoo #4 Intel S5400SF/S5400SF
[ 167.716178] RIP: 0010:[<ffffffff811c30bc>] [<ffffffff811c30bc>] ext4_ext_remove_space+0x9fc/0xe20
[ 167.716178] RSP: 0018:ffff8803524d59d8 EFLAGS: 00010246
[ 167.716178] RAX: 0000000000000000 RBX: ffff88046d5ef270 RCX: 0000000000000002
[ 167.716178] RDX: 0000000000000001 RSI: 0000000078c8fe39 RDI: 0000000078c8fe39
[ 167.716178] RBP: ffff8803524d5ae8 R08: 00000000aea77c00 R09: 0000000000000001
[ 167.716178] R10: ffffffff811c2a6d R11: 0000000000000001 R12: 0000000000000000
[ 167.716178] R13: ffff88046716fc70 R14: 0000000000000000 R15: 0000000000000001
[ 167.716178] FS: 00007f580f139740(0000) GS:ffff88047fc80000(0000) knlGS:0000000000000000
[ 167.716178] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 167.716178] CR2: 0000000000000028 CR3: 000000044cbc3000 CR4: 00000000000027e0
[ 167.716178] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 167.716178] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 167.716178] Process mount (pid: 2570, threadinfo ffff8803524d4000, task ffff88046d54ba80)
[ 167.716178] Stack:
[ 167.716178] 0000000000001111 ffff88046716fc70 ffff88046716fbc0 ffff8803524d5a98
[ 167.716178] ffff880394288000 ffff8804671c51a0 ffffffff524d5a68 ffff88046bc04000
[ 167.716178] 000000016ef01018 0000000100000000 ffff88046716fbc0 ffff88046bc05800
[ 167.716178] Call Trace:
[ 167.716178] [<ffffffff811c563b>] ext4_ext_truncate+0x1ab/0x1f0
[ 167.716178] [<ffffffff811b7d4b>] ? ext4_journal_start_sb+0x7b/0x1b0
[ 167.716178] [<ffffffff81199788>] ext4_truncate+0xb8/0xf0
[ 167.716178] [<ffffffff8119e3b8>] ext4_evict_inode+0x3c8/0x4c0
[ 167.716178] [<ffffffff8113ac56>] evict+0xa6/0x1b0
[ 167.716178] [<ffffffff8113ae63>] iput+0x103/0x210
[ 167.716178] [<ffffffff811bbf6b>] ext4_fill_super+0x29bb/0x2b00
[ 167.716178] [<ffffffff810e7d0d>] ? register_shrinker+0x4d/0x60
[ 167.716178] [<ffffffff81124b92>] mount_bdev+0x1a2/0x1e0
[ 167.716178] [<ffffffff811b95b0>] ? ext4_calculate_overhead+0x3d0/0x3d0
[ 167.716178] [<ffffffff8111dcb3>] ? __kmalloc_track_caller+0x53/0x160
[ 167.716178] [<ffffffff811b0920>] ext4_mount+0x10/0x20
[ 167.716178] [<ffffffff81125912>] mount_fs+0x42/0x1b0
[ 167.716178] [<ffffffff810f719b>] ? __alloc_percpu+0xb/0x10
[ 167.716178] [<ffffffff8113e40d>] vfs_kern_mount+0x6d/0x100
[ 167.716178] [<ffffffff8113ec2f>] do_kern_mount+0x4f/0x100
[ 167.716178] [<ffffffff81140848>] do_mount+0x518/0x7e0
[ 167.716178] [<ffffffff810f21e6>] ? memdup_user+0x46/0x90
[ 167.716178] [<ffffffff810f2283>] ? strndup_user+0x53/0x70
[ 167.716178] [<ffffffff81140c3b>] sys_mount+0x8b/0xe0
[ 167.716178] [<ffffffff816851a2>] system_call_fastpath+0x16/0x1b
[ 167.716178] Code: 8d 04 40 48 8d 04 81 48 89 43 18 0f b7 49 02 48 83 c1 01 48 85 c0 48 89 0b 0f 85 c1 f8 ff ff 0f 0b 66 0f 1f 44 00 00 48 8b 43 28 <48> 8b 40 28 48 89 43 20 e9 8a f8 ff ff 0f 1f 80 00 00 00 00 44
[ 167.716178] RIP [<ffffffff811c30bc>] ext4_ext_remove_space+0x9fc/0xe20
[ 167.716178] RSP <ffff8803524d59d8>
[ 167.716178] CR2: 0000000000000028
[ 167.725871] ---[ end trace 6719e73a51c1e021 ]---
[ 167.726127] mount used greatest stack depth: 3816 bytes left
|
Diese Meldung kommt, wenn ich den einen der beiden RAID5 Verbunde mounten will. Danach könnte ich zwar den Server laufen lassen (ohne diese Platten), aber nicht mehr booten. Statt reboot macht der Server einfach nichts. Also hinlaufen, ausschalten, einschalten. Selber Fehler.
Ich hab schon mal den Kernel neu kompiliert mit allen Modulen, aber hat leider nichts gebracht.
Kann mir hier jemand sagen, wie ich das in den Griff bekomme, ohne die Platte (den RAID5 Turm) neu zu partitionieren? Es ist zwar "nur" die Backup Platte, aber ich habe eigentlich keine Lust, die ganzen Daten wieder zu kopieren...
EDIT: ich war gerade den Server besuchen. Bei der Gelegenheit habe ich einen alten Kernel gebootet. Zwar hat das mounten locker mal 10 Minuten gedauert, aber es hat geklappt. Also ist es ein Problem des Kernels 3.4.9, denn 3.3.8 läuft.
Hat jemand dazu einen Tipp? _________________ read my lips: NO MORE BUGS!!
Last edited by Obelix on Fri Oct 19, 2012 10:37 pm; edited 1 time in total |
|
Back to top |
|
|
Hollowman Guru
Joined: 19 Apr 2007 Posts: 584
|
Posted: Fri Oct 19, 2012 4:24 pm Post subject: |
|
|
Hi
Mach mal mit dem neuen Kernel ein e2fsck -f auf das Raid. Haste das Problem dann immer noch?
Platten in dem Raid sind auch noch gesund? Kannst du den auslesen? Wenn ja was sagt er über die Platten? Nicht das da was im argen ist.
Sebastian |
|
Back to top |
|
|
Obelix Tux's lil' helper
Joined: 22 Aug 2011 Posts: 100
|
Posted: Fri Oct 19, 2012 10:37 pm Post subject: |
|
|
...ich bin etwas verblüfft, weil ich da schon ein paar Meldungen erwartet hätte, die auf Fehler hinweisen
Code: | e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/backup: 385162/366276608 files (1.1% non-contiguous), 1686645318/2930211840 blocks |
daraus erlese ich jetzt keine aufregenden Korrekturen am Filesystem. Aber gut. Ich konnte die Platten mounten. Da die Geschichte nicht so alt ist, vermute ich keinen Plattendefekt (und der Turm würde das auch farblich kennzeichnen, wenn so etwas wäre, damit man den Slot mit der defekten Platte identifizieren kann)
Eine Datei konnte ich noch als defekt identifizieren, weil die von der Größe her (5 PiB) das RAID gesprengt hätte, aber im Backup war die Datei noch ok, also konnte ich sie von Hand wieder herstellen.
Ich hoffe, dass das mit kleineren Dateien nicht auch noch der Fall ist...
Ich danke dir für den Tipp. Hoffentlich bleibt es jetzt so, dass ich die Systeme nächstes mal wieder mounten kann... _________________ read my lips: NO MORE BUGS!! |
|
Back to top |
|
|
Christian99 Veteran
Joined: 28 May 2009 Posts: 1668
|
Posted: Sat Oct 20, 2012 10:23 am Post subject: |
|
|
ich bin jetzt kein kernel-entwickler/experte, aber dass ein fehler im dateisystem zu sowas führt interessiert bestimmt einige leute. Vllt. wäre es angebracht sowas mal weiter zu melden? |
|
Back to top |
|
|
Obelix Tux's lil' helper
Joined: 22 Aug 2011 Posts: 100
|
Posted: Sat Oct 20, 2012 10:25 am Post subject: |
|
|
...gern, wenn mir noch jemand sagt, wohin, mache ich es. Ich bin ja selbst auch Softwareentwickler (hauptberuflich) und auch immer interessiert an so merkwürdigkeiten... _________________ read my lips: NO MORE BUGS!! |
|
Back to top |
|
|
Christian99 Veteran
Joined: 28 May 2009 Posts: 1668
|
Posted: Sat Oct 20, 2012 10:31 am Post subject: |
|
|
wie gesagt, ich kenn mich da jetzt auch nicht so aus. auf den ersten blick(?) scheint der fehler in ext4 passiert zu sein, und ich glaube (?) das wird direkt vom kernel team gepflegt. auf kernel.org hab ich das hier gefunden, http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html, aber vielleciht liest das auch jemand mit besseren kentnissen als ich.... |
|
Back to top |
|
|
Obelix Tux's lil' helper
Joined: 22 Aug 2011 Posts: 100
|
Posted: Sun Oct 21, 2012 2:28 pm Post subject: |
|
|
[Logbucheintrag der Serverflotte 2012-10-21 16:24 Captain Obelix - Nachtrag]
Ich habe gerade den Kernel auf 3.5.7 aktualisiert. Es ging problemlos die Platten zu mounten. Was noch viel auffälliger war, seit dem "e2fsck -f" hat das mounten der Platte statt bisher 1,5 bis 2 Minuten (sic!) pro Platte nur noch 1,5 Sekunden gedauert... Da war echt übel was im Argen... _________________ read my lips: NO MORE BUGS!! |
|
Back to top |
|
|
Hollowman Guru
Joined: 19 Apr 2007 Posts: 584
|
Posted: Sun Oct 21, 2012 3:21 pm Post subject: |
|
|
Hi
Ich hatte das auch schon mal, allerdings mit nem Ext3 auf RAID-5. Das e2fsck -f hatte da auch Wunder gewirkt.
Schau mal ob du in /var/log/messages diese Zeilen findest:
Code: | INFO: recovery required on readonly filesystem
write access will be enabled during recovery
recovery complete |
Sebastian |
|
Back to top |
|
|
Obelix Tux's lil' helper
Joined: 22 Aug 2011 Posts: 100
|
Posted: Sun Oct 21, 2012 5:41 pm Post subject: |
|
|
...das bekomme ich nicht mehr raus, weil ich heute mal die Datei gelöscht habe. Die war schon _dermaßen_ groß, dass es nicht mehr angenehm war, darin was zu suchen...
Aber es beruhigt mich, dass ich nicht der einzige bin, der das so hatte... _________________ read my lips: NO MORE BUGS!! |
|
Back to top |
|
|
|