With kernel 2.4, dmesg shows an Elite graphics card as "fbx Elite 3D", where 'x' is the actual /dev/fbx number. With kernel 2.6, the same card is reported as ffb: AFB at ...... As a result, afbinit can no longer detect an Elite card, because it relies on the "Elite 3D" line(s) in the dmesg report. It needs to use the AFB style as an alternative (and it needs a way to sort out which /dev/fb/x devices are Elite and which are something else, in the case of a system with several frame buffers of different types, such as one Creator, one Elite) Reproducible: Always Steps to Reproduce: 1.Install kernel 2.6.6 and boot it on your Elite3D system 2.Notice that "Elite 3D" is now AFB, and that the microcode for it is not loaded 3.Watch -X- die because it needs the microcode to run properly Actual Results: Microcode not loaded Expected Results: Microcode for Elite should be loaded Portage 2.0.50-r6 (default-sparc64-1.4, gcc-3.3.3, glibc-2.3.2-r9,2.2.5-r2, 2.6.6) ================================================================= System uname: 2.6.6 sparc64 sun4u Gentoo Base System version 1.4.10 ccache version 2.3 [disabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="sparc" AUTOCLEAN="yes" CFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" CHOST="sparc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe -Wno-deprecated" DISTDIR="/usr/portage/distfiles" FEATURES="cvs sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://ftp-mirror.internap.com/pub/gentoo/ ftp://mirrors.tds.net/gentoo ftp://ftp.ndlug.nd.edu/pub/gentoo/ http://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X Xaw3d avi berkdb cdr crypt cups encode fbcon foomaticdb gdbm gif gpm gtk guile imlib java jpeg libwww mad mikmod motif mozilla mpeg mpi mysql ncurses nls opengl pam pdflib perl png python qt readline ruby ruby18 sdl slang sparc spell ssl stroke tcltk tcpd tetex tiff truetype xml2 xmms xv zlib"
I'm assigning this to myself for now, because evidence suggests that I am the only one with this configuration (but this will change). The symptom is dramatic enough that anyone with Elite+kernel-2.6.6 will see it (unless I am the only one for whom the dmesg frame buffer report has changed, which I doubt.) The first part of the problem --- recognizing an alternative form of Elite FB report --- is easily fixed. The second part --- sorting out just what devices the various /dev/fb/x entries are --- I am not sure of. And loading the microcode into a Creator is catastrophic, so for completeness, part of the fix has to be identification of what the frame buffers are when there is more than one.
A bit more information, as a note: If you have kernel 2.6.6, U60, first frame buffer is ffb2+, second Elite-m3 (afb), dmesg reports this: ==================== ffb: FFB at 000001fc00000000 type 51 DAC 10 ffb: AFB at 000001fa00000000 type 39 DAC 10 ==================== And the /dev tree for them looks like: ==================== /dev/fb: total 0 0 drwxr-xr-x 2 root root 0 May 10 23:26 ./ 0 drwxr-xr-x 12 root root 0 May 25 22:12 ../ 0 crw------- 1 fmccor root 29, 0 May 10 23:26 0 0 crw------- 1 fmccor root 29, 1 May 25 21:24 1 ===================== So, the problem is which is which? (In this case, /dev/fb0 --> /dev/fb/0 is the ffb2+) ================================== Well, xorg finds them on startup like this: (--) SBUS:(0xf006e4f0) Sun FFB2+ Vertical Creator 3D at /SUNW,ffb@1e,0 (--) SBUS:(0xf00766bc) Sun Elite3D at /SUNW,afb@1d,0 ================================ And, since we are display :0.0 (I think), it picks /dev/fb0, which indeed is the creator: ================================ (II) /dev/fb0: Detected FFB2+/vertical, Z-buffer, Double-buffered. (II) /dev/fb0: BT498 (PAC2) ramdac detected (II) /dev/fb0: Detected Creator/Creator3D ================================ Of course, the ffb/afb driver sunffb knows what it is doing, and it can probe /dev/fb0 to figure out what it is. The problem we have here, though, is that the afbinit script doesn't know how to probe the device, and neither do I. So --- feel free to chime in here --- how at startup time do I take the facts that (1) I have 1 afb on the system (dmesg tells me that); (2) I have two frame buffers (/dev/fb/0, /dev/fb/1 tell me that, as also does dmesg); and figure out which one needs the microcode and which one will really hate me if I feed it the microcode? I guess you can take them in order (count the ffb lines, match them with /dev/fb/x devices, and load the microcode into the /dev/fb/x devices which correspond to ffb: AFB lines)?? Related question: are we talking a maximum of 2 frame buffers? For the U60 that's true, but what about other systems?
As Weeve suggested, with kernel 2.6, "cat /proc/fb" can be used to identify the frame buffers, just as "dmesg" can be used with kernel 2.4 (actually, to store the value anywhere, you need "cat -s"): E.g., on a 2 frame buffer U60, I see: =========== 0 Creator 3D 1 Elite 3D =========== and /dev/fb/1 is in fact the Elite card. So, if the initial "dmesg" check notices an entry "ffb: AFB", then the script should use afb_devs=`/bin/cat -s /proc/fb | /bin/egrep -i "Elite 3D" | /bin/sed 's/\ .*//'` to collect the list of Elite cards, then the corresponding loop to load microcode becomes: =========== # Load microcode onto each card. for AFB in ${afb_devs} do echo -n "/dev/fb/${AFB}: Loading Elite3D microcode... " /usr/sbin/afbinit /dev/fb/${AFB} /usr/lib/afb.ucode echo "done." done =========== So unless someone provides more information, this looks like a safe approach for modifying the afb init script to work with both kernel series.
Proposed fix in cvs as afb-1.0.1-r2. (I will change the '-sparc' mask to '~sparc' after I get a chance to check it on a dual fb system.)
afbinit-1.0.1-r2 (marked ~sparc in cvs) fixes this for kernel 2.6.x on single afb system and (ffb+afb) system. So I'm marking this fixed. If anyone has any problems with this version, please reopen.
