Date: Mon, 28 Jan 2019 23:18:43 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: Curtis Hamilton <clhamilto@gmail.com> Subject: Re: PowerMac G5 4-core (system total): usefdt=1 style booting (by itself): Turns out it usually hangs up during booting from power off Message-ID: <3DB75B89-5384-4442-A022-C80BF858726C@yahoo.com> In-Reply-To: <14F0F9E2-53C8-4E0A-B0F6-4491A9EC6076@yahoo.com> References: <47F8D1D3-11BC-4EC9-89AE-65566A6F9087@yahoo.com> <14F0F9E2-53C8-4E0A-B0F6-4491A9EC6076@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[This follows the progression of my intermittent testing. New
information is towards the bottom. The initial good results
have not held up.]
On 2019-Jan-28, at 19:30, Mark Millard <marklmi at yahoo.com> wrote:
> [The bug*daemon time-outs during shutdown also happen without =
fan-speed
> issues happening first (or during shutdown).]
>=20
> On 2019-Jan-28, at 18:16, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> Based on my:
>>=20
>> # uname -apKU
>> FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #6 r341836M: Mon =
Jan 28 14:42:29 PST 2019 =
markmi@FBSDFSSD:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/us=
r/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 =
1300005 1300005
>>=20
>> with:
>>=20
>> # svnlite diff /usr/src/sys/powerpc/include/vmparam.h =
=
=20
>> #
>>=20
>> (So no VM_MAX_KERNEL_ADDRESS workaround.)
>> And:
>>=20
>> # svnlite diff /usr/src/stand/common/metadata.c
>> Index: /usr/src/stand/common/metadata.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- /usr/src/stand/common/metadata.c (revision 341836)
>> +++ /usr/src/stand/common/metadata.c (working copy)
>> @@ -322,15 +322,10 @@
>> #if defined(LOADER_FDT_SUPPORT)
>> /* Copy out FDT */
>> fdtp =3D 0;
>> -#if defined(__powerpc__)
>> - if (getenv("usefdt") !=3D NULL)
>> + size =3D fdt_copy(addr);
>> + fdtp =3D addr;
>> + addr =3D roundup(addr + size, PAGE_SIZE);
>> #endif
>> - {
>> - size =3D fdt_copy(addr);
>> - fdtp =3D addr;
>> - addr =3D roundup(addr + size, PAGE_SIZE);
>> - }
>> -#endif
>>=20
>> kernend =3D 0;
>> kfp =3D file_findfile(NULL, kern64 ? "elf64 kernel" : "elf32 =
kernel");
>>=20
>> (So the previous usefdt=3D1 behavior is automatic.)
>>=20
>> Booting is then automatic, with smp working.
>>=20
>> So I expect that when -r341614 (that made set usefdt=3D1 work) is =
merged to
>> stable/12 that the same will be true for the additional updates =
there.
>>=20
>>=20
>> I will note the following (adjusted from a previously reported
>> experiment with manual usefdt=3D1 use):
>>=20
>> 1. After a while the fans get louder.
>>=20
>> 2. When shutting down the system once the fans are louder,
>>=20
>> Waiting (max 60 seconds) for system thread `bufdaemon' to stop...
>> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to =
stop...
>> Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to =
stop...
>>=20
>> all time out.
>>=20
>> So there seems to be some type of a problem.
>=20
> Experiments with booting and then shutting down somewhat
> later show that the bug*daemon time-outs during shutdown
> also happen without the fan's becoming loud first. They
> seem independent at this point.
>=20
> I'll keep experimenting on occasion.
>=20
> Oh: I did not mean to imply that only the -0 and the -1 of the
> various bufspaceddaemon-* timeout. I just did not list them all.
>=20
Contintued use has produced mostly hangups during booting when
starting from power-off (instead of shutdown -r now).
I've also seen that the buf*daemon at shutdown can be a mix
of ones that hang up and others that reach Done normally.
I've switched to a debug kernel build in order to see what
it reports. (So far nothing interesting.)
The boot-time hangs for "boot -v" show the last line(s)
as "Waking up CPU" messages --but at least one is not
displayed. This is the same as without the usefdt=3D1 type
of context.
It currently seems a rarity that it boots.
It looks to me like usefdt=3D1 does little or no good for the
problem exposed by the modern VM_MAX_KERNEL_ADDRESS value.
=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?3DB75B89-5384-4442-A022-C80BF858726C>