Kernel BUG: unable to handle kernel paging request at 000000040000001c

Deutsch (German) Installation/Administration
1

Hallo,

seit geraumer Zeit friert Leap 42.3 unregelmäßig, aber komplett ein (Caps Lock + Scroll Lock blinkt = Kernel panic) und benötigt einen harten reboot = Netzschalter. Jeder Absturz beginnt mit einer Kernel Bug Warnung an Adresse **000000040000001c. **Das ganze ended schließlich in hunderten von “attempt to access beyond end of device” HDD-Fehlermeldungen bis der Punkt des totalen Einfrierens erreicht ist. Ich bin nicht mehr so fit mit Kernel Problemen, da ich vor Leap, schlichtweg lange keine hatte.

Ich habe alle letzten “offiziellen” Kernel Updates mitgenommen, in der Hoffnung das Problem zeitraubender Analysen zu umgehen, aber mit dem letzten 4.4.114-42-default hat sich die Frequenz der Abstürze derartig erhöht, dass normales Arbeiten nicht mehr möglich ist. Es handelt sich um eine Rechenmaschine die eigentlich 24/7 läuft. In der Vergangenheit waren es nur ~1-2 Crashs pro Woche, was ich im Moment verkraften kann. Leider kann ich nicht mehr rekonstruieren, welche Kernel Variante weniger oft crashte. Ich weiß, dass 4.4.xxx ein sehr alter Kernel ist, aber ich habe schlicht keine Zeit mehr für Tumbleweed auf einer Rechenmaschine die Ergebnisse liefern muss, und bis Leap 15 sind es noch 3 Monate. Hat jemand eine Idee, wo das Problem liegt?

Danke im Voraus!

/var/log/messages:

