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

Tue Sep 30 23:21:46 UTC 2014

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 <mailto:markmi at dsl-only.net>
>
> On Sep 30, 2014, at 8:24 AM, Nathan Whitehorn <nwhitehorn at freebsd.org 
> <mailto: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 <http://dsl-only.net>
>>
>> _______________________________________________
>> freebsd-ppc at freebsd.org <mailto: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"
>>
>
>