Re: Patches to allow usefdt mode that works on a 2 socket PowerMac3, 6 example too --and makes more work on 2-socket/1-core-each PowerMac11, 2

On 2019-Apr-12, at 14:20, Dennis Clarke <dclarke a t blastwave.org> wrote:

> On 4/12/19 4:51 PM, Mark Millard wrote:
>> On 2019-Apr-12, at 13:13, Dennis Clarke <dclarke at blastwave.org> wrote:
>>> On 4/12/19 3:19 PM, Mark Millard via freebsd-ppc wrote:
> .
> .
> .
>>> 
>>> Would you be so kind as to paste all this into :
>>> 
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863
>>> 
>>> Really I would like to run some tests and follow up in the bug reports.
>> Okay I'll paste them in as attachments. But be warned:
> 
> Fair warning received loud and clear :-)
> 
>> The 2 files do not deal with threads being stuck sleeping
>> (and, so, the fans going) or other such. The stuck-sleeping
>> problem happens for both multi-socket G5's and multi-socket
>> G4's. (I do not have access to single-socket multi-core
>> powerpc64 or powerpc machines to test.)
> 
> I have multiple G5 type boxen and will try them out. At least try
> to.
> 
>> So do not expect too much from these patches: They address
>> some necessary issues but are not sufficient for everything.
>> 
> 
> Of course. No problem.
> 
> 
>> These patches for the openfirmware->fdt translation are
>> closer to being reasonable for FreeBSD official use
>> than my highly context-specific stuck-sleeping patches for
>> usefdt mode.
> 
> Well to be frank we know this is for mac g5 hardware and thus having
> them working at all in any fashion is better than the current situation.
> Apple made a ton of them and they are dirt cheap and available as
> opposed to the IBM Power situation which is expensive and just in
> datacenters.


I have added another attachment with patches for having hang-ups
at AP startup happen less often. These are in AIM-specific code
and so has less of a chance of causing other contexts problems.
They are also powerpc64 specific. Again, the patches are
investigatory and not in a form for direct check-in to FreeBSD.

This pair of patches narrows the time period over which threads
from the stages:

        SI_SUB_KTHREAD_INIT     = 0xe000000,    /* init process*/
        SI_SUB_KTHREAD_PAGE     = 0xe400000,    /* pageout daemon*/
        SI_SUB_KTHREAD_VM       = 0xe800000,    /* vm daemon*/
        SI_SUB_KTHREAD_BUF      = 0xea00000,    /* buffer daemon*/
        SI_SUB_KTHREAD_UPDATE   = 0xec00000,    /* update daemon*/
        SI_SUB_KTHREAD_IDLE     = 0xee00000,    /* idle procs*/
#ifndef EARLY_AP_STARTUP
        SI_SUB_SMP              = 0xf000000,    /* start the APs*/
#endif 

can conflict with starting an AP via an slb replacement position
picked via expressions like mftb()%n_slbs . It does this by 
explicitly picking and setting up a slb slot for its use just
before starting the AP.

(The AP has to be part way along before it can do its own
automatic-random-slb-slot-replacements from what I can tell.)

The patches do not remove the race and still do sometimes fail to
prevent getting a hang-up on a AP start. But it greatly decreased
the rate of hangups in my testing. (So it is a good source of
evidence about the original problem.)

If EARLY_AP_STARTUP was supported and used, the AP startup would
not have hang-up problems from mftb()%n_slbs based slb
replacements for other threads.

The patches are a hack, rather than a general/complete fix --and
I do not expect to see them in FreeBSD. But they do help set up
a better context for investigating other things.

===
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]"