Kernel Meldungen

[Schani]

Hallo zusammen, ich habe auf einem AMD 64 das aktuelle debian etch installiert. Zusätzlich ist noch ein SCSI Hardware Array drauf. Leider habe ich in letzter Zeit immer mal wieder Kernel Fehler die zum Stillstand führen.
Vor ein paar Tagen habe ich mich dann mal rangewagt und einen eigenen Kernel gebacken und installiert. Der Server läuft stabiler, bringt aber ab und zu trotzdem Fehlermeldungen aus denen ich nicht schlau werde.

Was mich wundert ist das nach ein paar Tagen die Grundauslastung auf 2.0 | 2.0 | 2.0 steht. Der Server läuft derzeit noch fast im Standgas, also ohne große Last. Die 2.0 sind einfach nur ein Offset.

Was mich noch verwirrt ist das alle /lib64 auf /lib gelinkt sind. Ist das normal?

Könnt Ihr mir Bitte sagen was ich noch prüfen kann um einen stabilen Server zu bekommen.

Besten Dank

Christian

Code: Alles auswählen

Apr  2 00:35:18 s15293430 kernel: gm[11833]: segfault at 00002b531fed5b10 rip 00002b531dff61c3 rsp 00007fff8cabf440 error 6
Apr  2 00:35:28 s15293430 kernel: imapd[2182]: segfault at 0000000000000031 rip 00002b4c64244ccc rsp 00007fff46e66dc0 error 4
Apr  2 00:35:28 s15293430 kernel: Eeek! page_mapcount(page) went negative! (-1)
Apr  2 00:35:28 s15293430 kernel:   page pfn = 10d11c
Apr  2 00:35:28 s15293430 kernel:   page->flags = 800000000001003c
Apr  2 00:35:28 s15293430 kernel:   page->count = 1
Apr  2 00:35:28 s15293430 kernel:   page->mapping = ffff81011b91b790
Apr  2 00:35:28 s15293430 kernel:   vma->vm_ops = _stext+0x7fdf7000/0x1a
Apr  2 00:35:29 s15293430 kernel: ------------[ cut here ]------------
Apr  2 00:35:29 s15293430 kernel: kernel BUG at mm/rmap.c:630!
Apr  2 00:35:29 s15293430 kernel: invalid opcode: 0000 [1] SMP
Apr  2 00:35:29 s15293430 kernel: CPU 1
Apr  2 00:35:29 s15293430 kernel: Modules linked in:
Apr  2 00:35:29 s15293430 kernel: Pid: 11861, comm: apache2 Tainted: G   M    2.6.23.16-20080211a #1
Apr  2 00:35:29 s15293430 kernel: RIP: 0010:[<ffffffff8027736e>]  [<ffffffff8027736e>] page_remove_rmap+0x115/0x131
Apr  2 00:35:29 s15293430 kernel: RSP: 0018:ffff8100d901bbd8  EFLAGS: 00010246
Apr  2 00:35:29 s15293430 kernel: RAX: 0000000000000000 RBX: ffff810004adbe20 RCX: ffffffff806c8e08
Apr  2 00:35:29 s15293430 kernel: RDX: 0000000100000000 RSI: 0000000000000096 RDI: ffffffff806c8e00
Apr  2 00:35:29 s15293430 kernel: RBP: ffff8100a8107870 R08: ffffffff806c8e08 R09: 0000000000000000
Apr  2 00:35:29 s15293430 kernel: R10: 0000000000000046 R11: ffffffff8021eb86 R12: 0000000000ced000
Apr  2 00:35:29 s15293430 kernel: R13: ffff81007c2da768 R14: ffff810004f255e0 R15: 0000000000e00000
Apr  2 00:35:29 s15293430 kernel: FS:  00002b12d4e685c0(0000) GS:ffff81011fc6aec0(0000) knlGS:0000000000000000
Apr  2 00:35:29 s15293430 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Apr  2 00:35:29 s15293430 kernel: CR2: 00002b12d3b95a02 CR3: 00000000da6bd000 CR4: 00000000000006e0
Apr  2 00:35:29 s15293430 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr  2 00:35:29 s15293430 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr  2 00:35:29 s15293430 kernel: Process apache2 (pid: 11861, threadinfo ffff8100d901a000, task ffff8100a6cd4040)
Apr  2 00:35:29 s15293430 kernel: Stack:  ffff810004adbe20 ffff810004adbe20 000000000d11c000 ffffffff8026febc
Apr  2 00:35:29 s15293430 kernel:  0000000000000000 ffff8100d901bcc8 ffffffffffffffff 0000000000000000
Apr  2 00:35:29 s15293430 kernel:  ffff8100a8107870 ffff8100d901bcd0 0000000000278ff4 0000000000000000
Apr  2 00:35:29 s15293430 kernel: Call Trace:
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff8026febc>] unmap_vmas+0x3ec/0x70e
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80273a95>] exit_mmap+0x74/0xe9
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80235937>] mmput+0x2c/0x9d
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80287125>] flush_old_exec+0x617/0x8ea
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80283309>] vfs_read+0x13f/0x153
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff802b2a25>] load_elf_binary+0x493/0x1a64
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff8027118d>] get_user_pages+0x2ff/0x365
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80285fa1>] get_arg_page+0x46/0x9c
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80286287>] copy_strings+0x1b8/0x1c9
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff80286386>] search_binary_handler+0xbb/0x206
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff802878bb>] do_execve+0x166/0x1e4
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff8020ac60>] sys_execve+0x36/0x88
Apr  2 00:35:29 s15293430 kernel:  [<ffffffff8020c1b7>] stub_execve+0x67/0xb0
Apr  2 00:35:29 s15293430 kernel:
Apr  2 00:35:29 s15293430 kernel:
Apr  2 00:35:29 s15293430 kernel: Code: 0f 0b eb fe 8b 77 18 41 58 5b 5d 83 e6 01 f7 de 83 c6 04 e9
Apr  2 00:35:29 s15293430 kernel: RIP  [<ffffffff8027736e>] page_remove_rmap+0x115/0x131
Apr  2 00:35:29 s15293430 kernel:  RSP <ffff8100d901bbd8>

