[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1114884: Console hangs on 6.1.0-39 while 6.1.0-37 works fine



Control: retitle -1 Console hangs on 6.1.0-39 while 6.1.0-37 works fine

Hello Chris,

On Wed, Nov 12, 2025 at 03:23:21PM +0100, Chris Mair wrote:
> tried all three, nothing changes the stuck screen as shown on the attached VGA monitor:
> 
> - `echo t > /proc/sysrq-trigger` doesn't show on the monitor, but shows debug log correctly in the dmesg output,
> 
> - `echo "Debian is great" > /dev/tty1` doesn't show on the monitor,
> 
> - pressing Alt+PrtSc+t doesn't show on the monitor and logs 'sysrq: This sysrq operation is disabled.' in the dmesg output.
> 
> 
> Please excuse if I repeat information:

That's fine, when working on several bugs on and off it's easy to miss
some relevant info.

> The kernels that works fine (up to 6.1.0-37-amd64), show the boot log
> and then at some point visibly change the screen resolution, the font
> gets visibly thinner, the screen is cleared and the text-login prompt
> appears.
> 
> Later kernels (from 6.1.0-39-amd64 and what I'm using right now
> 6.1.0-40-amd64) freeze the screen at exactly the
> moment that switch occurs.
> 
> To me, it looks like whatever that switch does, just completely
> freezes screen output. But, what was logged up to
> that point stays on screen indefinitely (as in the photo). It's not
> that the screen blanks because somehow the VGA signal
> is wrong or lost, it keeps on showing that last screen content frozen
> in time.

I think the most useful way forward would be to bisect that problem. The
idea is to check the kernel commit that is approximately in the middle
between 6.1.0-37 (the newest known working kernel) and 6.1.0-39 (the
oldest known broken kernel). Depending on the outcome of the test there
is either a newer working one or an older broken. That can be iterated
until the offending commit is identified.

To do that, the following has to be done. If you fail to follow my
instructions (because they are too short or don't work as expected)
please report that back.

	git clone --single-branch -b linux-6.1.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
	cd linux-stable
	git checkout v6.1.140 # corresponds to 6.1.0-37
	cp /boot/config-$(uname -r) .config
	yes '' | make localmodconfig
	make savedefconfig
	mv defconfig arch/x86/configs/my_defconfig

	make my_defconfig
	make -j $(nproc) bindeb-pkg

You might need to install some additional packages, the ones that
are typically missing are:

	build-essential bc bison flex libelf-dev libssl-dev

This results in a package containing a 6.1.140 kernel. Install that,
boot it. The expectation is that this works fine. Then confirm that
6.1.148 is also bad when you build it:

	cd linux-stable
	git checkout v6.1.148
	make my_defconfig
	make -j $(nproc) bindeb-pkg

install and boot that.

If there are no suprises (i.e. 6.1.140 is good and 6.1.148 has that
hanging console) do:

	cd linux-stable
	git bisect start v6.1.148 6.1.140
	make my_defconfig
	make -j $(nproc) bindeb-pkg

Install and test that kernel and depending on it showing the problem or
not do:

	git bisect bad

or

	git bisect good

which checks out the next kernel to test. Iterate until the git bisect
command emits the offending commit. This needs ~11 iterations.

Please uninstall these test kernels at the end again to make sure that
the Debian kernel is used. Depending on your partitioning you might also
have to uninstall kernel earlier to have enough disk space in /boot and
/boot/efi to install the next test kernel.

(Some thoughts I had before considering that bisecting is the right
thing to do: Your machine has two VGA adapters, which is the relevant?
You could try to reload the driver. For my machine using the i915 driver
this would work as follows:

	root@hostname:~# cd /sys/module/i915/drivers/pci\:i915/
	root@hostname:/sys/module/i915/drivers/pci:i915# ls -la
	total 0
	drwxr-xr-x  2 root root    0 Nov  7 23:30 .
	drwxr-xr-x 31 root root    0 Nov  7 20:47 ..
	lrwxrwxrwx  1 root root    0 Nov 15 18:34 0000:00:02.0 -> ../../../../devices/pci0000:00/0000:00:02.0
	--w-------  1 root root 4096 Nov 15 18:34 bind
	lrwxrwxrwx  1 root root    0 Nov 15 18:34 module -> ../../../../module/i915
	--w-------  1 root root 4096 Nov 15 18:34 new_id
	--w-------  1 root root 4096 Nov 15 18:34 remove_id
	--w-------  1 root root 4096 Nov 15 18:34 uevent
	--w-------  1 root root 4096 Nov 15 18:34 unbind
	root@hostname:/sys/module/i915/drivers/pci:i915# echo 0000:00:02.0 > unbind; sleep 3; echo 0000:00:02.0 > bind

However it's not clear what we would learn from that. Might only be an
additional info when reporting your problem upstream.)

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature


Reply to: