Date: Wed, 30 Jan 2019 17:18:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: PoerMac G5 "4 core" (system total): some from-power-off booting observations of the modern VM_MAX_KERNEL_ADDRESS value mixed with usefdt=1 Message-ID: <FA03DF6B-B8FC-42E5-A5B3-2891D88BDAD7@yahoo.com> In-Reply-To: <2153561F-FE12-4BA0-9856-F75110401AB6@yahoo.com> References: <2153561F-FE12-4BA0-9856-F75110401AB6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Where boot -v output is different between booting to completion vs. hanging up: actual text.] On 2019-Jan-29, at 17:52, Mark Millard <marklmi at yahoo.com> wrote: > For the modern VM_MAX_KERNEL_ADDRESS value and also use of the = usefdt=3D1 case: >=20 > This usually hang during boot during the "Waking up CPU" message = sequence. >=20 > But not always. Powering off and retrying , sometimes just a few = times, and > other times dozens of times, the system that I have access to does = eventually > boot for the combination. So some sort of race condition or lack of = stable > initialization? >=20 > When it does boot, smp seems to be set up and working. >=20 > Once booted, it is usually not very long until the fans are going = wild, > other than an occasional, temporary lull. >=20 >=20 >=20 > For for shutting down the following applies to both = VM_MAX_KERNEL_ADDRESS > values when a usefdt=3D1 type of context is in use: >=20 > When I've kept explicit track, I've not had any example of all of the: >=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 > getting to "done": instead one or more time out. Which and how many > vary. >=20 > The fans tend to take off for both VM_MAX_KERNEL_ADDRESS values. The > buf*daemon timeouts happen even if the fans have not taken off. >=20 With VM_MAX_KERNEL_ADDRESS reverted or a successful boot with the modern value: Adding CPU 0, hwref=3Dcd38, awake=3D1 Waking up CPU 3 (dev=3Dc480) Adding CPU 3, hwref=3Dc480, awake=3D1 Waking up CPU 2 (dev=3Dc768) Adding CPU 2, hwref=3Dc768, awake=3D1 Waking up CPU 1 (dev=3Dca50) Adding CPU 1, hwref=3Dca50, awake=3D1 SMP: AP CPU #3 launched SMP: AP CPU #2 launched SMP: AP CPU #1 launched Trying to mount root from ufs:/dev/ufs/FBSDG5L2rootfs [rw,noatime]... With the modern VM_MAX_KERNEL_ADDRESS value for a boot attempt that failed, an example (typed from a picture of the screen) is: Adding CPU 0, hwref=3Dcd38, awake=3D1 Waking up CPU 3 (dev=3Dc480) Another is: Adding CPU 0, hwref=3Dcd38, awake=3D1 Waking up CPU 3 (dev=3Dc480) Waking up CPU 2 (dev=3Dc768) (Both examples have no more output.) So CPUs 1..3 do not get "Adding CPU" messages. Also: I do not remember seeing all 3 "Waking up CPU" messages, just 1 or 2 of them. (Sometimes the "Trying to mount root from" message is in the mix as I remember.) One point of difference that is consistently observable for the old vs. modern VM_MAX_KERNEL_ADDRESS values is how many bufspacedaemon-* threads there are: old VM_MAX_KERNEL_ADDRESS value: 0..2 new VM_MAX_KERNEL_ADDRESS value: 0..6 I have had many boot attempts in a row boot for the modern VM_MAX_KERNEL_ADDRESS value, though not as many as the dozens of failures in a row. Highly variable with lots of testing. =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?FA03DF6B-B8FC-42E5-A5B3-2891D88BDAD7>