[storm]

Leider habe ich in letzter Zeit immer mal wieder Kernel Fehler die zum Stillstand führen.

Code: Alles auswählen

Apr  2 00:35:18 s15293430 kernel: gm[11833]: segfault at 00002b531fed5b10 rip 00002b531dff61c3 rsp 00007fff8cabf440 error 6
Apr  2 00:35:28 s15293430 kernel: imapd[2182]: segfault at 0000000000000031 rip 00002b4c64244ccc rsp 00007fff46e66dc0 error 4
...
Apr  2 00:35:28 s15293430 kernel: Eeek! page_mapcount(page) went negative! (-1)
...
Apr  2 00:35:29 s15293430 kernel: kernel BUG at mm/rmap.c:630!
Apr  2 00:35:29 s15293430 kernel: invalid opcode: 0000 [1] SMP
Apr  2 00:35:29 s15293430 kernel: CPU 1
Apr  2 00:35:29 s15293430 kernel: Modules linked in:
...
Apr  2 00:35:29 s15293430 kernel: Pid: 11861, comm: apache2 Tainted: G   M    2.6.23.16-20080211a #1
...

Das kann natürlich Zufall sein, dass mehrere segfaults innerhalb einer kurzen Zeitspanne auftreten, und dann auch noch apache in's Leere greift. Allerdings sollte die letzte Zeile mit den Tainted-flags zu denken geben, das flag 'M' erscheint, wenn eine Machine Check Exception gemeldet wurde. Das kommt von der Hardware. Steht da weiter oben im syslog vielleicht irgendetwas dazu? Natürlich bleibt die Möglichkeit eines kernel-bugs.

Was mich wundert ist das nach ein paar Tagen die Grundauslastung auf 2.0 | 2.0 | 2.0 steht. Der Server läuft derzeit noch fast im Standgas, also ohne große Last. Die 2.0 sind einfach nur ein Offset.

Na irgendwas muß da Last verursachen. top sollte dir da sagen, wer der Schuldige ist.

ciao, storm

[storm]

Nachtrag: da gab's unter 2.6.22 schon einige Meldungen [1] zu diesem Fehler, allerdings soll das mit 2.6.23 behoben worden sein [2]:

Thank you for your report.
there have been several reports (at least 8 on lkml already) of this
BUG() before for 2.6.22 (and a few before that), however nobody has
reported this in 2.6.23 or later, so it's very likely something that
this got fixed since in a later kernel....

Möglicherweise hat der fix nicht alles erwischt.

ciao, storm

[1] http://kerneloops.org/guilty.php?guilty ... class=oops
[2] http://kerneltrap.org/mailarchive/linux ... 2/3/470867

[Schani]

Jetzt bin ich aber am grübeln.

Ich habe mir ja einen eigenen Kernel gebaut und auch verlinkt. > 2.6.24.4

Nun sehe ich gerade das die Kernelmeldungen sich auf 2.6.23.16-20080211a beziehen.

Das ergibt auch
cat /proc/sys/kernel/osrelease
2.6.23.16-20080211a

Mein Lilo hat folgeneden Eintrag:

Code: Alles auswählen

boot=/dev/sda
root=/dev/sda1
vga=normal
timeout=60
prompt
lba32
read-only
default=lxser
serial=0,57600n8
append="console=ttyS0,57600 console=tty0 panic=30"
image=/vmlinuz
        label=lxser
        append="console=tty0 console=ttyS0,57600 panic=30"
image=/vmlinuz.old
        optional
        label=lxserold
        append="console=tty0 console=ttyS0,57600 panic=30"
image=/boot/memtest86+.bin
        optional
        label = memtest86+