2018-03-07T18:38:45.024046-05:00 kernel: 5971.350668] BUG: unable to handle kernel paging request at 000000040000001c
2018-03-07T18:38:45.024066-05:00 kernel: 5971.351626] IP: <ffffffff81199f25>] find_get_entry+0x35/0xa0
2018-03-07T18:38:45.024068-05:00 kernel: 5971.352566] PGD 8000001fa5489067 PUD 0
2018-03-07T18:38:45.024069-05:00 kernel: 5971.353500] Oops: 0000 #1] SMP
2018-03-07T18:38:45.024070-05:00 kernel: 5971.354433] Modules linked in: fuse af_packet iscsi_ibft iscsi_boot_sysfs msr snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_rapl edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel drbg snd_hda_codec ansi_cprng snd_hda_core snd_hwdep snd_pcm aesni_intel aes_x86_64 lrw nls_iso8859_1 gf128mul glue_helper mei_me snd_timer ablk_helper nls_cp437 vfat usblp fat snd iTCO_wdt xfs iTCO_vendor_support e1000e cryptd libcrc32c pcspkr i2c_i801 lpc_ich soundcore ptp mfd_core mei pps_core shpchp fjes tpm_infineon processor btrfs xor raid6_pq hid_generic usbhid sd_mod nvidia_drm(PO) nvidia_modeset(PO) mxm_wmi nvidia_uvm(PO) nvidia(PO) crc32c_intel serio_raw ipmi_msghandler ahci libahci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci ehci_pci libata xhci_hcd ehci_hcd drm usbcore usb_common nvme nvme_core wmi button sg scsi_mod efivarfs autofs4
2018-03-07T18:38:45.024071-05:00 kernel: 5971.362132] CPU: 2 PID: 3865 Comm: flirt Tainted: P O 4.4.114-42-default #1
2018-03-07T18:38:45.024072-05:00 kernel: 5971.363079] Hardware name: Gigabyte Technology Co., Ltd. Default string/X99P-SLI-CF, BIOS F25a 01/11/2018
2018-03-07T18:38:45.024073-05:00 kernel: 5971.364028] task: ffff881fccc68940 ti: ffff881fa863c000 task.ti: ffff881fa863c000
2018-03-07T18:38:45.024074-05:00 kernel: 5971.364987] RIP: 0010:<ffffffff81199f25>] <ffffffff81199f25>] find_get_entry+0x35/0xa0
2018-03-07T18:38:45.024075-05:00 kernel: 5971.365940] RSP: 0018:ffff881fa863fc70 EFLAGS: 00010246
2018-03-07T18:38:45.024076-05:00 kernel: 5971.366874] RAX: ffff880f47ad1af8 RBX: ffff881d98be5740 RCX: 00000000fffffffa
2018-03-07T18:38:45.024077-05:00 kernel: 5971.367800] RDX: 0000000400000000 RSI: 00000000000b1a39 RDI: ffff880f47ad1af0
2018-03-07T18:38:45.024078-05:00 kernel: 5971.368728] RBP: 00000000000b1a39 R08: 0000000000000000 R09: ffff880f47ad1af8
2018-03-07T18:38:45.024079-05:00 kernel: 5971.369654] R10: ffff880f47ad1af8 R11: ffff881fa863fc60 R12: ffff881d98be5738
2018-03-07T18:38:45.024080-05:00 kernel: 5971.370564] R13: ffff881d98be5738 R14: 00000000000b1a39 R15: ffffffffa174a8a0
2018-03-07T18:38:45.024081-05:00 kernel: 5971.371459] FS: 00007efe12c37740(0000) GS:ffff881fcf480000(0000) knlGS:0000000000000000
2018-03-07T18:38:45.024082-05:00 kernel: 5971.372346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2018-03-07T18:38:45.024083-05:00 kernel: 5971.373230] CR2: 000000040000001c CR3: 0000001f83f88000 CR4: 0000000000160670
2018-03-07T18:38:45.024084-05:00 kernel: 5971.374110] Stack:
2018-03-07T18:38:45.024085-05:00 kernel: 5971.374966] 000000000000000f 000000000142004a ffffffff8119b0d6 00000000b1a38000
2018-03-07T18:38:45.024086-05:00 kernel: 5971.375826] 00000000b1a39000 00000000b1a39000 ffff881d98be5738 0000000000001000
2018-03-07T18:38:45.024087-05:00 kernel: 5971.376668] ffff881fa863fd48 ffffffff8119b292 00000000b1a39000 ffffffffa1703501
2018-03-07T18:38:45.024088-05:00 kernel: 5971.377501] Call Trace:
2018-03-07T18:38:45.024089-05:00 kernel: 5971.378320] <ffffffff8119b0d6>] pagecache_get_page+0x26/0x1c0
2018-03-07T18:38:45.024090-05:00 kernel: 5971.379150] <ffffffff8119b292>] grab_cache_page_write_begin+0x22/0x40
2018-03-07T18:38:45.024091-05:00 kernel: 5971.379986] <ffffffffa1703501>] xfs_vm_write_begin+0x31/0xd0 [xfs]
2018-03-07T18:38:45.024092-05:00 kernel: 5971.380793] <ffffffff8119a0c5>] generic_perform_write+0xc5/0x1c0
2018-03-07T18:38:45.024093-05:00 kernel: 5971.381588] <ffffffffa1711ee0>] xfs_file_buffered_aio_write+0x110/0x260 [xfs]
2018-03-07T18:38:45.024094-05:00 kernel: 5971.382387] <ffffffffa171210a>] xfs_file_write_iter+0xda/0x1e0 [xfs]
2018-03-07T18:38:45.024095-05:00 kernel: 5971.383179] <ffffffff81214b70>] __vfs_write+0xd0/0x140
2018-03-07T18:38:45.024096-05:00 kernel: 5971.383949] <ffffffff8121584f>] vfs_write+0xaf/0x1d0
2018-03-07T18:38:45.024115-05:00 kernel: 5971.384700] <ffffffff812168f2>] SyS_write+0x42/0xa0
2018-03-07T18:38:45.024116-05:00 kernel: 5971.385432] <ffffffff8163e3ce>] entry_SYSCALL_64_fastpath+0x22/0xba
2018-03-07T18:38:45.024117-05:00 kernel: 5971.387699] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x22/0xba
2018-03-07T18:38:45.024118-05:00 kernel: 5971.388431]
2018-03-07T18:38:45.024119-05:00 kernel: 5971.389141] Leftover inexact backtrace:
2018-03-07T18:38:45.024120-05:00 kernel: 5971.389141]
2018-03-07T18:38:45.024122-05:00 kernel: 5971.390518] Code: ff 05 18 46 e7 7e 53 48 8d 5f 08 48 89 ee 48 89 df e8 f0 db 1a 00 48 85 c0 49 89 c1 74 3b 48 8b 10 48 85 d2 74 26 f6 c2 03 75 4c <8b> 4a 1c 85 c9 74 d9 8d 71 01 48 8d 7a 1c 89 c8 f0 0f b1 72 1c
2018-03-07T18:38:45.024123-05:00 kernel: 5971.391967] RIP <ffffffff81199f25>] find_get_entry+0x35/0xa0
2018-03-07T18:38:45.024124-05:00 kernel: 5971.392658] RSP <ffff881fa863fc70>
2018-03-07T18:38:45.024125-05:00 kernel: 5971.393329] CR2: 000000040000001c
2018-03-07T18:38:45.024126-05:00 kernel: 5971.395187] — end trace 154c87c3e89ac748 ]—
2018-03-07T18:38:45.024127-05:00 kernel: 5971.395856] BUG: sleeping function called from invalid context at …/include/linux/sched.h:2901
2018-03-07T18:38:45.024128-05:00 kernel: 5971.396544] in_atomic(): 1, irqs_disabled(): 1, pid: 3865, name: flirt
2018-03-07T18:38:45.024129-05:00 kernel: 5971.397221] CPU: 2 PID: 3865 Comm: flirt Tainted: P D O 4.4.114-42-default #1
2018-03-07T18:38:45.024130-05:00 kernel: 5971.397891] Hardware name: Gigabyte Technology Co., Ltd. Default string/X99P-SLI-CF, BIOS F25a 01/11/2018
2018-03-07T18:38:45.024131-05:00 kernel: 5971.398558] 0000000000000000 ffffffff813420b7 ffff881fccc68940 0000000000000f19
2018-03-07T18:38:45.024132-05:00 kernel: 5971.399223] ffffffff81093061 0000000000000046 0000000000000009 0000000000000f19
2018-03-07T18:38:45.024133-05:00 kernel: 5971.399872] ffffffff81085fc1 ffffffff00000000 0000000000000010 ffff881fa863fac0
2018-03-07T18:38:45.024134-05:00 kernel: 5971.400500] Call Trace:
2018-03-07T18:38:45.024135-05:00 kernel: 5971.401109] <ffffffff8101b0f9>] dump_trace+0x59/0x350
2018-03-07T18:38:45.024136-05:00 kernel: 5971.401705] <ffffffff8101b4ea>] show_stack_log_lvl+0xfa/0x180
2018-03-07T18:38:45.024137-05:00 kernel: 5971.402296] <ffffffff8101c2b1>] show_stack+0x21/0x40
2018-03-07T18:38:45.024138-05:00 kernel: 5971.402871] <ffffffff813420b7>] dump_stack+0x5c/0x85
2018-03-07T18:38:45.024139-05:00 kernel: 5971.403435] <ffffffff81093061>] exit_signals+0x21/0x130
2018-03-07T18:38:45.024140-05:00 kernel: 5971.403987] <ffffffff81085fc1>] do_exit+0xb1/0xb70
2018-03-07T18:38:45.024141-05:00 kernel: 5971.404531] <ffffffff8101bbac>] oops_end+0x9c/0xd0
2018-03-07T18:38:45.024143-05:00 kernel: 5971.405068] <ffffffff81068e97>] no_context+0x107/0x370
2018-03-07T18:38:45.024144-05:00 kernel: 5971.405600] <ffffffff81069984>] __do_page_fault+0x84/0x4e0
2018-03-07T18:38:45.024145-05:00 kernel: 5971.406135] <ffffffff81069e0b>] do_page_fault+0x2b/0x70
2018-03-07T18:38:45.024146-05:00 kernel: 5971.406666] <ffffffff81640f38>] page_fault+0x28/0x30
2018-03-07T18:38:45.024147-05:00 kernel: 5971.408710] DWARF2 unwinder stuck at page_fault+0x28/0x30
2018-03-07T18:38:45.024148-05:00 kernel: 5971.409232]
2018-03-07T18:38:45.024149-05:00 kernel: 5971.409740] Leftover inexact backtrace:
2018-03-07T18:38:45.024150-05:00 kernel: 5971.409740]
2018-03-07T18:38:45.024151-05:00 kernel: 5971.410741] <ffffffff81199f25>] ? find_get_entry+0x35/0xa0
2018-03-07T18:38:45.024152-05:00 kernel: 5971.411243] <ffffffff8119b0d6>] ? pagecache_get_page+0x26/0x1c0
2018-03-07T18:38:45.024153-05:00 kernel: 5971.411745] <ffffffff8119b292>] ? grab_cache_page_write_begin+0x22/0x40
2018-03-07T18:38:45.024154-05:00 kernel: 5971.412254] <ffffffffa1703501>] ? xfs_vm_write_begin+0x31/0xd0 [xfs]
2018-03-07T18:38:45.024156-05:00 kernel: 5971.412749] <ffffffff8119a0c5>] ? generic_perform_write+0xc5/0x1c0
2018-03-07T18:38:45.024157-05:00 kernel: 5971.413241] <ffffffff8163bdbc>] ? down_write+0x1c/0x50
2018-03-07T18:38:45.024158-05:00 kernel: 5971.413740] <ffffffffa1711ee0>] ? xfs_file_buffered_aio_write+0x110/0x260 [xfs]
2018-03-07T18:38:45.024159-05:00 kernel: 5971.414247] <ffffffffa171210a>] ? xfs_file_write_iter+0xda/0x1e0 [xfs]
2018-03-07T18:38:45.024160-05:00 kernel: 5971.414744] <ffffffff81214b70>] ? __vfs_write+0xd0/0x140
2018-03-07T18:38:45.024161-05:00 kernel: 5971.415235] <ffffffff8121584f>] ? vfs_write+0xaf/0x1d0
2018-03-07T18:38:45.024162-05:00 kernel: 5971.415721] <ffffffff812168f2>] ? SyS_write+0x42/0xa0
2018-03-07T18:38:45.024163-05:00 kernel: 5971.416203] <ffffffff8163e3ce>] ? entry_SYSCALL_64_fastpath+0x22/0xba

