head -r333897 (usefdt and old PowerMac) questions

[Mark Millard]

On 2018-Dec-9, at 22:07, Dennis Clarke <dclarke at blastwave.org> wrote:

> On 12/10/18 12:35 AM, Mark Millard via freebsd-ppc wrote:
>> On 2018-May-19, at 21:27, Mark Millard <marklmi26-fbsd at yahoo.com> wrote:
>>> On 2018-May-19, at 9:14 PM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
>>>> You need to wait for one more patch. With that, usefdt=1 is confirmed working on PowerMac 11,2 (like the quad core). You must use vt, not sc, but everything should work out of the box once that patch is in. The only caveat is that bge0 and bge1 may swap numbers.
>>>> -Nathan
>>> 
>>> Good to know. Thanks.
>>> 
>>> "You must use vt, not sc": does this mean changing to not
>>> include sc in the kernel at all? Or will /boot/loader.conf
>>> having:
>>> 
>>> kern.vty=vt
>>> 
>>> be enough despite sc also being present?
>>> . . .
>> Just an FYI about my from-source builds based on devel/powerpc64-xtoolchain-gcc
>> and the reverted-to-before /usr/src/sys/powerpc/include/vmparam.h -r334498 .
>> With the recent activity I jumped from -r340287 to -r341766 . It booted fine as
>> smp.
>> I tried booting with "set usefdt=1" and the ethernet connection moved to
>> the other plugin position. It booted fine as smp. That was with
>> /boot/loader.conf having:
>> kern.vty=sc
>> 
> 
> I feel a bit out of the loop here. I don't know what that "kern.vty=sc"
> is for at all. Perhaps kernel video tty = sugar coated?  Just a guess.

See: https://wiki.freebsd.org/Newcons

vt is the newer console support, sc (syscons) is the older support.

Long ago Nathan provided a workaround when I had a problem with
vt. It involved disabling ps3 support in order to allow building with
both vt and sc available. If I remember right, I've used sc more than
vt since then.


>> However I've not used X11 or such in years, just the console and ssh sessions.
> 
> Same here.
> 
> I can tell you that 341705 requires kern.smp.disabled=1 and usefdt=1 in
> order to boot without a strange freeze or panic. I will check out 341781
> now and see what new stability has arrived but 341705 requires hand
> holding and small prayers at boot time.

You are working with builds based on
/usr/src/sys/powerpc/include/vmparam.h having been updated. I am not.
The contexts are not the same and mine is a variation on the official
version, not the official version.

Your assumptions are invalidated by this difference (and possibly others)
if you make claims about my experimental builds of variations of any
specific version. I'd be surprised at this point if you tried an official
-r341766 build and found the behavior shown in my experimental build.
Similarly if I tried -r341705 .

I'm only claiming that in some contexts, reverting vmparam.h and
using that to do the builds seems to sidestep whatever the issue
is for G5's: it is a workaround/hack at this point and not likely
involved in a general fix. I'm not the only one to have seen such
variations in behavior for version variations based on vmparam.h
content for the one macro in question.

> Yes the bge0 and bge1 do swap places. I see your notes on Bug 233863 and
> will follow along here.
> 

I consider the old exchange with Nathan separate. I figured that he might
be interested that sc would be working. Prior to the around 2018-May-19
messages, Nathan and I last interactions for usefdt=1 use in 2016, if I
remember right.

I'm not sure when I will next do anything remotely interesting with the
G5. There might not be much to follow for a while.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)