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>
index | next in thread | previous in thread | raw e-mail
[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=1 case: > > This usually hang during boot during the "Waking up CPU" message sequence. > > 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? > > When it does boot, smp seems to be set up and working. > > Once booted, it is usually not very long until the fans are going wild, > other than an occasional, temporary lull. > > > > For for shutting down the following applies to both VM_MAX_KERNEL_ADDRESS > values when a usefdt=1 type of context is in use: > > When I've kept explicit track, I've not had any example of all of the: > > 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... > . . . > > getting to "done": instead one or more time out. Which and how many > vary. > > 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. > With VM_MAX_KERNEL_ADDRESS reverted or a successful boot with the modern value: Adding CPU 0, hwref=cd38, awake=1 Waking up CPU 3 (dev=c480) Adding CPU 3, hwref=c480, awake=1 Waking up CPU 2 (dev=c768) Adding CPU 2, hwref=c768, awake=1 Waking up CPU 1 (dev=ca50) Adding CPU 1, hwref=ca50, awake=1 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=cd38, awake=1 Waking up CPU 3 (dev=c480) Another is: Adding CPU 0, hwref=cd38, awake=1 Waking up CPU 3 (dev=c480) Waking up CPU 2 (dev=c768) (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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FA03DF6B-B8FC-42E5-A5B3-2891D88BDAD7>