From: Benjamin Herrenschmidt <benh@ke...> - 2003-11-15 02:12:38
There's something I don't understand with the way fbdev's and
fbcon are supposed to be initialized.
So the problem started when working on the ppc64 kernel tree on
the G5, radeonfb for some reason why displaying crap. After some
tracing, it appeared that the "fix" structure wasn't initialized
After more digging, it appeared that a different IBM 64 bits
machine experienced the same problem with 2 video cards in it
(the G5 had only one though...). Tracing on that later machine,
it appeared that the problem came from fbcon_startup() doing:
info = registered_fb[num_registered_fb-1];
That is, it picked the _last_ registered fbdev and called
open(), set_par(), etc.... on that (matroxfb in this case). But the
con2fbmap was full of zeros, and thus, fbcon actually used the _first_
registered fbdev (radeonfb here) to draw, thus drawing using an
fbdev on which it didn't do open, set_var, etc... with an uninitialized
"fix" structure (well, partially uninitialized).
Changing the above line to registered_fb fixed it for this. The
G5 was still broken though. The symptom was exactly the same, leading
me to think it was all about a "fix" init. issue though. I didn't have
time to go deep into what was going on. I just noticed that if I added
those 2 lines in the arch code of ppc64 that we had on ppc32 and not
on ppc64, it made things work (there are executed from setup_arch(),
that is very early during the boot process):
conswitchp = &dummy_con;
This is quite mysterious to me. It seems the fbcon layer is cery fragile
in the way it decides to initialize vs. use an fbdev. Shoud I go back
doing what I did in early 2.5 days and just for a set_var of the default
mode from the driver themselves just before registering ?
Also, I'm having reports of similar problems when radeonfb and/or fbcon
are used as modules (that is mismatch or absent call to initial
Get latest updates about Open Source Projects, Conferences and News.