Groups > linux.debian.kernel > #90548 > unrolled thread

Bug#1123750: linux: regression: virtual consoles 2-12 unusable

Started by	Salvatore Bonaccorso <carnil@debian.org>
First post	2025-12-21 08:00 +0100
Last post	2025-12-26 23:10 +0100
Articles	14 — 7 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Bug#1123750: linux: regression: virtual consoles 2-12 unusable Salvatore Bonaccorso <carnil@debian.org> - 2025-12-21 08:00 +0100
    Processed: Re: Bug#1123750: linux: regression: virtual consoles  2-12 unusable "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-12-21 08:00 +0100
    Bug#1123750: linux: regression: virtual consoles 2-12 unusable Salvatore Bonaccorso <carnil@debian.org> - 2025-12-21 09:10 +0100
    Bug#1123750: linux: regression: virtual consoles 2-12 unusable Thorsten Glaser <tg@mirbsd.de> - 2025-12-21 17:40 +0100
      Bug#1123750: linux: regression: virtual consoles 2-12 unusable Salvatore Bonaccorso <carnil@debian.org> - 2025-12-26 18:40 +0100
        Processed: Re: Bug#1123750: linux: regression: virtual consoles  2-12 unusable "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-12-26 18:40 +0100
        Bug#1123750: linux: regression: virtual consoles 2-12 unusable William Burrow <wbkernel@gmail.com> - 2025-12-26 20:30 +0100
          Bug#1123750: linux: regression: virtual consoles 2-12 unusable William Burrow <wbkernel@gmail.com> - 2025-12-27 03:10 +0100
            Bug#1123750: linux: regression: virtual consoles 2-12 unusable William Burrow <wbkernel@gmail.com> - 2025-12-27 03:30 +0100
          Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable Ben Hutchings <ben@decadent.org.uk> - 2026-01-02 17:30 +0100
            Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2026-01-08 14:40 +0100
              Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2026-01-28 15:30 +0100
        Bug#1123750: linux: regression: virtual consoles 2-12 unusable Thorsten Glaser <tg@debian.org> - 2025-12-26 23:10 +0100
        Bug#1123750: linux: regression: virtual consoles 2-12 unusable Thorsten Glaser <tg@debian.org> - 2025-12-26 23:10 +0100

#90548 — Bug#1123750: linux: regression: virtual consoles 2-12 unusable

From	Salvatore Bonaccorso <carnil@debian.org>
Date	2025-12-21 08:00 +0100
Subject	Bug#1123750: linux: regression: virtual consoles 2-12 unusable
Message-ID	<M4lA5-4w6w-1@gated-at.bofh.it>

Control: tags -1 + upstream moreinfo

On Sat, Dec 20, 2025 at 11:05:18PM +0100, Thorsten Glaser wrote:
> Package: src:linux
> Version: 5.10.247-1
> Severity: important
> X-Debbugs-Cc: tg@mirbsd.de
> 
> After an upgrade from 5.10.0-36 to -37, the virtual consoles
> 2-12 are unusable: they merely show a screenful of the old
> currency sign (which seems to be the replacement character
> for some reason, but I believe it’s U+00A4), and when I enter
> text, it mostly stays like that, except for one space that
> moves around the screen and a lowercase x that appears near
> the beginning of a line.
> 
> Virtual console 1 is fully usable.

Please see
https://lists.debian.org/debian-kernel/2025/12/msg00211.html .

If you can do the bisect mentioned that would help identifying the
problem.

Regards,
Salvatore

[toc] | [next] | [standalone]

#90549 — Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable

From	"Debian Bug Tracking System" <owner@bugs.debian.org>
Date	2025-12-21 08:00 +0100
Subject	Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable
Message-ID	<M4lA5-4w6w-3@gated-at.bofh.it>
In reply to	#90548

Processing control commands:

> tags -1 + upstream moreinfo
Bug #1123750 [src:linux] linux: regression: virtual consoles 2-12 unusable
Added tag(s) moreinfo and upstream.

-- 
1123750: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123750
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#90550

From	Salvatore Bonaccorso <carnil@debian.org>
Date	2025-12-21 09:10 +0100
Message-ID	<M4mFP-4x2q-3@gated-at.bofh.it>
In reply to	#90548

Hi,

On Sun, Dec 21, 2025 at 07:23:43AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + upstream moreinfo
> 
> On Sat, Dec 20, 2025 at 11:05:18PM +0100, Thorsten Glaser wrote:
> > Package: src:linux
> > Version: 5.10.247-1
> > Severity: important
> > X-Debbugs-Cc: tg@mirbsd.de
> > 
> > After an upgrade from 5.10.0-36 to -37, the virtual consoles
> > 2-12 are unusable: they merely show a screenful of the old
> > currency sign (which seems to be the replacement character
> > for some reason, but I believe it’s U+00A4), and when I enter
> > text, it mostly stays like that, except for one space that
> > moves around the screen and a lowercase x that appears near
> > the beginning of a line.
> > 
> > Virtual console 1 is fully usable.
> 
> Please see
> https://lists.debian.org/debian-kernel/2025/12/msg00211.html .
> 
> If you can do the bisect mentioned that would help identifying the
> problem.

I just realized I had a copy paste error in my proceure there, so
obvoulsy the second git checkout would be v5.10.247. For consistencly
let's replicate it here:

    git clone --single-branch -b linux-5.10.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v5.10.244
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 5.10.244 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it successfully boots / problem does not exist

    # test 5.10.247 to ensure this is "bad"
    git checkout v5.10.247
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it fails to boot / problem exists

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v5.10.244
    git bisect bad v5.10.247

In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, try to boot / verify if problem exists

and if the problem is hit run:

    git bisect bad

and if the problem doesn't trigger run:

    git bisect good

. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.

Iterate until git announces to have identified the first bad commit.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.

If we can identify a breaking commit that would be then easy enough to
forward upstream. I nparticular we should make as well sure if this is
a 5.10.y specific regresssion (but I have not seen the behaviour
reported on other kernels).

