Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 162980 - Some recent change in a startup makes a text console unusable
Summary: Some recent change in a startup makes a text console unusable
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-11 23:05 UTC by Michal Jaegermann
Modified: 2014-03-17 02:54 UTC (History)
1 user (show)

Fixed In Version: 8.16-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-03 21:25:08 UTC
Type: ---

Attachments (Terms of Use)
all modules loaded with a display junked (1.79 KB, text/plain)
2005-07-12 04:27 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2005-07-11 23:05:00 UTC
Description of problem:

When booting in a text mode everything looks normal until the moment when
prints on a screen "Initializing hardware... storage network audio"
and before a final "done" is printed a screen blinks and comes back
with a tall and narrow font, with a serious barrel distortion, and a
text column on screen becomes also tall and narrow with top and bottom rows
way beyond display borders (but with wide margins on left and right).

I understand that startup is supposed to load only some kernel modules but it
seems to have other side-effects because if I am booting older kernels,
where this distortion was previously absent, I am getting the same
treatment.  Even attempts to specify some other vga modes end up with
the same messed up console.  Font is changes until initrd starts.  Then
it goes back to a normal 80x25 system font and few moments later I am back
staring at unusable display.

If booting to level 1 I see the following modules loades after sound
modules (where video was yet normal):

dm_mod                 68625  0 
video                  23497  0 
button                 12257  0 
battery                15433  0 
ac                     10057  0 
ohci1394               42273  0 
ieee1394              379865  1 ohci1394
uhci_hcd               41441  0 
ehci_hcd               41421  0 
radeonfb              135069  1 
i2c_algo_bit           14281  1 radeonfb
shpchp                103529  0 
i2c_viapro             13657  0 
i2c_core               29505  3 radeonfb,i2c_algo_bit,i2c_viapro

Any ideas what gives?  There is apparently a new message in logs:

Console: switching to colour frame buffer device 90x25

and this is likley screwing me up.

Version-Release number of selected component (if applicable):

How reproducible:
always - unfortunately

Comment 1 Michal Jaegermann 2005-07-12 00:32:18 UTC
I think that maybe just updated 'udev' may be reponsible for this mess.  But
if this is really the case it is really not clear to me how to prevent it
from doing what it is doing.  I did not get much wiser looking through
documentation and udev config files.

Comment 2 Bill Nottingham 2005-07-12 02:47:30 UTC
Can you get a lsmod on the screwed up display? (via remote login, for example.)

Comment 3 Michal Jaegermann 2005-07-12 04:27:24 UTC
Created attachment 116635 [details]
all modules loaded with a display junked

This is an lsmod output in the original report while booted into level 1
(so various other modules are not loaded yet and taken mostly "in blind" :-).
At least that part which comes after sound modules when video is still good.
If you want to see the whole thing, still from a boot to a level 1, it is
attached here.	Unfortunately I do not have a similar listing from "before".

"Console: switching to colour frame buffer device 90x25" message comes
from .../drivers/char/vt.c; but why this was not happening previosly, and how
to prevent that from showing up, I still have no idea.

Comment 4 Bill Nottingham 2005-07-12 04:34:37 UTC
Hm, nothing here that would screw with video (in theory).

Are you using rhgb?

Comment 5 Michal Jaegermann 2005-07-12 05:02:49 UTC
No, there is no rhgb.  These are "pure runlevel 1" boots and with selinux
turned off as well.

I booted an i386 machine also with radeon video card but which lacks
sound and with "simpler" other things.  A console is also unusable there
but a list of modules loaded at level 1 is shorter.  Here it is:

Module                  Size  Used by
dm_mod                 59741  0 
video                  19909  0 
button                 10577  0 
battery                13381  0 
ac                      8773  0 
ohci_hcd               26209  0 
radeonfb              127773  1 
i2c_algo_bit           13257  1 radeonfb
i2c_amd756             10437  0 
i2c_core               24897  3 radeonfb,i2c_algo_bit,i2c_amd756
3c59x                  45673  0 
mii                     9409  1 3c59x
floppy                 62613  0 
ext3                  133833  2 
jbd                    61913  1 ext3