und vmlinuz hat einen link auf
lrwxrwxrwx 1 root root 22 Mar 31 23:42 vmlinuz -> /boot/vmlinuz-2.6.24.4

Mein boot:

Code: Alles auswählen

-rw-r--r-- 1 root root 1290771 Nov  8 13:04 System.map-2.6.20.21-071108a
-rw-r--r-- 1 root root 1357460 Feb 11 09:48 System.map-2.6.23.16-20080211a
-rw-r--r-- 1 root root 1403281 Mar 31 23:44 System.map-2.6.24.4
-rw-r--r-- 1 root root     512 Dec  6  2006 boot.0800
-rw-r--r-- 1 root root  308326 Mar 15 00:06 coffee.bmp
-rw-r--r-- 1 root root   34910 Nov  8 12:54 config-2.6.20.21-071108a
-rw-r--r-- 1 root root   35586 Feb 11 09:39 config-2.6.23.16-20080211a
lrwxrwxrwx 1 root root      15 Mar 14 23:26 debian.bmp -> /boot/sarge.bmp
-rw-r--r-- 1 root root  153720 Mar 15 00:06 debianlilo.bmp
drwx------ 2 root root   49152 Mar 14 23:26 lost+found
-rw------- 1 root root   72192 Mar 14 23:26 map
-rw-r--r-- 1 root root   94760 Mar 19  2006 memtest86+.bin
-rw-r--r-- 1 root root   23662 Mar 15 00:06 sarge.bmp
-rw-r--r-- 1 root root   24116 Mar 15 00:06 sid.bmp
-rw-r--r-- 1 root root 2875376 Nov  8 13:04 vmlinuz-2.6.20.21-071108a
-rw-r--r-- 1 root root 2687416 Feb 11 09:48 vmlinuz-2.6.23.16-20080211a
-rw-r--r-- 1 root root 2751960 Mar 31 23:39 vmlinuz-2.6.24.4

Eigentlich sollte doch von der 2.6.24.4 gebootet werden, oder?

Christian

[storm]

Eigentlich sollte doch von der 2.6.24.4 gebootet werden, oder?

Na, offensichtlich ist das nicht passiert. :) Hast du vielleicht lilo nach der Installation des neuen Kernels vergessen? Und selbst wenn es der 2.6.24.4 gewesen wäre, am ursprünglichen Problem ändert das auch nicht viel. Kuck dir lieber nochmal deine Hardware genauer an, teste die mal ausführlich unter harten Bedingungen, zB würd ich einen Speichertest und einen Stresstest des Raid-Systems vornehmen.

ciao, storm

[Schani]

Eigentlich sollte doch von der 2.6.24.4 gebootet werden, oder?

Na, offensichtlich ist das nicht passiert. Hast du vielleicht lilo nach der Installation des neuen Kernels vergessen? Und selbst wenn es der 2.6.24.4 gewesen wäre, am ursprünglichen Problem ändert das auch nicht viel. Kuck dir lieber nochmal deine Hardware genauer an, teste die mal ausführlich unter harten Bedingungen, zB würd ich einen Speichertest und einen Stresstest des Raid-Systems vornehmen.

ciao, storm

Was muss ich denn mit Lilo noch machen?
Kannst Du mir nen Tipp geben wie ich die Hardware einem Stresstest unterziehen kann?

Christian

[storm]

Was muss ich denn mit Lilo noch machen?

Das kommt drauf an, wie du den kernel gebaut hast: wenn du es nach debian-Art getan hast, sollte eigenlich nichts mehr zu tun sein. Dein Listing von /boot sieht auch so aus, allerdings fehlt in dieser Auflistung die config für den 2.6.24er. Was ich eigentlich meinte, ist, dass du bei der herkömmlichen Art den kernel zu bauen, nach dem Kopieren der erforderlichen Dateien, einmal als root lilo auf der Kommandozeile aufrufen musst. lilo schreibt dann einen neuen bootloader an die vorkonfigurierte Stelle und kann den kernel dann auch booten. Das kannst du auch nochmal machen, schaden kann es nicht.

Kannst Du mir nen Tipp geben wie ich die Hardware einem Stresstest unterziehen kann?

Backup machen, eventuell vom Netz abnabeln, dann tiobench oder bonnie++ drauf los lassen. Es gibt auch noch mehr Programme (apt-cache search stress test). Wichtig ist halt solche Tests mehrfach und in vielen Varianten laufen zu lassen und immer ein Auge auf's syslog zu richten. Aber versuch erstmal den neuen Kernel zu booten, vielleicht gibt sich dein Problem damit.

ciao, storm

[Schani]

Ja, jetzt hab ich den neuen Kernel am laufen. Auch einen Stresstest habe ich durchgeführt und der Kernel läuft ohne Fehler. Serverlast kurzeitig über 800 bei über 1000 Prozessen und keine einzige Fehlermeldung.

Jetzt muss er sich nur noch im täglichen Einsatz beweisen.

Besten Dank

Christian