Regards
Salvatore

[toc] | [prev] | [next] | [standalone]

#90551

From	Thorsten Glaser <tg@mirbsd.de>
Date	2025-12-21 17:40 +0100
Message-ID	<M4uDn-4Cdb-5@gated-at.bofh.it>
In reply to	#90548

Hi Salvatore,

>If you can do the bisect mentioned that would help identifying the
>problem.

I’m not in a position to do that currently, I don’t have a
fast machine anyway and packed light, too. But at least X11
works, so I’m fine currently.

This is a Thinkpad X61 with Intel integrated graphics, FWIW.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[toc] | [prev] | [next] | [standalone]

#90580

From	Salvatore Bonaccorso <carnil@debian.org>
Date	2025-12-26 18:40 +0100
Message-ID	<M6jXb-5QdE-7@gated-at.bofh.it>
In reply to	#90551

Control: tags -1 - moreinfo
Control: forwarded -1 https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html 

Hi,

On Sun, Dec 21, 2025 at 04:19:14PM +0000, Thorsten Glaser wrote:
> Hi Salvatore,
> 
> >If you can do the bisect mentioned that would help identifying the
> >problem.
> 
> I’m not in a position to do that currently, I don’t have a
> fast machine anyway and packed light, too. But at least X11
> works, so I’m fine currently.
> 
> This is a Thinkpad X61 with Intel integrated graphics, FWIW.

FTR, there is some progress in
https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
retrospectively we should have made a Debian BTS bug from the start
for easier tracking).

Helge, can you please include the Debian bug #1123750 in next replies?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90581 — Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable

From	"Debian Bug Tracking System" <owner@bugs.debian.org>
Date	2025-12-26 18:40 +0100
Subject	Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable
Message-ID	<M6jXb-5QdE-11@gated-at.bofh.it>
In reply to	#90580

Processing control commands:

> tags -1 - moreinfo
Bug #1123750 [src:linux] linux: regression: virtual consoles 2-12 unusable
Removed tag(s) moreinfo.
> forwarded -1 https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html
Bug #1123750 [src:linux] linux: regression: virtual consoles 2-12 unusable
Set Bug forwarded-to-address to 'https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html'.

-- 
1123750: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123750
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#90586

From	William Burrow <wbkernel@gmail.com>
Date	2025-12-26 20:30 +0100
Message-ID	<M6lFD-5Rsv-7@gated-at.bofh.it>
In reply to	#90580

Hi, all.
To summarize the message thread, commit 0998a6cb232 was found to be
the issue.  It is unclear why this commit causes an issue.  It was
added shortly after kernel v5.10.246 was released, so it was not
necessary to bisect between 5.10.244 and 5.10.247, saving time.
.
In testing, it was found that the variable charcnt is set to zero,
causing the if-statement to trigger.  This should not happen.  There
may be a bug somewhere else that triggers this.
.
Patching the line after the added if-statement in that commit from ch
= 0 to ch = 32 (space character) does not seem to fix the issue, it
just changes it from a screen of symbols to a (mostly) blank screen.
This is unexpected, since the address for the variable src should be
the same calculated with the change of ch = 32 with this patch or the
code before this patch.
.
Thanks for your time to review this bug.
.
------------------------- suspected commit ----------------------
diff --git a/drivers/video/fbdev/core/bitblit.c
b/drivers/video/fbdev/core/bitblit.c
index bb821b68f88c..4e774010d09f 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
vc_data *vc, struct fb_info *info,
                                    struct fb_image *image, u8 *buf, u8 *dst)
{
       u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
+       unsigned int charcnt = vc->vc_font.charcount;
       u32 idx = vc->vc_font.width >> 3;
       u8 *src;

