-1

After I upgrade kernel to 6.11.3 and 6.12-rc2 on Debian 11, my laptop cannot boot correctly. It will show blackscreen and "underscore cursor" on the left-top of the screen. Then, I found the last line of kern.log is

"traps: gdm3[1994] trap int3 ip:7fd83e616332 sp:7ffdc026ef90 error:0 in libglib-2.0.so.0.6600.8[59332,7fd83e5d9000+88000]"

and The Xorg.0.log shows

vesa(0): V_BIOS address 0x0 out of range

So, I think it should be about graphic module. Then, I try the boot parameter "nomodeset", but still cannot fix it. I also try Ubuntu 24.10 Live, it works fine. So, I think it might be about kernel config.

Here are my HW:

CPU: AMD Ryzen 5
GPU: Nvidia RTX4060

Here are my question:

How to know which graphic module is being used now for display? Then, I can know which kernel config I might need to enable.

Update:

  1. I also try these kernel on Intel CPU without dGPU and meet the same problem.
  2. Debian 12 with kernel 6.11 works fine.
3
  • this doesn't seem to be a kernel issue as much as it is a libglib issue? Did you perhaps update more software alongside with the kernel? Commented Oct 15, 2024 at 10:18
  • No, I didn't update any other software. Commented Oct 17, 2024 at 5:35
  • @Marcus Müller My libglib is the newest version of Debian 11 support, does it means that I need to upgrade to Debian 12? Commented Oct 17, 2024 at 5:58

1 Answer 1

1
"traps: gdm3[1994] trap int3 ip:7fd83e616332 sp:7ffdc026ef90 error:0 in libglib-2.0.so.0.6600.8[59332,7fd83e5d9000+88000]"

This means the gdm3 process with PID 1994 either encountered an int 3 CPU instruction, or received a SIGTRAP signal. Those are used as breakpoints when debugging a process, but "production-grade" code should not generally contain them. Maybe the program code was corrupted (on disk? in memory?) so that some other CPU instruction was transformed into int 3? When not encountered in a debugging context, the int 3 trap normally causes the program to crash.

vesa(0): V_BIOS address 0x0 out of range

This suggests the X11 server is not using any Direct Rendering interfaces, but is trying to fall back to (unaccelerated, legacy) VESA VBIOS access. But since your system is new enough to use UEFI, there is probably no legacy VBIOS available in UEFI mode at all (as indicated by VBIOS address being 0x0).

How to know which graphic module is being used now for display?

Run cat /proc/fb. It should tell you the name(s) of the kernel drivers of the currently detected display driver(s). If you'll see efifb or vesafb, the kernel is falling back to the unaccelerated basic display driver for UEFI or legacy BIOS, respectively.

An AMD Ryzen 5 laptop with a Nvidia RTX4060 as a dGPU will probably use the amdgpu driver for the iGPU integrated into the processor. For battery power optimization, the laptop's internal display is probably wired into the iGPU by default.

For the Nvidia dGPU, the possible drivers would be either the free nouveau or the proprietary nvidia driver. And since the RTX4060 is rather new, the free driver may miss some features. Since you're using Debian 11 which is significantly older than your hardware and no longer the current stable version, the versions of the nvidia driver packaged to Debian 11 might simply be too old to support your dGPU. The same might be true for the user-space X11 server components of the amdgpu driver too.

It may or may not be possible to switch the internal display to the dGPU control; if sudo cat /sys/kernel/debug/vgaswitcheroo/switch produces two or three lines of output similar to

0:DIS: :DynPwr:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0
2:DIS-Audio: :DynPwr:0000:01:00.1

then the necessary ACPI interface for switching the displays is present and the kernel knows how to use it. If the file is empty or the directory does not exist, then the ACPI interface for switching the GPUs connected to the laptop's internal display is not available to the kernel, or the appropriate drivers for your GPUs are not loaded.

See https://docs.kernel.org/gpu/vga-switcheroo.html for details.

If the entire /sys/kernel/debug directory is empty, you will need to mount the debugfs virtual filesystem first:

sudo mount -t debugfs debugfs /sys/kernel/debug

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.