Weird crash, need ideas.

astyle

astyle

I have a Lenovo Ideapad 720s-13ARR (Ryzen 5 2500U, 8GB of RAM). I managed to install FreeBSD 13.1-RELEASE on it, but had a weird crash this morning.

Running KDE Plasma 5.24.5, KF5 5.101, Xorg, just about everything is compiled from a ports tarball from Jan. 17.

Code: 
# uname -a
FreeBSD ideapad.localdomain 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64

I had Konqueror open, with quite a few tabs. Printed one tab to PDF, successfully. Wanted to open it in a PDF viewer. LibreOffice started up - and after that, the screen just turned off.

And now, for the weird behavior. I can SSH in, run su root, and kill some processes, and umount external USB sticks. A (pre-crash, this is important) listing from # kldstat yielded the following:
Code: 
# kldstat
Id Refs Address                Size Name
 1  143 0xffffffff80200000  1f30590 kernel
 2    1 0xffffffff82131000     a158 cryptodev.ko
 3    1 0xffffffff8213d000   5b93a0 zfs.ko
 4    1 0xffffffff832f9000     3530 fdescfs.ko
 5    1 0xffffffff83400000   417220 amdgpu.ko
 6    2 0xffffffff832fd000    739e0 drm.ko
 7    3 0xffffffff83371000     5220 linuxkpi_gplv2.ko
 8    4 0xffffffff83377000     62d8 dmabuf.ko
 9    1 0xffffffff8337e000     c758 ttm.ko
10    1 0xffffffff8338b000     2218 amdgpu_raven_gpu_info_bin.ko
11    1 0xffffffff8338e000     64d8 amdgpu_raven_sdma_bin.ko
12    1 0xffffffff83395000    2a2d8 amdgpu_raven_asd_bin.ko
13    1 0xffffffff833c0000     a3d8 amdgpu_raven_ta_bin.ko
14    1 0xffffffff833cb000     7558 amdgpu_raven_pfp_bin.ko
15    1 0xffffffff833d3000     6558 amdgpu_raven_me_bin.ko
16    1 0xffffffff833da000     4558 amdgpu_raven_ce_bin.ko
17    1 0xffffffff833df000     b9c0 amdgpu_raven_rlc_bin.ko
18    1 0xffffffff83818000    437e8 amdgpu_raven_mec_bin.ko
19    1 0xffffffff8385c000    437e8 amdgpu_raven_mec2_bin.ko
20    1 0xffffffff838a0000    5b438 amdgpu_raven_vcn_bin.ko
21    1 0xffffffff833eb000    11cd8 fusefs.ko
22    1 0xffffffff838fc000     3378 acpi_wmi.ko
23    1 0xffffffff83900000    87098 if_iwlwifi.ko
24    1 0xffffffff83988000    17310 if_iwm.ko
25    1 0xffffffff839a0000     3218 intpm.ko
26    1 0xffffffff833fd000     2180 smbus.ko
27    1 0xffffffff839a4000   1bc6e8 iwm8265fw.ko
28    1 0xffffffff83b61000     2340 uhid.ko
29    1 0xffffffff83b64000     4350 ums.ko
30    1 0xffffffff83b69000     3380 usbhid.ko
31    1 0xffffffff83b6d000     31f8 hidbus.ko
32    1 0xffffffff83b71000     4d00 ng_ubt.ko
33    3 0xffffffff83b76000     aac8 netgraph.ko
34    2 0xffffffff83b81000     a238 ng_hci.ko
35    2 0xffffffff83b8c000     25a8 ng_bluetooth.ko
36    1 0xffffffff83b8f000    38070 linux.ko
37    4 0xffffffff83bc8000    10ab0 linux_common.ko
38    1 0xffffffff83bd9000    32208 linux64.ko
39    1 0xffffffff83c0c000     2260 pty.ko
40    1 0xffffffff83c0f000     639c linprocfs.ko
41    1 0xffffffff83c16000     3284 linsysfs.ko
42    1 0xffffffff83c1a000     6730 cuse.ko