2

Folgendes: in das Systemd Journal ist: “Modules linked in:” – ‘intel’ (verschiedenes); ‘btrfs’; ‘nvidia’ (verschiedenes).
Also, das System ist mit eine Intel CPU, NVidia Grafikkarte und, Btrfs (System Partition?) ausgerüstet.

Wegen Btrfs, folgendes Rezept ausführen:

  • Entweder, wegen eine fehlende System Boot (Emergency Mode) oder, manuell von TTY CLI (mit der Benutzer ‘root’) “systemctl rescue”, das Passwort der Benutzer “root” eingeben und, alle Btrfs Skripten in “/etc/cron.weekly/” und “/etc/cron.monthly/” ausführen. Wenn das Btrfs Hausputz und kehren fertig ist, neu booten.

Vorsicht! Es kann eine Weile dauern – bis 24 Stunden …

Intel CPU und NVidia Grafikkarte: ein Dauerthema in dieses Forum; bin selber ein AMD (pur) Fanatiker – bitte warten bis Anderer zu das Thema “NVidia” antworten.

3

Danke für die Antwort.

Ich kann NVIDIA/Intel/btrfs nur zustimmen. Das ist auch mein erster und evt. letzter Versuch mit NVIDIA. Cuda macht eine einfache Programmierung nur leichter (unwesentlich - angesichts all der Treiber Probleme) und daher habe ich mich vor 2 Jahren “mal” überreden lassen, auf einer meiner Rechenmachinen die Seiten zu wechseln. Eine zeitlang hatten die NVIDIA Treiber einen guten Ruf und man kann auch beliebig viel Zeit mit AMD Grafikkarten zubringen, obwohl das definitiv einfacher geworden ist.

