10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now...

Wed Oct 1 04:50:12 UTC 2014

Multiple thanks (size handling improvement, scfb hint, earlier notes on experimenting with the code, and what should be true of what I asked about)!

I portmaster'd xf86-video-scfb. Unfortunately it does not work for my most-of-interest context for it: Radeon X1950. scfb ends up unloaded instead.

I initially tried it for the GeForce 7800 GT based PowerMac G5 Quad core. Xorg.0.log which reported needing 8 bit depth. With that fixed in xorg.conf the result was a display with odd colors, mostly lots of red as I remember, but it was doing something.

So I tried the same SSD in the Radeon X1950 G5 Quad core PowerMac. Xorg.0.log reported needing 32 bit depth. But fixing that in xorg.conf that was not enough to make it work: it then complained about "(EE) scfb(0): Weight given (000) is inconsistent with the depth (32)" and then unloaded scfb. From Xorg.0.log:

...
[   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

(Side note: It is too bad that Xorg says "Using syscons driver ..." for vt contexts. That mislead me originally.)

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

On Sep 30, 2014, at 4:21 PM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:

OK, we can bump the max screen size. As an aside, if you use vt(4) instead of syscons, you can use X even on unsupported cards with the xf86-video-scfb driver. It will be unaccelerated, but it will work.
-Nathan

On 09/30/14 14:36, Mark Millard wrote:
> I tried the 1920x1200 display instead of the 2560x1440 one and it then worked. I should have thought of that test.
> 
> 10.1-BETA2 used the whole screen for 2560x1440, although for a while the far right hand side would show the start of the next line as well (buffer width wrap). I prefer 10.1-BETA2's behavior for the size issue to what happens now under 10.1-BETA3 (useless display).
> 
> But (new experiment) the 2560x1440 display works when the card is a GeForce 7800 GT instead of the Radeon X1950 (same boot SSD, same type of PowerMac G5: Quad core). For the 7800 GT it just uses a small area in the middle as the console instead of trying to use the whole display. (Too bad it is as small as it is but it does work. I'd not be able to see all the text from my early-crash DDB dumps in the little area used. For now having lots of lines during boot is important for my context.)
> 
> (Xorg does not seem to handle the X1950, leaving console mode as the only option with that card. I can revert to another 7800 GT if I decide it is appropriate.)
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On Sep 30, 2014, at 8:24 AM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
> 
> What is your screen resolution? I suspect you are overflowing vt's early-boot framebuffer area. syscons is not supported on PS3, but you can remove PS3 from your kernel configuration to use it on powermacs.
> -Nathan
> 
> On 09/29/14 03:21, Mark Millard wrote:
>> 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI Radeon X1950" (ChipID = 0x7240)' card with vt: boot text is only a couple of pixels high/wide. Unreadable. Repeat the visual pattern across the screen (across, not down). [Note: This is not an Xorg/xfce4 issue in any way.]
>> 
>> And it appeared to be stopping very early every time so I've no clue what it was reporting.
>> 
>> 
>> Context (uname -a taken from a working boot context for the same SSD, see later):
>> 
>> FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep 29 02:34:31 PDT 2014     root at FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64  powerpc
>> 
>> Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES= WITHOUT_CLANG= WITH_DEBUG= in /etc/make.conf . DDB default script hack for dumping early-boot crash information. Added db_trace_self() call executed during first openfirmware_core call with MMU programmed. (So just before the classic before-copyright hang where OF_peer(0) fails fairly frequently.)
>> 
>> (That is the same context as for the prior 10.1-BETA2 activity. 10.1-BETA2 did not have this problem for this context.)
>> 
>> 
>> 
>> 
>> I tried reverting to using sc in GENERIC64 using the same 5 lines or so for sc that are in GENERIC. But it got build failure: ps3fb_remap was missing because ps3_syscons.c was not compiled.
>> 
>> That in turn was because sys/conf/files.powerpc listed "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not needed for syscons builds?). I changed that to "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again.
>> 
>> More such sys/conf/files.powerpc and/or sys/conf/files issues showed up preventing building for sc.
>> 
>> I gave up on being able to build powerpc64/GENERIC64 for sc directly and rebuilt again with vt (despite the boot results for the Radeon context).
>> 
>> (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual unload then load /boot/kernel.good/kernel then boot sequence from from not letting the G5 time out and autoboot. 10.1-BETA3's world seems to tolerate 10.1-BETA2's kernel. Otherwise this would have been a lot messier to deal with.)
>> 
>> 
>> 
>> A contrasting context that worked okay... GeForce 7800 GT based powerpc64/GENERIC64 PowerMac G5.
>> 
>> In this case the initial variant tried was: no use of WITH_DEBUG_FILES= WITHOUT_CLANG= WITH_DEBUG= or of source code hacks for early-boot-crash information. But still adding options DDB and GDB. So...
>> 
>> FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep 29 01:24:54 PDT 2014     root at FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64  powerpc
>> 
>> Index: /usr/src/sys/powerpc/conf/GENERIC64
>> ===================================================================
>> --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 272167)
>> +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy)
>> @@ -76,6 +76,8 @@
>>  # Debugging support.  Always need this:
>>  options  KDB   # Enable kernel debugger support.
>>  options  KDB_TRACE  # Print a stack trace for a panic.
>> +options  DDB
>> +options  GDB
>>    # Make an SMP-capable kernel by default
>>  options  SMP   # Symmetric MultiProcessor Kernel
>> 
>> 
>> 
>> But simply moving the earlier SSD (once rebuilt) from the Radeon PowerMac G5 (where it failed to display right or boot) to the GeForce based G5 resulted in normal text and a completed boot.
>> 
>> It looks like the problem here is tied to Radeons, or possibly to the model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 GT and not try to involve a PowerMac G5 Radeon in my activities for now.
>> 
>> [The before-Copyright crash still happens randomly. None of this is directly about that issue.]
>> 
>> 
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>> 
>> _______________________________________________
>> freebsd-ppc at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>> 
> 
> 