       while (cnt--) {
-               src = vc->vc_font.data + (scr_readw(s++)&
-                                         charmask)*cellsize;
+               u16 ch = scr_readw(s++) & charmask;
+
+               if (ch >= charcnt)
+                       ch = 0;
+               src = vc->vc_font.data + (unsigned int)ch * cellsize;

               if (attr) {
                       update_attr(buf, src, attr, vc);
@@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
                                      u8 *dst)
{
       u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
+       unsigned int charcnt = vc->vc_font.charcount;
       u32 shift_low = 0, mod = vc->vc_font.width % 8;
       u32 shift_high = 8;
       u32 idx = vc->vc_font.width >> 3;
       u8 *src;

       while (cnt--) {
-               src = vc->vc_font.data + (scr_readw(s++)&
-                                         charmask)*cellsize;
+               u16 ch = scr_readw(s++) & charmask;
+
+               if (ch >= charcnt)
+                       ch = 0;
+               src = vc->vc_font.data + (unsigned int)ch * cellsize;

               if (attr) {
                       update_attr(buf, src, attr, vc);
------------------------- suspected commit ----------------------

On Fri, Dec 26, 2025 at 12:48 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Control: tags -1 - moreinfo
> Control: forwarded -1 https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html
>
> Hi,
>
> On Sun, Dec 21, 2025 at 04:19:14PM +0000, Thorsten Glaser wrote:
> > Hi Salvatore,
> >
> > >If you can do the bisect mentioned that would help identifying the
> > >problem.
> >
> > I’m not in a position to do that currently, I don’t have a
> > fast machine anyway and packed light, too. But at least X11
> > works, so I’m fine currently.
> >
> > This is a Thinkpad X61 with Intel integrated graphics, FWIW.
>
> FTR, there is some progress in
> https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
> retrospectively we should have made a Debian BTS bug from the start
> for easier tracking).
>
> Helge, can you please include the Debian bug #1123750 in next replies?
>
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#90591

From	William Burrow <wbkernel@gmail.com>
Date	2025-12-27 03:10 +0100
Message-ID	<M6rUJ-5VP5-1@gated-at.bofh.it>
In reply to	#90586

Hi, did some more work.
The problem with changing the variable, ch, to any fixed value is that
when charcnt is 0, then whatever is being evaluated is clobbered.  The
reason for charcount being zero must be fixed.  The following log was
produced from the diff shown at the end of this message (only
bit_putcs_aligned() seems to be called):
.
-------------------------- log -------------------------
2025-12-26T20:30:02.666098-04:00 abc kernel: [   52.640518] ** **
bit_putcs_aligned: ---------->>
2025-12-26T20:30:02.666099-04:00 abc kernel: [   52.640518] ** **
bit_putcs_aligned: cnt: 12
2025-12-26T20:30:02.666100-04:00 abc kernel: [   52.640519] ** **
bit_putcs_aligned: vc->vc_font.data: 0xffff932c008a8010
2025-12-26T20:30:02.666101-04:00 abc kernel: [   52.640519] ** **
bit_putcs_aligned:          srcorig: 0xffff932c008a8210
2025-12-26T20:30:02.666102-04:00 abc kernel: [   52.640520] ** **
bit_putcs_aligned: before: ch: 0x20
2025-12-26T20:30:02.666103-04:00 abc kernel: [   52.640520] ** **
bit_putcs_aligned:  after: ch: 0x20
2025-12-26T20:30:02.666104-04:00 abc kernel: [   52.640521] ** **
bit_putcs_aligned: charcnt: 0x0
2025-12-26T20:30:02.666104-04:00 abc kernel: [   52.640522] ** **
bit_putcs_aligned: cellsize: 0x10
2025-12-26T20:30:02.666105-04:00 abc kernel: [   52.640522] ** **
bit_putcs_aligned: ch * cellsize: 0x200
2025-12-26T20:30:02.666106-04:00 abc kernel: [   52.640523] ** **
bit_putcs_aligned:           srcnew: 0xffff932c008a8210
2025-12-26T20:30:02.666107-04:00 abc kernel: [   52.640523] ** **
bit_putcs_aligned: srcorig - srcnew: 0x0
2025-12-26T20:30:02.666108-04:00 abc kernel: [   52.640525] ** **
bit_putcs_aligned: srcnew
2025-12-26T20:30:02.666109-04:00 abc kernel: [   52.640525] ** **
bit_putcs_aligned: <<----------
2025-12-26T20:30:02.666110-04:00 abc kernel: [   52.640526] ** **
bit_putcs_aligned: ---------->>
2025-12-26T20:30:02.666121-04:00 abc kernel: [   52.640526] ** **
bit_putcs_aligned: cnt: 11
2025-12-26T20:30:02.666123-04:00 abc kernel: [   52.640527] ** **
bit_putcs_aligned: vc->vc_font.data: 0xffff932c008a8010
2025-12-26T20:30:02.666124-04:00 abc kernel: [   52.640527] ** **
bit_putcs_aligned:          srcorig: 0xffff932c008a8320
2025-12-26T20:30:02.666125-04:00 abc kernel: [   52.640528] ** **
bit_putcs_aligned: before: ch: 0x31
2025-12-26T20:30:02.666125-04:00 abc kernel: [   52.640528] ** **
bit_putcs_aligned:  after: ch: 0x20          <<<--- CLOBBERED
2025-12-26T20:30:02.666126-04:00 abc kernel: [   52.640529] ** **
bit_putcs_aligned: charcnt: 0x0
2025-12-26T20:30:02.666127-04:00 abc kernel: [   52.640529] ** **
bit_putcs_aligned: cellsize: 0x10
2025-12-26T20:30:02.666128-04:00 abc kernel: [   52.640530] ** **
bit_putcs_aligned: ch * cellsize: 0x200
2025-12-26T20:30:02.666129-04:00 abc kernel: [   52.640530] ** **
bit_putcs_aligned:           srcnew:
0xffffjjjjjjjjjjjjjjjjj932c008a8210
2025-12-26T20:30:02.666130-04:00 abc kernel: [   52.640531] ** **
bit_putcs_aligned: srcorig - srcnew: 0x110
2025-12-26T20:30:02.666130-04:00 abc kernel: [   52.640531] ** **
bit_putcs_aligned: srcnew
2025-12-26T20:30:02.666132-04:00 abc kernel: [   52.640531] ** **
bit_putcs_aligned: <<----------
-------------------------- log -------------------------
.
Here is the patch that produced this log.  DO NOT work in the vtty
with this patch, it will fill your logs and maybe make your machine
unbootable.  Word to the wise.
.
-------------------------- patch to generate log --------------------------
--- a/drivers/video/fbdev/core/bitblit.c        2025-12-26
14:46:52.270645363 -0400
+++ b/drivers/video/fbdev/core/bitblit.c        2025-12-26
20:21:38.096907035 -0400
@@ -82,13 +82,35 @@
       unsigned int charcnt = vc->vc_font.charcount;
       u32 idx = vc->vc_font.width >> 3;
       u8 *src;
+       u16 ch = 0;
+       u16 prech = 0;
+       u8 * srcnew, * srcorig;

       while (cnt--) {
-               u16 ch = scr_readw(s++) & charmask;
-
-               if (ch >= charcnt)
-                       ch = 0;
-               src = vc->vc_font.data + (unsigned int)ch * cellsize;
+               prech = scr_readw(s++);
+               srcorig = vc->vc_font.data + (prech&
+                                         charmask)*cellsize;
+               printk("** ** bit_putcs_aligned: ---------->>\n");
+               printk("** ** bit_putcs_aligned: cnt: %d\n", cnt);
+               printk("** ** bit_putcs_aligned: vc->vc_font.data:
0x%lx\n", vc->vc_font.data );
+               printk("** ** bit_putcs_aligned:          srcorig:
0x%lx\n", srcorig );
+
+               ch = prech & charmask;
+               printk("** ** bit_putcs_aligned: before: ch: 0x%x\n", ch);
+
+                if (ch >= charcnt)
+                        ch = 32;
+                srcnew = vc->vc_font.data + ch * cellsize;
+               printk("** ** bit_putcs_aligned:  after: ch: 0x%x\n", ch);
+               printk("** ** bit_putcs_aligned: charcnt: 0x%x\n", charcnt);
+               printk("** ** bit_putcs_aligned: cellsize: 0x%x\n", cellsize);
+               printk("** ** bit_putcs_aligned: ch * cellsize:
0x%x\n", (ch * cellsize));
+               printk("** ** bit_putcs_aligned:           srcnew:
0x%lx\n", srcnew);
+               printk("** ** bit_putcs_aligned: srcorig - srcnew:
0x%lx\n", (srcorig - srcnew));
+
+               // src = srcorig; printk("** ** bit_putcs_aligned: srcorig\n");
+               src = srcnew; printk("** ** bit_putcs_aligned: srcnew\n");
+               printk("** ** bit_putcs_aligned: <<----------\n");

               if (attr) {
                       update_attr(buf, src, attr, vc);
-------------------------- patch to generate log --------------------------
.

On Fri, Dec 26, 2025 at 3:18 PM William Burrow <wbkernel@gmail.com> wrote:
>
> Hi, all.
> To summarize the message thread, commit 0998a6cb232 was found to be
> the issue.  It is unclear why this commit causes an issue.  It was
> added shortly after kernel v5.10.246 was released, so it was not
> necessary to bisect between 5.10.244 and 5.10.247, saving time.
> .
> In testing, it was found that the variable charcnt is set to zero,
> causing the if-statement to trigger.  This should not happen.  There
> may be a bug somewhere else that triggers this.
> .
> Patching the line after the added if-statement in that commit from ch
> = 0 to ch = 32 (space character) does not seem to fix the issue, it
> just changes it from a screen of symbols to a (mostly) blank screen.
> This is unexpected, since the address for the variable src should be
> the same calculated with the change of ch = 32 with this patch or the
> code before this patch.
> .
> Thanks for your time to review this bug.
> .
> ------------------------- suspected commit ----------------------
> diff --git a/drivers/video/fbdev/core/bitblit.c
> b/drivers/video/fbdev/core/bitblit.c
> index bb821b68f88c..4e774010d09f 100644
> --- a/drivers/video/fbdev/core/bitblit.c
> +++ b/drivers/video/fbdev/core/bitblit.c
> @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
> vc_data *vc, struct fb_info *info,
>                                     struct fb_image *image, u8 *buf, u8 *dst)
> {
>        u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> +       unsigned int charcnt = vc->vc_font.charcount;
>        u32 idx = vc->vc_font.width >> 3;
>        u8 *src;
>
>        while (cnt--) {
> -               src = vc->vc_font.data + (scr_readw(s++)&
> -                                         charmask)*cellsize;
> +               u16 ch = scr_readw(s++) & charmask;
> +
> +               if (ch >= charcnt)
> +                       ch = 0;
> +               src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
>                if (attr) {
>                        update_attr(buf, src, attr, vc);
> @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
>                                       u8 *dst)
> {
>        u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> +       unsigned int charcnt = vc->vc_font.charcount;
>        u32 shift_low = 0, mod = vc->vc_font.width % 8;
>        u32 shift_high = 8;
>        u32 idx = vc->vc_font.width >> 3;
>        u8 *src;
>
>        while (cnt--) {
> -               src = vc->vc_font.data + (scr_readw(s++)&
> -                                         charmask)*cellsize;
> +               u16 ch = scr_readw(s++) & charmask;
> +
> +               if (ch >= charcnt)
> +                       ch = 0;
> +               src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
>                if (attr) {
>                        update_attr(buf, src, attr, vc);
> ------------------------- suspected commit ----------------------
>
> On Fri, Dec 26, 2025 at 12:48 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Control: tags -1 - moreinfo
> > Control: forwarded -1 https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html
> >
> > Hi,
> >
> > On Sun, Dec 21, 2025 at 04:19:14PM +0000, Thorsten Glaser wrote:
> > > Hi Salvatore,
> > >
> > > >If you can do the bisect mentioned that would help identifying the
> > > >problem.
> > >
> > > I’m not in a position to do that currently, I don’t have a
> > > fast machine anyway and packed light, too. But at least X11
> > > works, so I’m fine currently.
> > >
> > > This is a Thinkpad X61 with Intel integrated graphics, FWIW.
> >
> > FTR, there is some progress in
> > https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
> > retrospectively we should have made a Debian BTS bug from the start
> > for easier tracking).
> >
> > Helge, can you please include the Debian bug #1123750 in next replies?
> >
> > Regards,
> > Salvatore

[toc] | [prev] | [next] | [standalone]

#90592

From	William Burrow <wbkernel@gmail.com>
Date	2025-12-27 03:30 +0100
Message-ID	<M6se5-5VXy-1@gated-at.bofh.it>
In reply to	#90591

After some more digging, the problem is probably when the font is
assigned in the following file:
drivers/video/fbdev/core/fbcon.c
Somewhere around line 1011, maybe.  Line 1009 hardcodes the charcount
to 256.  Later kernels set this to the actual font size sometime
around 2020.  Two commits found in this area in the 6.1.120 kernel
applied cleanly, but did not compile.  Specifically, the following
commits were applied in order, first a1ac250a82a5e97, then commit
17d649967006f.
.
However, for the purposes of the 5.10, it looks like the value is
hardcoded to 256.  So, rather than fix this properly, just hardcoding
the value as is is probably sufficient.
.
I will try a build later with a hardcoded fix.
.
a1ac250a82a5e97: fbcon: Avoid using FNTCHARCNT() and hard-coded
built-in font charcount
17d649967006f: Revert "fbcon: don't lose the console font across
generic->chip driver switch"
.

On Fri, Dec 26, 2025 at 10:07 PM William Burrow <wbkernel@gmail.com> wrote:
>
> Hi, did some more work.
> The problem with changing the variable, ch, to any fixed value is that
> when charcnt is 0, then whatever is being evaluated is clobbered.  The
> reason for charcount being zero must be fixed.  The following log was
> produced from the diff shown at the end of this message (only
> bit_putcs_aligned() seems to be called):
> .
> -------------------------- log -------------------------
> 2025-12-26T20:30:02.666098-04:00 abc kernel: [   52.640518] ** **
> bit_putcs_aligned: ---------->>
> 2025-12-26T20:30:02.666099-04:00 abc kernel: [   52.640518] ** **
> bit_putcs_aligned: cnt: 12
> 2025-12-26T20:30:02.666100-04:00 abc kernel: [   52.640519] ** **
> bit_putcs_aligned: vc->vc_font.data: 0xffff932c008a8010
> 2025-12-26T20:30:02.666101-04:00 abc kernel: [   52.640519] ** **
> bit_putcs_aligned:          srcorig: 0xffff932c008a8210
> 2025-12-26T20:30:02.666102-04:00 abc kernel: [   52.640520] ** **
> bit_putcs_aligned: before: ch: 0x20
> 2025-12-26T20:30:02.666103-04:00 abc kernel: [   52.640520] ** **
> bit_putcs_aligned:  after: ch: 0x20
> 2025-12-26T20:30:02.666104-04:00 abc kernel: [   52.640521] ** **
> bit_putcs_aligned: charcnt: 0x0
> 2025-12-26T20:30:02.666104-04:00 abc kernel: [   52.640522] ** **
> bit_putcs_aligned: cellsize: 0x10
> 2025-12-26T20:30:02.666105-04:00 abc kernel: [   52.640522] ** **
> bit_putcs_aligned: ch * cellsize: 0x200
> 2025-12-26T20:30:02.666106-04:00 abc kernel: [   52.640523] ** **
> bit_putcs_aligned:           srcnew: 0xffff932c008a8210
> 2025-12-26T20:30:02.666107-04:00 abc kernel: [   52.640523] ** **
> bit_putcs_aligned: srcorig - srcnew: 0x0
> 2025-12-26T20:30:02.666108-04:00 abc kernel: [   52.640525] ** **
> bit_putcs_aligned: srcnew
> 2025-12-26T20:30:02.666109-04:00 abc kernel: [   52.640525] ** **
> bit_putcs_aligned: <<----------
> 2025-12-26T20:30:02.666110-04:00 abc kernel: [   52.640526] ** **
> bit_putcs_aligned: ---------->>
> 2025-12-26T20:30:02.666121-04:00 abc kernel: [   52.640526] ** **
> bit_putcs_aligned: cnt: 11
> 2025-12-26T20:30:02.666123-04:00 abc kernel: [   52.640527] ** **
> bit_putcs_aligned: vc->vc_font.data: 0xffff932c008a8010
> 2025-12-26T20:30:02.666124-04:00 abc kernel: [   52.640527] ** **
> bit_putcs_aligned:          srcorig: 0xffff932c008a8320
> 2025-12-26T20:30:02.666125-04:00 abc kernel: [   52.640528] ** **
> bit_putcs_aligned: before: ch: 0x31
> 2025-12-26T20:30:02.666125-04:00 abc kernel: [   52.640528] ** **
> bit_putcs_aligned:  after: ch: 0x20          <<<--- CLOBBERED
> 2025-12-26T20:30:02.666126-04:00 abc kernel: [   52.640529] ** **
> bit_putcs_aligned: charcnt: 0x0
> 2025-12-26T20:30:02.666127-04:00 abc kernel: [   52.640529] ** **
> bit_putcs_aligned: cellsize: 0x10
> 2025-12-26T20:30:02.666128-04:00 abc kernel: [   52.640530] ** **
> bit_putcs_aligned: ch * cellsize: 0x200
> 2025-12-26T20:30:02.666129-04:00 abc kernel: [   52.640530] ** **
> bit_putcs_aligned:           srcnew:
> 0xffffjjjjjjjjjjjjjjjjj932c008a8210
> 2025-12-26T20:30:02.666130-04:00 abc kernel: [   52.640531] ** **
> bit_putcs_aligned: srcorig - srcnew: 0x110
> 2025-12-26T20:30:02.666130-04:00 abc kernel: [   52.640531] ** **
> bit_putcs_aligned: srcnew
> 2025-12-26T20:30:02.666132-04:00 abc kernel: [   52.640531] ** **
> bit_putcs_aligned: <<----------
> -------------------------- log -------------------------
> .
> Here is the patch that produced this log.  DO NOT work in the vtty
> with this patch, it will fill your logs and maybe make your machine
> unbootable.  Word to the wise.
> .
> -------------------------- patch to generate log --------------------------
> --- a/drivers/video/fbdev/core/bitblit.c        2025-12-26
> 14:46:52.270645363 -0400
> +++ b/drivers/video/fbdev/core/bitblit.c        2025-12-26
> 20:21:38.096907035 -0400
> @@ -82,13 +82,35 @@
>        unsigned int charcnt = vc->vc_font.charcount;
>        u32 idx = vc->vc_font.width >> 3;
>        u8 *src;
> +       u16 ch = 0;
> +       u16 prech = 0;
> +       u8 * srcnew, * srcorig;
>
>        while (cnt--) {
> -               u16 ch = scr_readw(s++) & charmask;
> -
> -               if (ch >= charcnt)
> -                       ch = 0;
> -               src = vc->vc_font.data + (unsigned int)ch * cellsize;
> +               prech = scr_readw(s++);
> +               srcorig = vc->vc_font.data + (prech&
> +                                         charmask)*cellsize;
> +               printk("** ** bit_putcs_aligned: ---------->>\n");
> +               printk("** ** bit_putcs_aligned: cnt: %d\n", cnt);
> +               printk("** ** bit_putcs_aligned: vc->vc_font.data:
> 0x%lx\n", vc->vc_font.data );
> +               printk("** ** bit_putcs_aligned:          srcorig:
> 0x%lx\n", srcorig );
> +
> +               ch = prech & charmask;
> +               printk("** ** bit_putcs_aligned: before: ch: 0x%x\n", ch);
> +
> +                if (ch >= charcnt)
> +                        ch = 32;
> +                srcnew = vc->vc_font.data + ch * cellsize;
> +               printk("** ** bit_putcs_aligned:  after: ch: 0x%x\n", ch);
> +               printk("** ** bit_putcs_aligned: charcnt: 0x%x\n", charcnt);
> +               printk("** ** bit_putcs_aligned: cellsize: 0x%x\n", cellsize);
> +               printk("** ** bit_putcs_aligned: ch * cellsize:
> 0x%x\n", (ch * cellsize));
> +               printk("** ** bit_putcs_aligned:           srcnew:
> 0x%lx\n", srcnew);
> +               printk("** ** bit_putcs_aligned: srcorig - srcnew:
> 0x%lx\n", (srcorig - srcnew));
> +
> +               // src = srcorig; printk("** ** bit_putcs_aligned: srcorig\n");
> +               src = srcnew; printk("** ** bit_putcs_aligned: srcnew\n");
> +               printk("** ** bit_putcs_aligned: <<----------\n");
>
>                if (attr) {
>                        update_attr(buf, src, attr, vc);
> -------------------------- patch to generate log --------------------------
> .
>
> On Fri, Dec 26, 2025 at 3:18 PM William Burrow <wbkernel@gmail.com> wrote:
> >
> > Hi, all.
> > To summarize the message thread, commit 0998a6cb232 was found to be
> > the issue.  It is unclear why this commit causes an issue.  It was
> > added shortly after kernel v5.10.246 was released, so it was not
> > necessary to bisect between 5.10.244 and 5.10.247, saving time.
> > .
> > In testing, it was found that the variable charcnt is set to zero,
> > causing the if-statement to trigger.  This should not happen.  There
> > may be a bug somewhere else that triggers this.
> > .
> > Patching the line after the added if-statement in that commit from ch
> > = 0 to ch = 32 (space character) does not seem to fix the issue, it
> > just changes it from a screen of symbols to a (mostly) blank screen.
> > This is unexpected, since the address for the variable src should be
> > the same calculated with the change of ch = 32 with this patch or the
> > code before this patch.
> > .
> > Thanks for your time to review this bug.
> > .
> > ------------------------- suspected commit ----------------------
> > diff --git a/drivers/video/fbdev/core/bitblit.c
> > b/drivers/video/fbdev/core/bitblit.c
> > index bb821b68f88c..4e774010d09f 100644
> > --- a/drivers/video/fbdev/core/bitblit.c
> > +++ b/drivers/video/fbdev/core/bitblit.c
> > @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
> > vc_data *vc, struct fb_info *info,
> >                                     struct fb_image *image, u8 *buf, u8 *dst)
> > {
> >        u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> > +       unsigned int charcnt = vc->vc_font.charcount;
> >        u32 idx = vc->vc_font.width >> 3;
> >        u8 *src;
> >
> >        while (cnt--) {
> > -               src = vc->vc_font.data + (scr_readw(s++)&
> > -                                         charmask)*cellsize;
> > +               u16 ch = scr_readw(s++) & charmask;
> > +
> > +               if (ch >= charcnt)
> > +                       ch = 0;
> > +               src = vc->vc_font.data + (unsigned int)ch * cellsize;
> >
> >                if (attr) {
> >                        update_attr(buf, src, attr, vc);
> > @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
> >                                       u8 *dst)
> > {
> >        u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> > +       unsigned int charcnt = vc->vc_font.charcount;
> >        u32 shift_low = 0, mod = vc->vc_font.width % 8;
> >        u32 shift_high = 8;
> >        u32 idx = vc->vc_font.width >> 3;
> >        u8 *src;
> >
> >        while (cnt--) {
> > -               src = vc->vc_font.data + (scr_readw(s++)&
> > -                                         charmask)*cellsize;
> > +               u16 ch = scr_readw(s++) & charmask;
> > +
> > +               if (ch >= charcnt)
> > +                       ch = 0;
> > +               src = vc->vc_font.data + (unsigned int)ch * cellsize;
> >
> >                if (attr) {
> >                        update_attr(buf, src, attr, vc);
> > ------------------------- suspected commit ----------------------
> >
> > On Fri, Dec 26, 2025 at 12:48 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
> > >
> > > Control: tags -1 - moreinfo
> > > Control: forwarded -1 https://lists.debian.org/debian-kernel/2025/12/msg00293.html https://lists.debian.org/debian-kernel/2025/12/msg00211.html
> > >
> > > Hi,
> > >
> > > On Sun, Dec 21, 2025 at 04:19:14PM +0000, Thorsten Glaser wrote:
> > > > Hi Salvatore,
> > > >
> > > > >If you can do the bisect mentioned that would help identifying the
> > > > >problem.
> > > >
> > > > I’m not in a position to do that currently, I don’t have a
> > > > fast machine anyway and packed light, too. But at least X11
> > > > works, so I’m fine currently.
> > > >
> > > > This is a Thinkpad X61 with Intel integrated graphics, FWIW.
> > >
> > > FTR, there is some progress in
> > > https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
> > > retrospectively we should have made a Debian BTS bug from the start
> > > for easier tracking).
> > >
> > > Helge, can you please include the Debian bug #1123750 in next replies?
> > >
> > > Regards,
> > > Salvatore

[toc] | [prev] | [next] | [standalone]

#90655 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

From	Ben Hutchings <ben@decadent.org.uk>
Date	2026-01-02 17:30 +0100
Subject	Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable
Message-ID	<M8Qch-7xYI-3@gated-at.bofh.it>
In reply to	#90586

[Multipart message — attachments visible in raw view] — view raw

Hello stable maintainers,

Several Debian users reported a regression after updating to kernel
version 5.10.247.

Commit f0982400648a ("fbdev: Add bounds checking in bit_putcs to fix
vmalloc-out-of-bounds"), a backport of upstream commit 3637d34b35b2,
depends on vc_data::vc_font.charcount being initialised correctly.

However, before commit a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT()
and hard-coded built-in font charcount") in 5.11, this member was set
to 256 for VTs initially created with a built-in font and 0 for VTs
initially created with a user font.

Since Debian normally sets a user font before creating VTs 2 and up,
those additional VTs became unusable.  VT 1 also doesn't work correctly
if the user font has > 256 characters, and the bounds check is
ineffective if it has < 256 characters.

This can be fixed by backporting the following commits from 5.11:

7a089ec7d77f console: Delete unused con_font_copy() callback implementations
259a252c1f4e console: Delete dummy con_font_set() and con_font_default() callback implementations
4ee573086bd8 Fonts: Add charcount field to font_desc
4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount
a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount

These all apply without fuzz and builds cleanly for x86_64 and parisc64.

I tested on x86_64 that:

- VT 2 works again
- bit_putcs_aligned() is setting charcnt = 256
- After loading a font with 512 characters, bit_putcs_aligned() sets
  charcnt = 512 and is able to display characters at positions >= 256

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
                                                          - Lily Tomlin

[toc] | [prev] | [next] | [standalone]

#90748 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2026-01-08 14:40 +0100
Subject	Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable
Message-ID	<MaYp3-91mJ-1@gated-at.bofh.it>
In reply to	#90655

On Fri, Jan 02, 2026 at 05:26:22PM +0100, Ben Hutchings wrote:
> Hello stable maintainers,
> 
> Several Debian users reported a regression after updating to kernel
> version 5.10.247.
> 
> Commit f0982400648a ("fbdev: Add bounds checking in bit_putcs to fix
> vmalloc-out-of-bounds"), a backport of upstream commit 3637d34b35b2,
> depends on vc_data::vc_font.charcount being initialised correctly.
> 
> However, before commit a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT()
> and hard-coded built-in font charcount") in 5.11, this member was set
> to 256 for VTs initially created with a built-in font and 0 for VTs
> initially created with a user font.
> 
> Since Debian normally sets a user font before creating VTs 2 and up,
> those additional VTs became unusable.  VT 1 also doesn't work correctly
> if the user font has > 256 characters, and the bounds check is
> ineffective if it has < 256 characters.
> 
> This can be fixed by backporting the following commits from 5.11:
> 
> 7a089ec7d77f console: Delete unused con_font_copy() callback implementations
> 259a252c1f4e console: Delete dummy con_font_set() and con_font_default() callback implementations
> 4ee573086bd8 Fonts: Add charcount field to font_desc
> 4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount
> a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount
> 
> These all apply without fuzz and builds cleanly for x86_64 and parisc64.
> 
> I tested on x86_64 that:
> 
> - VT 2 works again
> - bit_putcs_aligned() is setting charcnt = 256
> - After loading a font with 512 characters, bit_putcs_aligned() sets
>   charcnt = 512 and is able to display characters at positions >= 256

All now queued up, thanks!

greg k-h

[toc] | [prev] | [next] | [standalone]

#90986 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

From	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date	2026-01-28 15:30 +0100
Subject	Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable
Message-ID	<MieIp-dYuH-5@gated-at.bofh.it>
In reply to	#90748

On Thu, Jan 15, 2026 at 12:41:10AM -0800, Barry K. Nathan wrote:
> On 1/8/26 5:23 AM, Greg Kroah-Hartman wrote:
> > On Fri, Jan 02, 2026 at 05:26:22PM +0100, Ben Hutchings wrote:
> > > Hello stable maintainers,
> > > 
> > > Several Debian users reported a regression after updating to kernel
> > > version 5.10.247.
> > > 
> > > Commit f0982400648a ("fbdev: Add bounds checking in bit_putcs to fix
> > > vmalloc-out-of-bounds"), a backport of upstream commit 3637d34b35b2,
> > > depends on vc_data::vc_font.charcount being initialised correctly.
> > > 
> > > However, before commit a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT()
> > > and hard-coded built-in font charcount") in 5.11, this member was set
> > > to 256 for VTs initially created with a built-in font and 0 for VTs
> > > initially created with a user font.
> > > 
> > > Since Debian normally sets a user font before creating VTs 2 and up,
> > > those additional VTs became unusable.  VT 1 also doesn't work correctly
> > > if the user font has > 256 characters, and the bounds check is
> > > ineffective if it has < 256 characters.
> > > 
> > > This can be fixed by backporting the following commits from 5.11:
> > > 
> > > 7a089ec7d77f console: Delete unused con_font_copy() callback implementations
> > > 259a252c1f4e console: Delete dummy con_font_set() and con_font_default() callback implementations
> > > 4ee573086bd8 Fonts: Add charcount field to font_desc
> > > 4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount
> > > a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount
> > > 
> > > These all apply without fuzz and builds cleanly for x86_64 and parisc64.
> > > 
> > > I tested on x86_64 that:
> > > 
> > > - VT 2 works again
> > > - bit_putcs_aligned() is setting charcnt = 256
> > > - After loading a font with 512 characters, bit_putcs_aligned() sets
> > >    charcnt = 512 and is able to display characters at positions >= 256
> > 
> > All now queued up, thanks!
> > 
> > greg k-h
> 
> For what it's worth, now that the above commits are queued up for 5.10.y:
> There are two more commits, which were previously applied to 5.15.y, that
> now apply to 5.10.y without merge conflicts (also without fuzz, if you apply
> the 5.15.y versions of the patches):
> 
> 
> a5a923038d70
> fbdev: fbcon: Properly revert changes when vc_resize() failed
> (previously applied to 5.15.64 and 5.19.6)
> 
> 3c3bfb8586f8
> fbdev: fbcon: release buffer when fbcon_do_set_font() failed
> (previously applied to 5.15.86, 6.0.16, and 6.1.2)
> 
> 
> After looking at these two commits, it seems to me that they are now
> applicable to 5.10.y, and I think they probably should be applied (unless
> I'm overlooking or missing something).

Both now applied, thanks!

greg k-h

[toc] | [prev] | [next] | [standalone]

#90589

From	Thorsten Glaser <tg@debian.org>
Date	2025-12-26 23:10 +0100
Message-ID	<M6mLn-5S9d-1@gated-at.bofh.it>
In reply to	#90580

Dixi quod…

>(Given this, I’m not sure console-setup needs to change here, but
>it’s not entirely unlikely that something may wish to use these
>fonts without the unimap, so IMHO the compilation process should
>make sure that the glyphs #33‥#126 should be their ASCII counter‐
>parts, and that either #32 or #0 should be the empty glyph.

Turns out they do, I inspected the generated unimap, and #32‥#126
do correspond to their ASCII equivalents.

>slightly argue in favour of #32 here, which Linux should then make
>its numbered fallback glyph for unimap-less fonts.)

This, then. (So, basically, the “ch = 0x20;” suggestion from Helge,
except only for unimap-less fonts.)

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :)    15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?	-- ~/.Xmodmap wonders…

[toc] | [prev] | [next] | [standalone]

#90590

From	Thorsten Glaser <tg@debian.org>
Date	2025-12-26 23:10 +0100
Message-ID	<M6ms1-5S26-1@gated-at.bofh.it>
In reply to	#90580

[Multipart message — attachments visible in raw view] — view raw

Salvatore Bonaccorso dixit:

>FTR, there is some progress in
>https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which

Interesting.

No, fonts don’t always have 256 or 512 glyphs, they can have less.

On the laptop where this happens, I use one compiled by
console-fonts, so glyph order is essentially random, but
a patched version thereof with my own 9×18 variant as base,
not the standard fonts from Debian, so that’s likely the
reason I get the currency sign, not the copyright sign.

And, looking at /etc/console-setup/cached_Uni1-Fixed18x9.psf.gz
in hex editor mode, I can indeed see that the unimap for the
first glyph is \xC2\xA4, the currency sign.

I think at this point it is clear that we’re talking about three
separate bugs. Adding the console-setup maintainers to To:.

The one we discovered here is that the fonts autocompiled by
console-setup do not place a blank glyph at index 0, which is
probably expected here.

⚠ Note that using the LAST glyph of a font would be even worse!

This expectation was useful in times when fonts had codepages,
but it is not sensible for PSFU fonts with an unimap. This is the
second bug: the kernel must not use glyph #0 or #32 or so but the
glyph that corresponds to U+0020 in its encoding. (For PSF fonts,
without an unimap, continuing to use a numbered glyph is likely
still the best thing.)

(Given this, I’m not sure console-setup needs to change here, but
it’s not entirely unlikely that something may wish to use these
fonts without the unimap, so IMHO the compilation process should
make sure that the glyphs #33‥#126 should be their ASCII counter‐
parts, and that either #32 or #0 should be the empty glyph. I’d
slightly argue in favour of #32 here, which Linux should then make
its numbered fallback glyph for unimap-less fonts.)

The third bug, however, is that the consoles are spilled full of
those glyphs and that the normal expected output (hostname, the
text "login:", and the shell output when running the shell) does
not show up. That’s the one reported as #1123750. Given it only
occurs on the bullseye kernels, it may be a bug introduced when
backporting the referenced commit.

Helge wrote:

> visible), we could try replacing it by:
> ch = 0x20; /* use ASCII space character */

Looking at (after over three minutes of Anubis overheating my
laptop to 73+°C) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=18c4ef4e765a798b47980555ed665d78b71aeadf
I see that this won’t fly.

“ch” here is not an ASCII codepoint but the glyph index of the
font, which doesn’t need to have an ASCII-based encoding. (In fact,
many don’t because you don’t need to have blank glyphs at 0, 32,
160 for latin1, and 255 for cp437; one blank glyph and an unimapping
suffice.) There belongs some code that looks up the glyph corresponding
to U+0020 and using that instead (ideally, do that at font load time
and store the “blank glyph index” in the font-specific struct).

But, again, that’s just a side bug. This is something I can avoid by
loading a font with a blank glyph at index #0. In fact, let me switch
to Ctrl-Alt-F2 (I’m currently in X) and do that.

… having done that, this results in a mostly blank screen, only the
very first character of the shell prompt is visible, nothing else
at all. That’s the real bug that needs fixing.

My /etc/console-setup/cached_Uni1-Fixed18x9.psf.gz is attached, for
easier reproducing; you can use “setfont cached_Uni1-Fixed18x9.psf.gz”
on a text console you logged in to activate it, or set it as
FONT=/pathto/cached_Uni1-Fixed18x9.psf.gz in /etc/default/console-setup.

I’ve also attached the other font I tested with, which results in
the mostly blank screen.

bye,
//mirabilos, who’s written enough software for fonts himself that
he can handle most common formats

PS: Source for these is in contrib/fonts/fixed/ in MirBSD CVS.
PPS: Mail between me and Googlemail users is extremely likely to fail.
I fully blame Google.
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist

[toc] | [prev] | [standalone]

csiph-web

Bug#1123750: linux: regression: virtual consoles 2-12 unusable

Contents

#90548 — Bug#1123750: linux: regression: virtual consoles 2-12 unusable

#90549 — Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable

#90550

#90551

#90580

#90581 — Processed: Re: Bug#1123750: linux: regression: virtual consoles 2-12 unusable

#90586

#90591

#90592

#90655 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

#90748 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

#90986 — Bug#1123750: [5.10] regression: virtual consoles 2-12 unusable

#90589

#90590