Woran erkennt man, dass der Bug mit btrfs zusammenhängt? Ich habe zwar oft mit btrfs an anderer Stelle zu kämpfen, aber die HDD errors hier nachdem der pointer Fehler auftritt, erscheinen bezüglich einer anderen HDD mit XFS. Einmal hat der Bug die Partitionstabelle beschädigt, aber alle disk checks laufen fehlerfrei durch, d.h. ich würde ein Hardware Problem dort im Moment noch ausschließen. Die btrfs disk ist eigentlich immer recht gut balanced. Das System bootet problemlos, bleibt halt nur alle paar Stunden einfach stehen. Das ist nervig wenn man lange Simulationen laufen hat.

Grüße.

4

Gar nicht.
Er hängt nämlich mit xfs zusammen, würd ich sagen…

2018-03-07T18:38:45.024088-05:00 kernel:  5971.377501] Call Trace:
2018-03-07T18:38:45.024089-05:00 kernel:  5971.378320] <ffffffff8119b0d6>] pagecache_get_page+0x26/0x1c0
2018-03-07T18:38:45.024090-05:00 kernel:  5971.379150] <ffffffff8119b292>] grab_cache_page_write_begin+0x22/0x40
2018-03-07T18:38:45.024091-05:00 kernel:  5971.379986] <ffffffffa1703501>] xfs_vm_write_begin+0x31/0xd0 [xfs]
2018-03-07T18:38:45.024092-05:00 kernel:  5971.380793] <ffffffff8119a0c5>] generic_perform_write+0xc5/0x1c0
2018-03-07T18:38:45.024093-05:00 kernel:  5971.381588] <ffffffffa1711ee0>] xfs_file_buffered_aio_write+0x110/0x260 [xfs]
2018-03-07T18:38:45.024094-05:00 kernel:  5971.382387] <ffffffffa171210a>] xfs_file_write_iter+0xda/0x1e0 [xfs]
2018-03-07T18:38:45.024095-05:00 kernel:  5971.383179] <ffffffff81214b70>] __vfs_write+0xd0/0x140
2018-03-07T18:38:45.024096-05:00 kernel:  5971.383949] <ffffffff8121584f>] vfs_write+0xaf/0x1d0
2018-03-07T18:38:45.024115-05:00 kernel:  5971.384700] <ffffffff812168f2>] SyS_write+0x42/0xa0
2018-03-07T18:38:45.024116-05:00 kernel:  5971.385432] <ffffffff8163e3ce>] entry_SYSCALL_64_fastpath+0x22/0xba