The same "Console: switching to colour frame buffer device 90x25" showed
up there as well and this is definitely something new.  It comes in the
following context:
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 18 (level, low) -> IRQ 185
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=145.00 Mhz, System=145.00 MHz
radeonfb: PLL min 12000 max 30000
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Console: switching to colour frame buffer device 90x25
radeonfb (0000:02:06.0): ATI Radeon QY 
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)

but, as I mentioned before, even with kernels even with kernel which were
not doing that before.  Hm, 'module-init-tools' were updated too.

Actually on the recent try that i386 box on a reboot switched video,
printed " ... done    [OK]" and immediately died in a startup sequence.
SysRq key was not turned on yet, so even that is ineffective.  Power button

The last one operation turned out to be "interesting".  After taking that
machine down I had to unplug it entirely and wait around a minute before 
I was able to power it up again.  Before that there was no reaction on 
a power button at all.  I do not remember seeing ever a non-laptop machine
messed up to such extent.

Comment 6 Bill Nottingham 2005-07-12 05:07:10 UTC
So, presumably if you have "install radeonfb /bin/true" in /etc/modprobe.conf,
this doesn't happen?

Comment 7 Michal Jaegermann 2005-07-12 05:13:00 UTC
Yes, in the meantime I just put "install radeonfb :" into my /etc/modprobe.conf
and my console display is sane again (and no radeonfb on my list of modules).
Somebody was way too kind for me.  Sigh!

Comment 8 Bill Nottingham 2005-07-12 05:19:15 UTC
Which modutils do you have installed?

Comment 9 Bill Nottingham 2005-07-12 05:21:19 UTC
Erm, module-init-tools. *whack*.

Comment 10 Michal Jaegermann 2005-07-12 05:31:14 UTC
Yes, indeed, module-init-tools-3.2-0.pre7.1.  Was in a pile of rawhide
updates which I put in today.

Something apparently also added 'include /etc/modprobe.d' at the bottom
of my /etc/modprobe.conf with such effect that whatever was in this directory
was added twice; once before what I have in /etc/modprobe.conf, apparently
automatic,  and the second time after.  I thought that the latest re-definition

Comment 11 Bill Nottingham 2005-07-12 06:30:52 UTC
Actually, a change was made to automatically include /etc/modprobe.d; I'd
suspect that you had the include there already.

Comment 12 Michal Jaegermann 2005-07-12 14:57:19 UTC
> suspect that you had the include there already

No.  At least not in an explicit form.  At this moment there are there no
include directives and if I will do 'modprobe -c | less' the I see first
a content of files in /etc/modprobe.d, so it looks that this inclusion
is automatic, followed by all lines from /etc/modprobe.conf.  After that
there is a big chunk after "# Aliases extracted from modules themselves."

What is more, although I do not see that documented anywhere, files from
/etc/modprobe.d seem to be included by name in a _reverse_ alphabetical
order.  I happen to have an extra file there.  That could be a coincidence
and that may be really an order given by 'find' (so this will be 'readdir()'?).

If I will put back the last line with 'include /etc/modprobe.d', then
'modprobe -c | less' shows lines from modprobe.d, lines from modprobe.conf,
lines from modprobe.d files again, and after that "Aliases extracted from
modules themselves".

Comment 13 Bill Nottingham 2005-10-03 21:25:08 UTC
This should be fixed in current rawhide - the blacklisting was broken.

Comment 14 Michal Jaegermann 2005-10-03 21:51:49 UTC
Indeed, in an output of 'modprobe -c' I see now 'blacklist radeonfb' and
this likely has similar effects like 'install radeonfb :' :-) although I do
not see that documented anywhere save some comments in /etc/modprobe.d/blacklist

Comment 15 Bill Nottingham 2005-10-03 21:54:48 UTC
Actually, that was there before (it's pulled from /etc/modprobe.d/blacklist.)

The problem was that initscripts wasn't looking at that file (oops).

Note You need to log in before you can comment on or make changes to this bug.