FreeBSD 13.1 und 13.2 crashed unter 2 Bedingungen - wie den Übeltäter finden

[serie300]

Hallo

Auf meinem neuen Rechner kommt es unter 2 Bedingungen zu Kernel Crashes (Maschine bootet durch und schreibt crash-log).
1. Nach ein paar Minuten Internet surfen mit iridium-browser (ziemlich zuverlässig, nicht an eine Webseite gebunden)
2. Beim Booten der Maschine (ab und zu, gefühlt jedes 5. mal).
Würde also erstmal raten Grafiktreiber (amdgpu) oder Netzwerktreiber.
Ich habe ein bisschen den [ realtek-re-kmod ] aus den Ports im Verdacht, den ich für den boardeigenen RT8125 2.5GB Netzwerk Chip brauche. Der taucht dann auch in /var/crash/core.txt auf.

#6  0xffffffff810b1fff in trap_pfault (frame=0xfffffe00c4556c80,
    usermode=false, signo=<optimized out>, ucode=<optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:761
#7  <signal handler called>
#8  ether_input (ifp=<optimized out>, m=0xffff)
    at /usr/src/sys/net/if_ethersubr.c:818
#9  0xffffffff8272e4ed in re_rxeof () from /boot/modules/if_re.ko
#10 0xffffffff82721f4a in re_int_task_8125 () from /boot/modules/if_re.ko
#11 0xffffffff80c68961 in taskqueue_run_locked (queue=0xfffff800020f30e0,
    queue@entry=0xfffff800020f0400) at /usr/src/sys/kern/subr_taskqueue.c:514
#12 0xffffffff80c69c23 in taskqueue_thread_loop (
    arg=arg@entry=0xfffffe00c434d238)
    at /usr/src/sys/kern/subr_taskqueue.c:826
#13 0xffffffff80bc2fce in fork_exit (

1) Wie kann ich vor einem PR an den Maintainer des realtek-re-kmod sicherstellen, daß der tatsächlich der Übeltäter ist?
2) Was müßte dann in den PR schreiben, um beim debugging zu helfen ?
Board ist ein Asus TUF B550M-Plus Wifi II. Btw: Ich bezweifle, daß ich den boardeigenen Mediatek WLAN Controller unter FreeBSD zum Laufen bekomme, um so mit einem anderen Netzwerk Adapter zu probieren; USB-Ethernet Adapter müßte ich erst besorgen.

Serie300

 

[waldbaer59]

Bei meinem HP-Thin-Client kam es bei der Nutzung von amdgpu unregelmäßig, aber lastabhängig zu spontanen Reboots. Daher habe ich statt der On-Board-Grafik nun eine Nvidia GT710 in der Nutzung. Seitdem habe ich keine solchen Probleme mehr.
Ich tippe also auf ein Fehlverhalten von amdgpu.

VLG
Stephan

 

[mr44er]

Im Port dazu steht:

By default, the size of allocated mbufs is enough to receive the largest Ethernet frame supported by the card. If your memory is highly fragmented, trying to allocate contiguous pages (more than 4096 bytes) may result in driver hangs. For this reason the value is tunable at boot time, e.g. if you don't need Jumbo frames you can lower the memory requirements and avoid this issue with: hw.re.max_rx_mbuf_sz="2048"

Probier mal jeweils das Gegenteil wie du es hast, also mit und ohne diesem Eintrag.

 

[Yamagi]

Der taucht dann auch in /var/crash/core.txt auf.

Die entscheidende Frage ist, ob es reproduzierbar ist. Das Problem mit Speicherkorruption ist, dass sie den Kernel an jeder Stelle zum Absturz bringen kann. Wenn man also bei jedem Crash einen anderen Backtrace bekommt, hat man Speicherkorruption irgendwo im Kernel. Wenn es immer der gleiche oder zumindest ein ähnlicher Backtrace ist, wäre wohl tatsächlich realtek-re-kmod schuld.