Date: Fri, 12 Apr 2019 16:17:58 -0700 From: Mark Millard <marklmi@yahoo.com> To: Dennis Clarke <dclarke@blastwave.org> Cc: freebsd-ppc@freebsd.org Subject: 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 Message-ID: <A4E361A0-4C6C-4E37-BB04-AB52094F4206@yahoo.com> In-Reply-To: <5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org> References: <988F644F-D5E7-4FB4-AAB3-A72E9DA88CE6@yahoo.com> <af38e008-d9f9-9364-56c5-56387cbcf95d@blastwave.org> <465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com> <5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A4E361A0-4C6C-4E37-BB04-AB52094F4206>