Keine Ahnung was man da tun kann (außer einen Bugreport schreiben), da ich XFS nicht verwende.
Evtl. würd ein Filesystemcheck helfen?

5

Danke für Deinen Beitrag. Ab und an, aber sehr selten, muss ich das Filesystem nach dem crash reparieren. Im wesentlichen Inodes aufräumen und 3x wurde die Partitionstabelle irgendeiner Platte beschädigt (letzteres war auf verschiedenen Festplatten mit btrfs oder XFS). Es kommt darauf an in welcher Phase der Crash auftritt, i.e. welche Disk Operationen gerade liefen. Daher war meine Vermutung, dass die Ursache anderswo liegt und die HDD einfach nur in Folge mitgenommen wird.

6

So, ja, nicht das Systempartition aber, doch eine XFS Benutzerpartition, der sich einwandfrei reparieren lässt …

  • Hinweise beim S.M.A.R.T.?
  • Mutterplatine BIOS ist neu (2018).
  • Anwendung? – Simulation kommt mit Datenströme zu und/oder von Dateien in das XFS Partition nicht zu recht?

Folgende ZFS Problem: <Issues · openzfs/zfs · GitHub.
Möglicherweise ist es doch eine vergleichbare XFS Fehler.

7
  • SMART zeigt keinerlei Probleme, ich musste aber anfang letzter Woche die Partitionstabelle manuell wiederherstellen, nachdem diese durch einen der Crashs beschädigt wurde und das Laufwerk sich nicht mehr mounten ließ.
  • BIOS ist auf neustem Stand – gerade vorgestern wieder geflashed in der Hoffnung, dass es mit CPU/RAM zusammenhängt. Ich reize alle cores und die 128GB RAM voll aus, daher ist das System sicher unter mehr Last als bei 95% der normalen Anwender.
  • Anwendung ist custom-made und einige off-the-shelf image processing tools mit harten Lese/Schreib Operationen, d.h. wenn alles laufen würde (tut es auf meiner älteren Maschine mit OpenSuse 13.2, Kernel 3.16.7-53-desktop und auch mit btrfs/XFS disks – leider zu wenig RAM für ein Unterprogramm und natürlich viel langsamer), erwarte ich einige TerraByte Traffic am Tag.

