TB

Ich habe mir im August letzten Jahres ein neues NAS gegönnt, diesmal eine Eigenkonstruktion, da das alte NAS von Thecus den Geist aufgegeben hatte (Netzteil defekt).
Das lief auch ganz prima, jedenfalls bis vor ein paar Tagen, da fing es an zu spinnen…

Ich habe als Hardware einen A4-6300 auf einem Asus F2A85-M Pro Mainboard verbaut. Die CPU hat einen integrierten Grafikchip, einen Radeon HD 8370D.
Das schien für den alten Kernel 3.2 zu modern zu sein, was ja auch nicht verwunderlich ist, der 3.2er ist von 2012 und die CPU von 2013.
Ich habe auf dem Gerät aber gar keinen X-Server installiert, daher fiel mir das bisher nicht auf und hat auch nicht gestört.
Und genau das scheint sich im Januar geändert zu haben. Der letzte Reboot wg. Kernel-Update war am 17.01., danach kam aber noch ein libc-Update dazu.
Meine Vermutung ist, das diese Kombination zu dem Fehler führte.

Es häuften sich jedenfalls Kernel-Oopse, die gab es zwar auch schon früher, ich habe sie aber nie bemerkt:

kernel: [29775.798315] BUG: unable to handle kernel paging request at 00000000000200e0
kernel: [29775.798384] IP: [] sysfs_find_dirent+0x5d/0xc5
kernel: [29775.798441] PGD 0
kernel: [29775.798462] Oops: 0000 [#1] SMP
kernel: [29775.798495] CPU 1
kernel: [29775.798512] Modules linked in: ext3 jbd tun sit tunnel4 softdog nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop snd_hda_codec_realtek snd_hda_codec_hdmi powernow_k8 mperf crc32c_intel eeepc_wmi asus_wmi sparse_keymap rfkill gh
ash_clmulni_intel radeon aesni_intel aes_x86_64 aes_generic cryptd pcspkr evdev wmi processor button thermal_sys ttm snd_hda_intel drm_kms_helper snd_hda_codec drm snd_hwdep power_supply snd_pcm i2c_algo_bit snd_page_alloc snd_timer i2c_piix4 snd i2c_core soundcore ext4
crc16 jbd2 mbcache dm_mod raid1 md_mod microcode usbhid hid sg sd_mod crc_t10dif usb_storage r8169 mii ohci_hcd ahci libahci libata xhci_hcd ehci_hcd scsi_mod usbcore usb_common [last unloaded: scsi_wait_scan]
kernel: [29775.799160]
kernel: [29775.799176] Pid: 14415, comm: lsmod Not tainted 3.2.0-4-amd64 #1 Debian 3.2.65-1+deb7u1 System manufacturer System Product Name/F2A85-M PRO
kernel: [29775.799282] RIP: 0010:[] [] sysfs_find_dirent+0x5d/0xc5
kernel: [29775.799354] RSP: 0018:ffff880058adbc78 EFLAGS: 00010206
kernel: [29775.799398] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
kernel: [29775.799455] RDX: ffff880005b89872 RSI: ffff880057aced40 RDI: ffff880005b89838
kernel: [29775.799513] RBP: 0000000000020100 R08: 0000000000000001 R09: ffff880058adbd68
kernel: [29775.799571] R10: ffff880005b898c0 R11: ffff880005b898c0 R12: ffff880005b89838
kernel: [29775.799628] R13: ffff880059122880 R14: ffff880056d83ec0 R15: 0000000000000000
kernel: [29775.799687] FS: 00007f3bfe2f5700(0000) GS:ffff88005da80000(0000) knlGS:0000000000000000
kernel: [29775.799752] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [29775.799799] CR2: 00000000000200e0 CR3: 000000004b6f7000 CR4: 00000000000406e0
kernel: [29775.799856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: [29775.799914] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
kernel: [29775.799972] Process lsmod (pid: 14415, threadinfo ffff880058ada000, task ffff880052c2f140)
kernel: [29775.800005] Stack:
kernel: [29775.800005] ffff880005b898c0 ffff880005b89800 ffff880056889050 fffffffffffffffe
kernel: [29775.800005] ffff880005b898c0 ffffffff811510ed ffff880005b89960 ffff880005b89800
kernel: [29775.800005] ffff880056889050 ffff880058adbe78 ffff880005b898c0 ffffffff81103392
kernel: [29775.800005] Call Trace:
kernel: [29775.800005] [] ? sysfs_lookup+0x4b/0xd4
kernel: [29775.800005] [] ? d_alloc_and_lookup+0x3a/0x60
kernel: [29775.800005] [] ? walk_component+0x219/0x406
kernel: [29775.800005] [] ? do_last+0x108/0x58d
kernel: [29775.800005] [] ? path_openat+0xce/0x33a
kernel: [29775.800005] [] ? tlb_flush_mmu+0x37/0x50
kernel: [29775.800005] [] ? tlb_finish_mmu+0xc/0x31
kernel: [29775.800005] [] ? do_filp_open+0x2a/0x6e
kernel: [29775.800005] [] ? _cond_resched+0x7/0x1c
kernel: [29775.800005] [] ? __strncpy_from_user+0x18/0x48
kernel: [29775.800005] [] ? alloc_fd+0x64/0x109
kernel: [29775.800005] [] ? do_sys_open+0x5e/0xe5
kernel: [29775.800005] [] ? system_call_fastpath+0x16/0x1b
kernel: [29775.800005] Code: 81 48 c7 c0 99 57 4f 81 4d 89 e1 48 c7 c2 77 f5 4d 81 48 0f 44 c8 be 3e 02 00 00 48 c7 c7 47 f5 4d 81 31 c0 e8 90 5d ef ff eb 5a 8b 75 e0 4c 89 e7 e8 1c 03 06 00 83 f8 00 7c 0c 74 06 48 8b
kernel: [29775.800005] RIP [] sysfs_find_dirent+0x5d/0xc5
kernel: [29775.800005] RSP
kernel: [29775.800005] CR2: 00000000000200e0
kernel: [29775.879136] ---[ end trace 68c2d1c32b51fd5c ]---

Das trat schon beim Boot auf, das System lief aber recht normal weiter… nur das udev durchdrehte!
Und das war wirklich ein Problem, denn es wurden immer mehr Prozesse gespawnt und blieben dann einfach so hängen:

udevd[436]: timeout: killing '/sbin/modprobe -b pci:v00001002d00009998sv00001043sd00008526bc03sc00i00' [492]

Das System war dadurch nicht mehr erreichbar, es hatte einen Load von um die 80 herrum und lief auf Volllast:

Das Device das da geladen werden sollte war genau der Grafik-Chip. Entsprechend war der auch nicht geladen.
Allerdings ließen sich die udev-Prozesse nicht beenden, einzig ein Restart von udev hat Abhilfe gebracht, dabei blieb aber mindestens ein solcher Prozess hängen und der Load ging nicht unter 1. Also keine befriedigende Lösung.

Im Internet lässt sich zu dieser Konstellation auch nicht wirklich was finden, bzw. nur wenig.
Was ich gefunden habe deutete eben darauf hin, das der 3.2er ausgetauscht gehört.
Also habe ich Debian-Backports mit in die sources.list aufgenommen und den 3.16er Kernel installiert und das Problem war weg.
Außerdem wird jetzt das passende Kernel-Modul geladen:

00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 9998
        Subsystem: ASUSTeK Computer Inc. Device 8526
        Kernel driver in use: radeon

Ich vermute, dass mir das schon früher aufgefallen wäre, hätte ich da ein Linux mit X-Server installiert. Aber man sieht hier wieder schön, wie stabil Linux eigentlich ist.
Trotz das der Grafikchip nicht funktioniert läuft das System (fast) problemlos und kann benutzt werden. Und wenn dann doch Probleme auftreten sind diese behebbar, ohne das
man hier gleich alles auf den Kopf stellen muss. Nicht wie bei Windows, wo der Austausch von Motherboard + Prozessor zu einem unbenutzbaren, kaputten System führt, das nicht mehr bootet und sich auch nicht selber reparieren mag… aber das ist eine andere Geschichte. 😉

P.S. Der Beitrag ist hauptsächlich für Leute gedacht die eine Lösung für solche Probleme suchen, wie gesagt, man findet wenig dazu. 😉

---

Filed under: Linux - @ 12.02.2015 14:24

Schlagwörter: AMD, Asus, Debian, Hardware, Kernel, Kernel Oops, load, SysAdm, udev