• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Dump interpretieren

waldbaer59

Well-Known Member
Themenstarter #1
Hallo zusammen,

in der letzten Zeit habe ich auf einer neuen SSD ein FreeBSD aufgesetzt, und ich hatte das Gefühl, das System sei nun stabiler als beim ersten Versuch. Nun habe ich aber doch wieder einen Dump bekommen und überlege, auf was mich dieser hinweisen kann ...
Den Anfang des zugehörigen Text-Files zeige ich in der folgenden Code-Strecke; aber ich kann auch gerne die komplette Datei als Anhang an den Post binden, wenn es als nützlich / erforderlich betrachtet wird.

Im Moment bin ich froh, dass FreeBSD eher noch eine Spielwiese für mich ist, aber ich möchte schon gerne wenigstens mittelfristig ein FreeBSD als kleines Arbeitspferd für die 'gemeinen Dinge des Alltags' ;) betreiben.

Ideengeber gesucht ;) .

VLG
Stephan


Code:
Tue Apr 14 18:48:25 CEST 2020

FreeBSD HPTC_III 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x80
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff82df1b83
stack pointer           = 0x28:0xfffffe004b73b940
frame pointer           = 0x28:0xfffffe004b73b950
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 3
current process         = 869 (Xorg)
trap number             = 12
panic: page fault
cpuid = 1
time = 1586882805
KDB: stack backtrace:
#0 0xffffffff80c1d2f7 at kdb_backtrace+0x67
...
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#2
Code:
#0 0xffffffff80c1d2f7 at kdb_backtrace+0x67
...
Gib uns nochmal den kompletten Backtrace. :)
 

waldbaer59

Well-Known Member
Themenstarter #3
Okay, passiert hiermit und vielen Dank für die Reaktion. Sorry, aber ich bin gerade an einigen (Bau-) Stellen unterwegs und komme nicht kontinuierlich zum Computern ...
Ich habe nur einen bestimmten Namen überall mit "XXXXXX" ersetzt; ansonsten ist alles original.

VLG
Stephan
 

Anhänge

Yamagi

Possessed With Psi Powers
Mitarbeiter
#4
Hi,
alles gut. :) Da konntest du nicht wissen... Die Kurzfassung ist: Ich würde auf das radeonkms.ko Kernelmodul als Schuldigen tippen. Wirklich helfen kann ich dabei mangels aktueller Erfahrung mit Radeons unter FreeBSD nicht.

Der Backtrace ist:
Code:
#0  doadump () at src/sys/amd64/include/pcpu.h:234
234        __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD));
(kgdb) #0  doadump () at src/sys/amd64/include/pcpu.h:234
#1  0xffffffff80bd0228 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:451
#2  0xffffffff80bd0689 in vpanic (fmt=<value optimized out>, 
    ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:877
#3  0xffffffff80bd0483 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:804
#4  0xffffffff810a7dcc in trap_fatal (frame=<value optimized out>, 
    eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:943
#5  0xffffffff810a7e19 in trap_pfault (frame=0xfffffe004b73b880, usermode=0)
    at src/sys/amd64/include/pcpu.h:234
#6  0xffffffff810a740f in trap (frame=0xfffffe004b73b880)
    at /usr/src/sys/amd64/amd64/trap.c:443
#7  0xffffffff81081bdc in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:289
#8  0xffffffff82df1b83 in linux_cdev_pager_dtor (handle=<value optimized out>)
    at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:613
#9  0xffffffff80efc16e in dev_pager_dealloc (object=0xfffff8006eb6b500)
    at /usr/src/sys/vm/device_pager.c:263
#10 0xffffffff80f1ef85 in vm_object_terminate (object=0xfffff8006eb6b500)
    at /usr/src/sys/vm/vm_object.c:792
#11 0xffffffff80f1e319 in vm_object_deallocate (object=0x0)
    at /usr/src/sys/vm/vm_object.c:643
#12 0xffffffff80f11db5 in vm_map_process_deferred ()
    at /usr/src/sys/vm/vm_map.c:3426
#13 0xffffffff80f1bf89 in kern_munmap (td=<value optimized out>, 
    addr0=<value optimized out>, size=<value optimized out>)
    at /usr/src/sys/vm/vm_mmap.c:576
#14 0xffffffff810a8984 in amd64_syscall (td=0xfffff80011eb8000, traced=0)
    at src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#15 0xffffffff81082500 in fast_syscall_common ()
    at /usr/src/sys/amd64/amd64/exception.S:581  
#16 0x0000000800ce631a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Und der aktuelle Prozess:
Code:
current process        = 869 (Xorg)
Xorg springt über einen Syscall in den Kernel. Das sind Stack Frame 15 bis 14. Da der Kerneleinsprung erst in Frame 15 ist, ist es erstmal egal, dass Frame 16 korrupt ist. Das kann ein Problem sein oder nicht, ist hier aber auch erstmal nicht wichtig. Der Syscall-Handler ruft dann kern_munmap() auf, also war der Syscall wohl munmap(). Das VM-Objekt, was durch den Syscall entfernt werden soll, wird dann gesucht, auf der FreeBSD-Seite entfernt und am Ende geht es in den Linux KPI Wrapper, den das Radeon-Modul nutzt. Als der einen internen Destruktor -- linux_cdev_pager_dtor() -- aufruft, wirft die CPU eine Page Fault Exception. Das ist Stack Frame 7. Page Faults auf Kernel Speicher sind nicht möglich, weshalb das eine Fatal Trap ist. Der Kernel erkennt, dass er inkonsistent ist und schießt sich mit einem Aufruf von panic() ab.

Ursache ist sehr wahrscheinlich, wie oben schon gesagt, ein Bug in dem Bereich DRM und dem Linux KPI Wrapper. Weil es eine Radeon ist und die zumindest bei meinen letzten, allerdings schon fast ein Dreivierteljahr zurückliegenden Tests sehr wackelig waren, würde ich auf das radeonkms.ko Modul tippen. Vielleicht kann da jemand mit aktuelleren Erfahrungen mehr zu sagen.
 

waldbaer59

Well-Known Member
Themenstarter #5
Schade, dann kann ich nur hoffen dass sich die Situation in Bezug auf diese Grafik verbessert oder ich muss eine andere Karte (=billige Nvidia) in den Steckplatz des TC frickeln.
Da kost' mich die Korrektur der Grafik dann mehr als die gesamte Kiste....
Ich warte noch einige Zeit ab bevor ich etwas unternehme....
 

waldbaer59

Well-Known Member
Themenstarter #6
Nur als kleine Info zwischendrin: ich habe mir jetzt eine Nvidia Grafik in die Kiste befördert und hoffe, dass damit die Spontanreboots / Dumps Geschichte sind. Es wird sicher noch ein paar (wenige) Fragen brauchen bis alles komplett rund läuft und ich dann wieder damit anfangen kann, mir das System zu verbasteln ;) .

VLG
Stephan
 

mr44er

moderater Moderator
Mitarbeiter
#7
Nur nochmal zur gegenseitigen Absicherung:
Den Arbeitsspeicher hast du damals überprüft? Auch könnt ich mir vorstellen, dass es bei der Zuweisung von shared memory dynamic und fixed gibt. Letzteres wäre dann erfolgsversprechender, aber das ist IT, da hilft nur Unlogik. Falls ich das damals schon schrieb, ignorier' den Post. ;)

Ich tendiere auch zu radeonkms.ko, aber schau mal, ob du mit der nvidia uptime hinbekommst. Wenn ja, ist davon auszugehen, dass der Arbeitsspeicher ok ist.