Re: PowerMac G5 4-core (system total): usefdt=1 style booting (by itself): Turns out it usually hangs up during booting from power off

Mark Millard via freebsd-ppc <[email protected]>
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]>
[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).]
> 
> On 2019-Jan-28, at 18:16, Mark Millard <[email protected]> wrote:
> 
>> Based on my:
>> 
>> # 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/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG  powerpc powerpc64 1300005 1300005
>> 
>> with:
>> 
>> # svnlite diff /usr/src/sys/powerpc/include/vmparam.h                                                                                                                                        
>> #
>> 
>> (So no VM_MAX_KERNEL_ADDRESS workaround.)
>> And:
>> 
>> # svnlite diff /usr/src/stand/common/metadata.c
>> Index: /usr/src/stand/common/metadata.c
>> ===================================================================
>> --- /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 = 0;
>> -#if defined(__powerpc__)
>> -    if (getenv("usefdt") != NULL)
>> +    size = fdt_copy(addr);
>> +    fdtp = addr;
>> +    addr = roundup(addr + size, PAGE_SIZE);
>> #endif
>> -    {
>> -	size = fdt_copy(addr);
>> -	fdtp = addr;
>> -	addr = roundup(addr + size, PAGE_SIZE);
>> -    }
>> -#endif
>> 
>>    kernend = 0;
>>    kfp = file_findfile(NULL, kern64 ? "elf64 kernel" : "elf32 kernel");
>> 
>> (So the previous usefdt=1 behavior is automatic.)
>> 
>> Booting is then automatic, with smp working.
>> 
>> So I expect that when -r341614 (that made set usefdt=1 work) is merged to
>> stable/12 that the same will be true for the additional updates there.
>> 
>> 
>> I will note the following (adjusted from a previously reported
>> experiment with manual usefdt=1 use):
>> 
>> 1. After a while the fans get louder.
>> 
>> 2. When shutting down the system once the fans are louder,
>> 
>> 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...
>> 
>> all time out.
>> 
>> So there seems to be some type of a problem.
> 
> 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.
> 
> I'll keep experimenting on occasion.
> 
> 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.
> 

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=1 type
of context.

It currently seems a rarity that it boots.

It looks to me like usefdt=1 does little or no good for the
problem exposed by the modern VM_MAX_KERNEL_ADDRESS value.


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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.