Ich vermute bereits länger, dass es mit den Datenströmen zusammenhängen kann, denn während die Skripte laufen, kommt es wesentlich häufiger zur Kernel Panic. ABER: das System crashed auch ohne Last (Simulation/Processing läuft nicht) mit dem selben Address-Code; dann sind die Abstürze aber wieder auf 1-2/Tag runter. Die letzten Monate hatte ich immer auf die NVIDIA Karte (980Ti) getippt, aber die XServer logs und verschiedenen System logs geben keinen Hinweis auf NVIDIA.

Ich habe allerdings auch einige vereinzelte, eigenartige Warnungen zu blue-z (kein Bluetooth Gerät/Dongle angeschlossen) und, was mich mehr besorgt, zur swap Partition (swapon failed: invalid argument; Failed to activate swap /dev/…). Die swap partition scheint o.k., aber sie liegt auch auf der XFS Platte die under den harten Lese/Schreibvorgängen leidet. Ich wollte mal versuchen eine andere zu definieren und schauen, ob das hilft.

8

Oder, eine Prüfumgebung implementieren – Master Prozess – mehrere Kind-Prozessen die E/A simultan über die Prozessor-Kerne verteilt erledigen …

Muss nachschauen – irgendwie duftet es von Anwendung E/A Warteschlangen die der Dateisystem E/A überlasten; vielleicht ein Problem mit die “Feature Test Macros” – persönlich bin ich mit die Dinge sehr pingelig …
GCC “Warning options”? – “-Wall” & Co.

9

Ganz blöde bedenken: ist der Platte eine SSHD?
Zum Beispiel: Seagate FireCuda ST1000LX015 Handbuch:
Rated Workload:

Average annualized workload rating: <55 TB/year.
The specifications for the product assumes the I/O workload does not exceed the average annualized workload rate limit of 55 TB/year. Workloads exceeding the annualized rate may degrade and impact reliability as experienced by the particular application. The average annualized workload rate limit is in units of TB per calendar year.

10

Gegeben, viel E/A:

  • YaST: Kernel-Einstellungen: “Globaler E/A-Planer”:

“Völlig faire Warteschlange” [cfq];
“NOOP”;
“Frist” [deadline].
Weiter lesen und einregeln mit <https://doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/cha.tuning.io.html>.