From owner-freebsd-ppc@freebsd.org Fri Nov 25 19:37:38 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F02FCC55086 for ; Fri, 25 Nov 2016 19:37:38 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A11B881F; Fri, 25 Nov 2016 19:37:38 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id p9so46781936vkd.3; Fri, 25 Nov 2016 11:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5W/9oNnDcqo+NoZHqH/mKdrqOToEjEdNvV7QE6ZBLd0=; b=OLhX55mGuD4qyggs+zFP3W3RvWh1UYaKEO0upB+v4SACcj+j0M2Lsko7j4OlxokhZR gnCkMJmBo6E0nw0lzDxOM1WPsqJ/i+MJB6a5bbbpACPjlL79Jv7YKwCGCxMZMwvm0gWs 37WXFkTQWfKS3FNF5790gZWOoy0eXeQve5OerFyjP9nfMj5GsUJRBw8uyc4dv8FvxdWe W/1T148k30pNBhvfoJ9Kjmwftxkf2uMXeTfPQV/zjig+kyp1CHPwlJjOqtnQmQI0eUSp nv5aShlE7STkU/TBF+tae3pGNRnsDCIgfxVXoP5L1IYaXErfWv9G61JniYYIjFOu7gYG ygQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5W/9oNnDcqo+NoZHqH/mKdrqOToEjEdNvV7QE6ZBLd0=; b=mpkKVwQ7Wk7fhDiLTdPU8gw1tb8vF3u+hrt3qsgaQzUH8NSgz+LDIHOEIFAOv3hOiI +BQ+5fXW8vUH7dGor1fveZgb6ajIC8Tn2yR56GwV/vHJZPAK669rp+zbBu3GLspD1g1f zT8c2ajJFgOTSuKOdfoK7x6EKIQkdbOMY+h8o1BsLeYATf6VhvErTdoneQC1M2jCmRLq jVvLOa3P6JO+4MwQtsAm0cgTg3rKn5Sx/PtEWeVlJc8SB7jdms3M/mdJvnAERFFoJWwx L6/hdflzhqz7l6iCoZgUF5ZAq6Awcuux1/6m0Wv+M/X04iJkDpHSX/vssInkTes4/WLV 0pxA== X-Gm-Message-State: AKaTC02AFyrYtFUhOgg/CcgZF2jSbPmJ/8RIG4ZBr908igrGOnI97hglTUygq1FhjujotTM9eu11IUJSGVmy/w== X-Received: by 10.31.191.194 with SMTP id p185mr3592901vkf.98.1480102657746; Fri, 25 Nov 2016 11:37:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.19.132 with HTTP; Fri, 25 Nov 2016 11:37:37 -0800 (PST) Received: by 10.103.19.132 with HTTP; Fri, 25 Nov 2016 11:37:37 -0800 (PST) In-Reply-To: <53724219-2378-45E0-B521-8F3EFA85CE41@dsl-only.net> References: <8915A2F8-0C75-4B8B-BCC1-7252EA02D292@dsl-only.net> <53724219-2378-45E0-B521-8F3EFA85CE41@dsl-only.net> From: Justin Hibbits Date: Fri, 25 Nov 2016 13:37:37 -0600 Message-ID: Subject: Re: I think I found why the iMac G3 that I have access to has not booted FreeBSD vintages: 2015-Mar+ . . . [Yep: booted!] To: Mark Millard Cc: Nathan Whitehorn , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 19:37:39 -0000 Hi Mark, Nice legwork on this. I just committed r309167 which should fix this bug. Can you update and test? - Justin On Nov 21, 2016 05:22, "Mark Millard" 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 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 stwu r1,-32(r1) > > 0080e400 stw r31,24(r1) > > 0080e404 mr r31,r1 > > 0080e408 lwz r9,4(r4) > > 0080e40c lwz r10,308(r9) > > 0080e410 lwz r8,312(r10) > > 0080e414 mfsprg r9,0 > > 0080e418 lwz r9,36(r9) > > 0080e41c rlwinm r9,r9,27,5,31 > > 0080e420 mfsprg r11,0 > > 0080e424 rlwinm r9,r9,2,0,29 > > 0080e428 add r9,r9,r10 > > 0080e42c addi r9,r9,256 > > 0080e430 lwz r11,36(r11) > > 0080e434 clrlwi r11,r11,27 > > 0080e438 li r0,1 > > 0080e43c slw r0,r0,r11 > > 0080e440 lwz r11,24(r9) > > 0080e444 or r0,r0,r11 > > 0080e448 stw r0,24(r9) > > 0080e44c mfsprg r9,0 > > 0080e450 stw r8,304(r9) > > 0080e454 lwz r9,644(r4) > > 0080e458 lwz r9,1176(r9) > > 0080e45c lis r0,-16384 > > 0080e460 mtsrin r9,r0 <<<<<<<<======= > "Context-synchronization(s)"? > > 0080e464 lwz r11,0(r1) > > 0080e468 lwz r31,-8(r11) > > 0080e46c mr r1,r11 > > 0080e470 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 beq- cr7,00847960 > > 00847958 lwz r3,1024(r11) > > 0084795c bl 004fdfac > > 00847960 lwz r3,4(r3) > > 00847964 mtctr r3 > > 00847968 mr r3,r29 > > 0084796c mr r4,r28 > > 00847970 bctrl <<<<<<<<<<========= Calls > moea_activate. > > 00847974 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 > > >