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]

[Mark Millard]

[This is another reply to Jean-Sébastien Pédron's Sat Oct 4 15:31:47 UTC 2014 reply to my notes about how things are on PowerMac G5's.  This note is just about attempting use a build of the kernel from the kms-drm-update-38 source code.]

Context: PowerMac G5's with PCI-Express and 2 processors with dual cores and the kms-drm-update-38 kernel. Some use 12 GBytes RAM other use 16 GBytes RAM.



Radeon X1950 for 2560x1440: A pure black screen for boot after the clear that FreeBSD does of the openfirmware black-text on white background stage of booting, no evidence is anything else in any lighting. So this is somewhat different from 10.1-RC1/BETA3 but not like 10.1-BETA2. (The X1950 card is fairly recently available to me and I've never tried it with anything before 10.1-BETA2 or so.)

(With the general, long-known PowerPac G5 boot-hang problems I'd not conclude much from the apparent hangs I got for this context.)



Radeon X1950 for 1920x1200: The boot text is fine. Xorg behavior is no different than with 10.1-RC1/BETA3/... The same Xorg.0.log messages result and the same failures to find a screen to use happens. (scfb too.) (Xorg -configure produced xorg.conf.new being a match to my usual xorg.conf_radeon_pciex that I copy to /etc/X11/xorg.conf when I switch the SSD to the X1950 based G5.)



GeForce 7800 GT (used with 1920x1200): boot/console display is fine but Xorg/xfce4 had display problems that I've never seen before.

As I moved the mouse around similar, smaller scale shapes were drawn up towards the top of the screen (compared to the mouse position), with that shape pattern repeating going across the screen.

When I closed windows blocks of mostly black (rectangular) would be drawn in the same sort of areas. Again a repeating pattern going across the screen.

The nearly black text on black display problem was present when switching to consoles from Xorg/xfce4.



Other points: the boots with that kernel consistently reported...

lock order reversal:
 1st 0xad67d50 ufs (ufs) @ /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/kern/vfs_subr.c:2137
 2nd 0xc0000000d0434fb8 bufwait (bufwait) @ /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/ufs/ffs/ffs_vnops.c:262
 3rd 0xad67418 ufs (ufs) @ /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/kern/vfs_subr.c:2137
KDB: stack backtrace:
0xc000000115f97fb0: at .kdb_backtrace+0x5c
0xc000000115f980e0: at ._witness_debugger+0x3c
0xc000000115f98170: at .witness_checkorder+0xa7c
0xc000000115f98260: at .__lockmgr_args+0x9d4
0xc000000115f983a0: at .ffs_lock+0xa8
0xc000000115f98450: at .VOP_LOCK1_APV+0x158
0xc000000115f984e0: at ._vn_lock+0x88
0xc000000115f985d0: at .vget+0x88
0xc000000115f98680: at .vfs_hash_get+0x12c
0xc000000115f98740: at .ffs_vgetf+0x60
0xc000000115f98830: at .softdep_sync_buf+0xbd0
0xc000000115f98980: at .ffs_syncvnode+0x278
0xc000000115f98a60: at .ffs_truncate+0x6cc
0xc000000115f98ca0: at .ufs_direnter+0x9cc
0xc000000115f98dd0: at .ufs_makeinode+0x5bc
0xc000000115f98ff0: at .ufs_create+0x44
0xc000000115f99070: at .VOP_CREATE_APV+0x14c
0xc000000115f99100: at .vn_open_cred+0x1e0
0xc000000115f992c0: at .vn_open+0x24
0xc000000115f99340: at .kern_openat+0x284
0xc000000115f99520: at .kern_open+0x34
0xc000000115f995a0: at .sys_open+0x28
0xc000000115f99620: at .trap+0x564
0xc000000115f99880: at .powerpc_interrupt+0x1e0
0xc000000115f99920: user SC trap by 0x502d4af8: srr1=0x900000000000d032
            r1=0xffffffffffffa3e0 cr=0x48004082 xer=0x20000000 ctr=0x502d4af0

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