THis is going to bounce ; but, have any of you thought about joining with the debian powerpc team now that they have been put off for ppc64el - POWER 8&9 - and the 32 and 64 bit parts are unsupported?
It's time for you people to start working together. Put your differences aside and you will solve the problems. On Mon, Nov 21, 2016 at 6:22 AM, Mark Millard <[email protected]> wrote: > [Top post of operational confirmation.] > > I'm now logged in on the iMac G3 under a variant of head -r308874 . > (Finally after about 1.8 years.) > > It is currently running a variation of head -r308874 with a debug > kernel that has the two isync's added around moea_activate's > mtsrin (and KTR turned back off). > > With no such isync's (or other such "context-synchronizations") > the iMac G3 does not boot. (The below likely does not preserve > tabs.) > > # svnlite diff /usr/src/sys/powerpc/aim/mmu_oea.c > Index: /usr/src/sys/powerpc/aim/mmu_oea.c > =================================================================== > --- /usr/src/sys/powerpc/aim/mmu_oea.c (revision 308874) > +++ /usr/src/sys/powerpc/aim/mmu_oea.c (working copy) > @@ -991,7 +991,9 @@ > CPU_SET(PCPU_GET(cpuid), &pm->pm_active); > PCPU_SET(curpmap, pmr); > > + isync(); > mtsrin(USER_SR << ADDR_SR_SHFT, td->td_pcb->pcb_cpu.aim.usr_vsid); > + isync(); > } > > > stable/11 should also get such a change, not just head. > > It would be nice if releng/11 eventually picked up such a > change so that some release/11.0.? booted on iMac G3's as well. > Otherwise it waits for release/11.1.0 . > > I wonder if there might be intermittent problems for > TARGET_ARCH=powerpc systems that are (usually) booting > for release/11.0.x currently. > > (I only have access to one iMac G3 to test and no access > to any other kinds of G3's. I have access to a few types > of PowerMac G4's and 2 types of PowerMac G5's. All the > PowerPc family machines that I have access to are Apple > machines.) > > > > > Note: > > stable/10 still has the old powerpc/swtch32.S code and so is > fine for this issue. > > Part of the context from back in early 2015 was that I > switched from 10 to 11 as part of getting ready to investigate > projects/clang380-import for powerpc and powerpc64 use. I > did not revert back to 10.x despite the iMac G3 not booting. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Nov-21, at 2:10 AM, Mark Millard <markmi at dsl-only.net> wrote: > > > First I report my understanding of the PowerPc background information > > involved: > > (then later the code that has that background involved) > > > > For reference: > > > > 82 mtsrin(vm_offset_t va, register_t value) > > 83 { > > 84 > > 85 __asm __volatile ("mtsrin %0,%1" :: "r"(value), "r"(va)); > > 86 } > > > > PowerPC requirements: > > > > mtsr(instruction access): no synchronization required before; > > context synchronization required after > > mtsrin(instruction access): no synchronization required before; > > context synchronization required after > > > > So the same criteria. isync, sc, or rfi would be > > "context-synchronizing". > > > > mtsr(data access): context synchronization required before; > > context synchronization required after > > mtsrin(data access): context synchronization required before; > > context synchronization required after > > > > So even more required for this context: before and after. > > Again isync would be "context-synchronizing". > > > > > > Now the code that has that background involved. . . > > > > aim/mmu_oea.c's moea_activate does mtsrin without any explicit > > "context-synchronizing" before or after it --and it replaced > > code that did have the "context-synchronizing". > > > > The modern (2015-Mar-4+) code: > > > > /* > > * Activate a user pmap. The pmap must be activated before it's address > > * space can be accessed in any way. > > */ > > void > > moea_activate(mmu_t mmu, struct thread *td) > > { > > pmap_t pm, pmr; > > > > /* > > * Load all the data we need up front to encourage the compiler to > > * not issue any loads while we have interrupts disabled below. > > */ > > pm = &td->td_proc->p_vmspace->vm_pmap; > > pmr = pm->pmap_phys; > > > > CPU_SET(PCPU_GET(cpuid), &pm->pm_active); > > PCPU_SET(curpmap, pmr); > > > > mtsrin(USER_SR << ADDR_SR_SHFT, td->td_pcb->pcb_cpu.aim.usr_vsid); > > } > > > > I expect that two isync's are missing. > > > > At the assembler level of detail the modern code in my example > > build is: > > > > 0080e3fc <moea_activate> stwu r1,-32(r1) > > 0080e400 <moea_activate+0x4> stw r31,24(r1) > > 0080e404 <moea_activate+0x8> mr r31,r1 > > 0080e408 <moea_activate+0xc> lwz r9,4(r4) > > 0080e40c <moea_activate+0x10> lwz r10,308(r9) > > 0080e410 <moea_activate+0x14> lwz r8,312(r10) > > 0080e414 <moea_activate+0x18> mfsprg r9,0 > > 0080e418 <moea_activate+0x1c> lwz r9,36(r9) > > 0080e41c <moea_activate+0x20> rlwinm r9,r9,27,5,31 > > 0080e420 <moea_activate+0x24> mfsprg r11,0 > > 0080e424 <moea_activate+0x28> rlwinm r9,r9,2,0,29 > > 0080e428 <moea_activate+0x2c> add r9,r9,r10 > > 0080e42c <moea_activate+0x30> addi r9,r9,256 > > 0080e430 <moea_activate+0x34> lwz r11,36(r11) > > 0080e434 <moea_activate+0x38> clrlwi r11,r11,27 > > 0080e438 <moea_activate+0x3c> li r0,1 > > 0080e43c <moea_activate+0x40> slw r0,r0,r11 > > 0080e440 <moea_activate+0x44> lwz r11,24(r9) > > 0080e444 <moea_activate+0x48> or r0,r0,r11 > > 0080e448 <moea_activate+0x4c> stw r0,24(r9) > > 0080e44c <moea_activate+0x50> mfsprg r9,0 > > 0080e450 <moea_activate+0x54> stw r8,304(r9) > > 0080e454 <moea_activate+0x58> lwz r9,644(r4) > > 0080e458 <moea_activate+0x5c> lwz r9,1176(r9) > > 0080e45c <moea_activate+0x60> lis r0,-16384 > > 0080e460 <moea_activate+0x64> mtsrin r9,r0 <<<<<<<<======= > "Context-synchronization(s)"? > > 0080e464 <moea_activate+0x68> lwz r11,0(r1) > > 0080e468 <moea_activate+0x6c> lwz r31,-8(r11) > > 0080e46c <moea_activate+0x70> mr r1,r11 > > 0080e470 <moea_activate+0x74> blr > > > > > > But the old, historical code that this replaced did have > > explicit "context-synchornizing" in powerpc/swtch32.S for > > AIM ( -r279594 replaced the below on 2015-Mar-4 ): > > > > -#ifdef AIM > > - lwz %r5,PCB_AIM_USR_VSID(%r3) /* Load the USER_SR segment reg > */ > > - isync > > - mtsr USER_SR,%r5 > > - isync > > -#endif > > > > (It was part of setting the user pmap during thread switching.) > > > > This replacement happened shortly before I discovered that > > the iMac G3 could no longer boot. It stops in pmap_activate > > in the lwz r11,0(r1) just after moea_activate returns from > > its bctrl-based call (modern code again below): > > > > . . . > > 00847954 <pmap_activate+0x94> beq- cr7,00847960 <pmap_activate+0xa0> > > 00847958 <pmap_activate+0x98> lwz r3,1024(r11) > > 0084795c <pmap_activate+0x9c> bl 004fdfac <kobj_lookup_method> > > 00847960 <pmap_activate+0xa0> lwz r3,4(r3) > > 00847964 <pmap_activate+0xa4> mtctr r3 > > 00847968 <pmap_activate+0xa8> mr r3,r29 > > 0084796c <pmap_activate+0xac> mr r4,r28 > > 00847970 <pmap_activate+0xb0> bctrl <<<<<<<<<<========= Calls > moea_activate. > > 00847974 <pmap_activate+0xb4> lwz r11,0(r1) <<<<<<<===== This fails. > > > > I end up at the db> prompt (too early for interactive input). > > (I have ddb automatically execute a compiled-in script.) > > > > I've confirmed with show registers that ctl has the address of > moea_activate > > (0x80e3fc in my example build of head -r308874) and srr0 has > pmap_activate+0xb4's > > value (matching lr). srr1 has the value 0x1032. dar has the value > 0xe43f6a50 > > (matching r1 and r31). dsisr has the value 0x40000000. > > > > I also have confirmed with verbose KTR reporting that: > > > > cpu0 mi_switch: old thread 100022 (td_sched 0x2x0e6a8, pid 12, irq0: > pcm0) > > > > happens just before it stops at pmap_activate+0xb4, at least > > as far as visible messages go. > > > > Again, I expect that two isync's are missing in moea_activate: > > one before the mtsrin and one after it, matching the old mtsr > > handling from before the change. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "[email protected]" >