After the crash, my first thought was to re-load amdgpu.ko and related modules. Aaannnnd.... # kldunload hung and would not do anything. I started another SSH session, and used /bin/kill to stop the hung # kldunload command. That did terminate the process, but the pty session (where the doomed kldunload was running) was rendered unusable, as in, I type a command, press enter, and cursor jumps, but nothing else happens.

I think this can be resolved by just rebooting the machine. BUT... I'm hoping that my description of the issue rings a bell for someone who can suggest some kind of troubleshooting for me. Basically, what can I do when kernel modules don't load/unload properly? Is there a RAM issue? or some sysctl that needs to be adjusted?

If there are any further questions, please ask away!
 
I don't think every kernel module can be unloaded, particularly complex modules. amdgpu.ko may be one of them. The reason is that before unload the driver would have to release all memory and may be do more cleanup and not all drivers do that. I would just reboot.
 
Even if unloading/reloading a kernel module is impractical, I was thinking, there's gotta be something to do when graphics crash... like setting a sysctl to manage RAM better... or some other config that I'm not aware of. My crash happened most likely when I attempted to exceed my 8GB of RAM... A bit of a bummer, because I was in the middle of doing something important, and yeah, it requires graphics to be more stable than that.
 
FreeBSD DRM driver code is ported from Linux using linuxKPI so we are kind of stuck. There are a bunch of drm related sysctls but they are not documented and fiddling with them might get you in more trouble! Just make sure you have enough swapspace.

You may be able to change the amount of memory dedicated for graphics from the BIOS.
 
Always question whether trouble is caused by the core of the system (here: kernel modules) or that it is caused by faults of ordinary programs like LibreOffice, Konqueror like here or their 'miscommunication' in pipes. Faults also can be triggered by specific file types, and PDF is known for that (a PDF can be many sub-formats).

What happens when you open the PDF with eg. graphics/mupdf or graphics/xpdf ?

Chain of deduction:
  1. wrong or broken file type? (including sub-types like PDF-A, forms, CSS/Javascript, DRM, etc)
  2. user config
  3. interaction, improper compatibility between file types and programs
  4. OS-setup as in (overly) user tweaked
  5. bugs
  6. rotten OS-concept (only seems to apply outside FOSS)
 
meine said:
wrong or broken file type? (including sub-types like PDF-A, forms, CSS/Javascript, DRM, etc)
Click to expand...
After reboot, logged into a clean KDE desktop, opened the file with Libre Office Draw. LO is rather RAM-hungry, but file opened fine, and looks correct. Internet research also indicated that Libre Office Draw is able to open simple PDF files, and at least display them.
meine said:
user config
Click to expand...
VERY minimal... I just compiled graphics/drm-kmod, edited /etc/rc.conf as per the FreeBSD graphics wiki, and that's it.
meine said:
interaction, improper compatibility between file types and programs
Click to expand...
I'd expect the program to crash and give me an error, but not the graphics to crash on me in that case.
meine said:
OS-setup as in (overly) user tweaked
Click to expand...
I actually avoid that to the extent practical.
meine said:
  1. bugs
  2. rotten OS-concept (only seems to apply outside FOSS)
Click to expand...
One would think of better enforcement of process boundaries in RAM... even with older software. FWIW, my Konqueror version is at 22.12.1, it's compiled, but still pulls in Python 2.7 😩 , and apparently not in active development since 2016...
 
Instead of konqueror why not use firefox&caja.
I use "awesome" as window manager. Because it is fast (& awesome)
Resident memory of awesome is merely 138M.
 
Yeah, I had to install FF 109.0 from pkg, because it takes more than 8 GB of RAM to compile THAT... After this conversation, I'm beginning to suspect py27 and Konqueror for my crash... because just about everything else looks very solid. Even RAM-hungry compilations don't mess up the graphics like the py27/Konqueror duo.
 
You must log in or register to reply here.
Back
Top