Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally]

Sat Oct 4 00:45:22 UTC 2014

I've not been using any tier 1 FreeBSD environments to compare/contrast the below with: just powerpc and powerpc64, both only with PowerMacs. This note is FYI in case the comparison/contrast with what others report for tier 1 might have tier 1 implications. The XOrg context is 1.12.

Context for this note: powerpc64/GENERIC64 using vt vs. sc for NVIDIA 7800 GT's and Radeon X1950's on PowerMac G5 Quad cores, various 10.?-???'s since this environment switched to vt. In this context kern.vty=vt is automatic and for an unmodified GENERIC64 sc is not available (because of ps3 not supporting sc but being supported by an unmodified GENERIC64). More build/configuration details at the bottom of this message.

Note: It takes a special GENERIC64 variant with ps3 disabled in order to have sc available. Very recently [10.1.-BETA3] I've done that so I could try sc. It takes kern.vty=sc to get to the sc environment when it is so added to GENERIC64.

NVIDIA 7800 GT in that type of PowerMac G5: Nearly black text on black background problems for vt console switching from Xorg/xfce4 but normal text display for sc...

For my context when vt is used with Xorg 1.12 and xfce4 (the only context I've used) for the 7800 GT cards switching back to a console window (Control/Option-Fn) displays nearly black text on a black background. It is so near black that, depending on which display and the lighting, I may or may not be able to read the text on careful examination. Normally I can at least tell that something is being displayed. But originally I though it was a black screen until one time the lighting was such that I noticed the slight difference and investigated further. The tail of Xorg.0.log after Control/Option-F2  with "black on black" resulting ended up having no messages from after startxfce4 finished starting:

[    81.598] (**) Apple Optical USB Mouse: (accel) keeping acceleration scheme 1
[    81.598] (**) Apple Optical USB Mouse: (accel) acceleration profile 0
[    81.598] (**) Apple Optical USB Mouse: (accel) acceleration factor: 2.000
[    81.598] (**) Apple Optical USB Mouse: (accel) acceleration threshold: 4
[    81.598] (II) Apple Optical USB Mouse: SetupAuto: hw.iftype is 4, hw.model is 0
[    81.598] (II) Apple Optical USB Mouse: SetupAuto: protocol is SysMouse

Returning to xfce4/Xorg and logging out added:

[   379.126] (WW) xf86EnableIO 7
[   397.600] (II) UnloadModule: "kbd"
[   397.600] (II) UnloadModule: "mouse"
[   398.642] Server terminated successfully (0). Closing log file.

so nothing unusual. (Nothing odd for the earlier parts either.) Logouts also produce the "black on black" display issue for the console, even if there was no prior switching to/from a console.

sc does not have this problem for the 7800 GT's when I use kern.vty=sc: I can switch back and forth between Xorg/xfce4 and consoles or log out just fine when using sc and the console displays end up normal/readable. The tail of Xorg.0.log for an example of this ended up being:

[   163.091] (**) Apple Optical USB Mouse: (accel) acceleration profile 0
[   163.091] (**) Apple Optical USB Mouse: (accel) acceleration factor: 2.000
[   163.091] (**) Apple Optical USB Mouse: (accel) acceleration threshold: 4
[   163.091] (II) Apple Optical USB Mouse: SetupAuto: hw.iftype is 4, hw.model is 0
[   163.091] (II) Apple Optical USB Mouse: SetupAuto: protocol is SysMouse
[   184.174] (WW) xf86EnableIO 7
[   184.208] (**) Option "BaudRate" "1200"
[   184.209] (**) Option "StopBits" "2"
[   184.209] (**) Option "DataBits" "8"
[   184.209] (**) Option "Parity" "None"
[   184.209] (**) Option "Vmin" "1"
[   184.209] (**) Option "Vtime" "0"
[   184.209] (**) Option "FlowControl" "None"
[   212.917] (WW) xf86EnableIO 7
[   515.033] (II) UnloadModule: "kbd"
[   515.034] (II) UnloadModule: "mouse"
[   516.427] Server terminated successfully (0). Closing log file.

So for NVIDIA 7800 GT's on PowerMac's I'd expect that it is not any vt vs. sc environment independent code that is the problem but something specific to the vt context in some way.

Radeon X1950 in the same sort of PowerMac G5, using vt as the example context: Why I can not test console switching for such a Radeon context...

For 10.1-BETA3 the boot-time vt console display works for 1920x1200 but not (usefully/readably) for 2560x1440. So the following notes are for a 1920x1200 context. (10.1-BETA2 had different behavior and was usable for 2560x1440 despite a temporary display oddity during booting. But I'm not going down this path here. I'm pointing out a different XOrg issue.)

My attempt to test a Radeon X1950 in such a PowerMac G5 shows that XOrg does not get very far:

[    63.468] (WW) xf86EnableIO 7
[    63.468] (WW) Falling back to old probe method for vesa
[    63.468] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    63.468] (II) RADEON(0): TOTO SAYS 0000000090000000
[    63.468] (II) RADEON(0): MMIO registers at 0x0000000090000000: size 64KB
[    63.469] (II) RADEON(0): PCI bus 10 card 0 func 0
[    63.469] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[    63.469] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[    63.469] (==) RADEON(0): Default visual is TrueColor
[    63.469] (**) RADEON(0): Option "NoAccel"
[    63.469] (II) RADEON(0): VGAAccess option set to FALSE, VGA module load skipped
[    63.469] (==) RADEON(0): RGB weight 888
[    63.469] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[    63.469] (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID = 0x7240)
[    63.469] (--) RADEON(0): Linear framebuffer at 0x0000000098000000
[    63.469] (II) RADEON(0): PCI card detected
[    63.469] (WW) RADEON(0): Failed to read PCI ROM!
[    63.469] (II) RADEON(0): Attempting to read un-POSTed bios
[    63.469] (WW) RADEON(0): Failed to read PCI ROM!
[    63.469] (WW) RADEON(0): Unrecognized BIOS signature, BIOS data will not be used
[    63.469] (II) UnloadModule: "radeon"
[    63.469] (EE) Screen(s) found, but none have a usable configuration.
[    63.469] 
Fatal server error:
[    63.469] no screens found

