SRU justification:
Impact: The use of 512 character fonts on a vga console is broken since
seemingly ever until now somebody noticed. While not being a panic spreading
issue it can simply be fixed.
Fix: Let the get_font function return the complete character set and not
only the first 256 characters, while pretending to have done all. Fix
sent to upstream (accepted into -mm)
Testcase: Call showconsolefont after loading a 512 character font and do not
panic (seems to be another bug in there), switch console and back and the
second half of the font is corrupted.
---
This issue has been reported several times before in various
forms. Typically about one national character missing. I try to
summarize all information I have collected in this new general report
and mark the earlier reports about special cases as duplicates.
Several non-ASCII characters get corrupted in the framebuffer
console. (see attached photos) This happens when returning from X back
to the console using Ctrl-Alt-F1 ... Ctrl-Alt-F6.
The characters are are displayed correctly when booting into single
user mode and not starting X. (see attached
intrepid-single-user-OK.jpg) So the problem is not incomplete font
implementation or some locale issue. This is why I report the bug to
the kernel instead of to console-setup, if feels that console-setup
should not cause random pixel "characters" (But of course the bug could
really be somewhere else. I'm far from understanding completely how
this all works.) I also attach my /etc/defaults/console-setup
Actually the problem is described in /usr/share/doc/console-setup/FAQ.gz
However, it says that this happens only in text mode, not in framebuffer
mode. So how can I find out in which mode my console is actually running?
I believe that my console should be in framebuffer mode, because:
$ lsmod | grep fb
fbcon 47648 0
tileblit 10880 1 fbcon
font 16512 1 fbcon
bitblit 13824 1 fbcon
However there is a file /etc/modprobe.d/blacklist-framebuffer and it says
# Framebuffer drivers are generally buggy and poorly-supported, and cause
# suspend failures, kernel panics and general mayhem. For this reason we
# never load them automatically.
So do we use fbcon, but not the underlaying framebuffer???
Some documentation is here http://www.mjmwired.net/kernel/Documentation/fb/fbcon.txt, but I'm still confused.
The problem is not specifc to the reported kernel version. I see it
also with the current Hardy kernel and the Jaunty Beta LiveCD (see
jaunty-liveCD.jpg). The problem is not specific to the reported
grahics card. I see it also on Nvidia, on Radeon, and also on the
virtualized card created by VMware. The previously reported bugs (now
linked as duplicates) cover also various hardware and software
configurations.
I have tested the range Unicode U+00A0 ... U+00FF, my console coding
is UTF-8. http://www.utf8-chartable.de/ can be used for
referece. (From the previousily reported national character issues I
conclude that also characters outside this range are affected)
You can easily test yourself using the attached file
$ cat sampletable.txt
The character corruption comes in 2 different forms:
- Random pixel character range: All characters between and including
U+00E9 and U+00FF are corrupted. Often the pixels are completely
random (See attached intrepid-random-pixel-range.jpg) and they are
different on each console tty1, tty2, ... Sometimes they are just
all white or black.
The somehow weird thing is that the U+00E8 (e grave) is always the
last character displayed correctly, whereas U+00E9 (e acute) is
always the first corrupted character.
- missing accents. There is no random corruption in this case, but
accents are missing from capital letters. It looks more like an
intentional low-grade variant of the font. Accents are present on
lowercase letters. A couple of very rare characters (e.g. thorn)
are displayed as white blocks. (see attached
intrepid-no-accents.jpg) I guess this variant of the problem may
lead to the belief that a certain configuration is not affected, if
you just test a couple of lowercase characters.
The same kernel on the same machine can sometimes show "random pixel
character range" and sometimes "missing accents". E.g. when boot first
into single user mode and start your X later in contrast of starting
everything the standard way. (intrepid-random-pixel-range.jpg and
intrepid-no-accents.jpg are from the same machine using the same kernel)
P.S. Not sure how important this problem really is. I started to dig
when investigating some serious display corruption (affecting also X
on framebuffer 7) So originally I thought if even the console gets
corrupted things are really bad. But in the meantime I have come to
the conclusion that this character corruption is most likely a
completely different issue from my original problem. For me personally
non-ASCII characters on the console are of minor importance. On the
other side according to Ubunutu philosophy software should be
available in the user's local language. This of course requires that
national characters work, if somebody works on the console.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
Package: linux-image-2.6.27-14-generic 2.6.27-14.30
ProcCmdLine: root=UUID=f6bf9b65-0cad-45bd-b3a0-a7353a3900af ro quiet splash
ProcEnviron:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
LANG=fi_FI.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.27-14.30-generic
SourcePackage: linux
Oops launchpad does not really display the file name.
Picture 1/4 was intrepid-
Picture 2/4 was intrepid-