Date: Sun, 7 Apr 2019 18:20:27 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: 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] Message-ID: <88C954A4-6D5A-4AB9-AA26-0ACD6D298605@yahoo.com> In-Reply-To: <9A2F72B7-A25C-478C-B1AD-0661278F0B46@yahoo.com> References: <BD01C826-89A2-46A0-9157-022481E0DC88@yahoo.com> <98A19824-3C07-4ED6-A848-5A634F95E1CF@yahoo.com> <D473FC85-E895-48C0-A587-F52A4FB403AF@yahoo.com> <9A2F72B7-A25C-478C-B1AD-0661278F0B46@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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=3D1 style handling, suggesting mismatches or incompletenesses for usefdt=3D1 .] On 2019-Apr-7, at 16:31, Mark Millard <marklmi at yahoo.com> wrote: >=20 > On 2019-Apr-7, at 15:46, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> . . . >=20 >>=20 >> I'll see about diff'ing the good vs. bad PowerMac3,6 >> ofwdump -ap output when I have a chance. >>=20 >=20 > The outputs are not such that a diff is all that useful, > a extensively different output ordering appears to be=20 > involved. >=20 > For reference: >=20 > # 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 >=20 > ( *3,6_bad.txt was under usefdt=3D1 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. ) >=20 > 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=3D1 style if usefdt=3D1 = 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=3D1 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88C954A4-6D5A-4AB9-AA26-0ACD6D298605>