The X1950 card works fine in Mac OS X 10.5 on the same PowerMac G5 Quad core. (It is the only Radeon for a PCI Express based PowerMac that I have access to.)

My attempt to side step this with use of xf86-video-scfb and a matching xorg.conf did not work either (note also the 'depth (32)' below vs. the 'depth (24)' above, not just the 'Weight given (000)' below):

[   321.133] (II) LoadModule: "scfb"
[   321.134] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[   321.134] (II) Module scfb: vendor="X.Org Foundation"
[   321.134]    compiled for 1.12.4, module version = 0.0.4
[   321.134]    ABI class: X.Org Video Driver, version 12.1
[   321.134] (II) scfb: driver for wsdisplay framebuffer: scfb
[   321.154] (--) Using syscons driver with X support (version 8595229351.252)
[   321.154] (--) using VT number 9

[   321.154] (WW) Falling back to old probe method for scfb
[   321.154] scfb trace: probe start
[   321.154] (II) scfb(0): using default device
[   321.154] scfb trace: probe done
[   321.154] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   321.154] scfb: PreInit 0
[   321.154] (II) scfb(0): Using: depth (32),   width (1920),    height (1200)
[   321.154] (**) scfb(0): Depth 32, (--) framebuffer bpp 32
[   321.154] (EE) scfb(0): Weight given (000) is inconsistent with the depth (32)
[   321.154] (II) UnloadModule: "scfb"
[   321.154] (EE) Screen(s) found, but none have a usable configuration.
[   321.154] 
Fatal server error:
[   321.154] no screens found

Additional PowerMac G5 FreeBSD configuration details for the current 10.1-BETA3 status/tests:

FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #31 r272167M: Tue Sep 30 22:50:33 PDT 2014     root at FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64  powerpc

/usr/src:

$ svnlite info /usr/src
Path: /usr/src
Working Copy Root Path: /usr/src
URL: https://svn0.us-west.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 272167
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 272167
Last Changed Date: 2014-09-26 02:52:39 -0700 (Fri, 26 Sep 2014)

$ svnlite status /usr/src
?       /usr/src/.snap
?       /usr/src/restoresymtable
M       /usr/src/sys/ddb/db_script.c
M       /usr/src/sys/powerpc/conf/GENERIC64
M       /usr/src/sys/powerpc/ofw/ofw_machdep.c

The PowerMac G5's have some early-boot crash problems and the db_script.c and ofw_machdep.c changes are for displaying some information on screen for before any input is possible, some of it during the crash handling and some of it before the potential crash.

The GENERIC64 variant now in use disables ps3, adds sc, and has the DDB and GDB options added. Those last two are associated with the above before/during-early-crash information display and have been involved from before I started disabling ps3 and adding sc.

/etc/make.conf:

$ more /etc/make.conf
WITH_DEBUG_FILES=
WITHOUT_CLANG=
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=

(Most of the behavior has been tested on an SSD that only had the WRKDIRPREFIX line and without the db_script.c/ofw_machdep.c changes and all of it tested repeated in that context. The only reason for WITHOUT_CLANG= is because clang's build was failing when WITH_DEBUG_FILES= was present. powerpc/powerpc64 is not clang based as of 10.1-BETA3 (or likely any time soon as far as I can tell).)

$ more /boot/loader.conf
verbose_loading="YES"
kern.vty=vt

(or with kern.vty=sc instead as appropriate).

I am copying my appropriate machine/device/driver-specific xorg.conf file to /etc/X11/xorg.conf when I switch contexts that are not the same video configuration. I do not bother listing them here.

/usr/ports:

$ svnlite info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 369514
Node Kind: directory
Schedule: normal
Last Changed Author: olgeni
Last Changed Rev: 369514
Last Changed Date: 2014-09-29 03:44:00 -0700 (Mon, 29 Sep 2014)
$ svnlite status /usr/ports
?       /usr/ports/.snap
?       /usr/ports/restoresymtable

(I.e., no changes to the ports compared to r369514.)

===
Mark Millard
markmi at dsl-only.net