head -r345758: usefdt=1 style boot fails on PowerMac7,2 G5 (1 core per socket): Error -2 adding node /cpus/PowerpC,970 [G4 failures too, problem identified]

Mark Millard marklmi at yahoo.com
Wed Apr 10 02:44:42 UTC 2019


[Turns out that PowerMac11,2 G5 (2 socket, 2 cores per) usefdt style
booting skips a node and any subordinates, but not any CPUs.]

On 2019-Apr-7, at 18:20, Mark Millard <marklmi at yahoo.com> wrote:

> [I produced a ofwdump -ap output from the old SSD
> booting the PowerMac11,2 . It produces a (somewhat)
> larger output than is produced under usefdt=1
> style handling, suggesting mismatches or incompletenesses
> for usefdt=1 .]
> 
> On 2019-Apr-7, at 16:31, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> 
>> On 2019-Apr-7, at 15:46, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> . . .
>> 
>>> 
>>> I'll see about diff'ing the good vs. bad PowerMac3,6
>>> ofwdump -ap output when I have a chance.
>>> 
>> 
>> The outputs are not such that a diff is all that useful,
>> a extensively different output ordering appears to be 
>> involved.
>> 
>> For reference:
>> 
>> # ls -lTd ~/ofwdump_*.txt
>> -rw-r--r--  1 root  wheel  166008 Apr  7 16:21:33 2019 /root/ofwdump_11,2_usefdt1.txt
>> -rw-r--r--  1 root  wheel   93713 Apr  7 13:11:21 2019 /root/ofwdump_3,6_bad.txt
>> -rw-r--r--  1 root  wheel  162390 Apr  7 15:40:23 2019 /root/ofwdump_3,6_good.txt
>> -rw-r--r--  1 root  wheel  818400 Apr  7 15:15:03 2019 /root/ofwdump_7,2_good.txt
>> 
>> ( *3,6_bad.txt was under usefdt=1 and based on far more modern head code than the
>> matching *3,6_good.txt file was. *7,2_good.txt is from the old version of head as
>> well. )
>> 
>> ofwdump_3,6_bad.txt seems to be missing a lot, based on the size difference vs.
>> ofwdump_3,6_good.txt .
> 
> So, showing the older context's ofwdump -ap output file size as well:
> 
> # ls -lTd ~/ofwdump_*.txt
> -rw-r--r--  1 root  wheel  192603 Apr  7 17:48:15 2019 /root/ofwdump_11,2_old.txt
> -rw-r--r--  1 root  wheel  166008 Apr  7 16:21:33 2019 /root/ofwdump_11,2_usefdt1.txt
> -rw-r--r--  1 root  wheel   93713 Apr  7 13:11:21 2019 /root/ofwdump_3,6_bad.txt
> -rw-r--r--  1 root  wheel  162390 Apr  7 15:40:23 2019 /root/ofwdump_3,6_good.txt
> -rw-r--r--  1 root  wheel  818400 Apr  7 15:15:03 2019 /root/ofwdump_7,2_good.txt
> 
> Again, the ordering differences and such make a diff
> not all that useful.
> 
> I have no clue why ofwdump_7,2_good.txt is so much larger than all the
> others.
> 
> It would be easier to compare old vs. usefdt=1 style if usefdt=1 style
> managed to preserve the ordering of what ofwdump -ap outputs for old, there
> by allowing vastly fewer differences (despite magic node number differences
> and such). I've no clue how to validate the usefdt=1 style as things are.
> 
> I do not ever have access to other types of G5's. I do sometimes have
> access to some single-socket/single-processor/single-core G4s and one
> G3. But I'm not intending to do any exploring for these for now.
> 
> Let me know if you want a bugzilla submittal with the ofwdump_*,*.txt files
> as attachments.

I caught a picture of a PowerMac11,2 G5 (2 socket, 2 cores per) booting,
usefdt style, that showed:

Error -2 adding node /ht at 0,f2000000/pci at 8/mac-io at 7/i2c at 18000/i2c-bus at 0 (i2c-bus at 0), skipping

(The screen clears quickly after that so I'd not noticed before.)

That was the only such message. Still, it is enough to explain having
a notable different size of ofwdump -ap output text between usefdt style
modern and non-usefdt style older for the same machine (both 32-bit
powerpc FreeBSD variants).

(powerpc64 FreeBSD crashes/gets-stuck for the likes of ofwdump -ap for
a non-usefdt style boot on the same machine, apparently going back to at
least -r333594 . I've sent a separate note to the list for this issue.)

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



More information about the freebsd-ppc mailing list