From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 06:21:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4415DBF5 for ; Fri, 21 Mar 2014 06:21:05 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0223D5B for ; Fri, 21 Mar 2014 06:21:04 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id id10so2175546vcb.12 for ; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=PnE5BC+VsuiQ8lVldsCeQs+wZLwT9On0nF8vvZqJKic=; b=Y1NYTsKsci0vr96NWgintokz+wD4M3/uMR8EvP49jxJysXv0KSdLN8dbexvDcoU8u9 Rm+HduBuSdy1xt/vUcQQ0Acv3VdkoVOI4AyWE0XBZunNSnqWiKr4TB+4AcFfssmyiHQ0 tDuLdIq6xP+x6YxijkZaYepWOZPhe8PRir/Ks2a9qWcVbj70ACRiWY0LXZ4k8PSdPbVg 5cBKRpk+0yRV35IH5XoNCL9NozzEaybqe2q8swc5Ki1n15EgkbdWlkmov2G9IcvfgKhd chpEglb1JDjMI4JE00vruXmPY87eSvk4O4/RoEF7EBQ6+Icdd9UnQ0Df9O1U7z3PvLNS eTqw== X-Gm-Message-State: ALoCoQkf364KUCNcnew90G8VNLgYS/zXv7gJPuLhBGM9/3wlOilBSBX4ruJoh/eOdbO+ytuWe9mV MIME-Version: 1.0 X-Received: by 10.58.1.97 with SMTP id 1mr1092755vel.23.1395382858399; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) Received: by 10.220.209.135 with HTTP; Thu, 20 Mar 2014 23:20:58 -0700 (PDT) In-Reply-To: <1395320561.80941.13.camel@revolution.hippie.lan> References: <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <20131222123636.GA61193@ci0.org> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan> <1395320561.80941.13.camel@revolution.hippie.lan> Date: Fri, 21 Mar 2014 07:20:58 +0100 Message-ID: Subject: Re: arm SMP on Cortex-A15 From: Wojciech Macek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 06:21:05 -0000 No, changing flushD to flushID did not make any difference, but I think it should be there - D-only flushing might not be sufficient. Currently, I'm running pmap_kernel_internal attached below. It is doing unconditional flushID at the end, just like the old comment was saying :) SMP seems to be stable. /* * add a wired page to the kva * note that in order for the mapping to take effect -- you * should do a invltlb after doing the pmap_kenter... */ static PMAP_INLINE void pmap_kenter_internal(vm_offset_t va, vm_offset_t pa, int flags) { struct l2_bucket *l2b; pt_entry_t *ptep; pt_entry_t opte; PDEBUG(1, printf("pmap_kenter: va = %08x, pa = %08x\n", (uint32_t) va, (uint32_t) pa)); l2b = pmap_get_l2_bucket(pmap_kernel(), va); if (l2b == NULL) l2b = pmap_grow_l2_bucket(pmap_kernel(), va); KASSERT(l2b != NULL, ("No L2 Bucket")); ptep = &l2b->l2b_kva[l2pte_index(va)]; opte = *ptep; if (flags & KENTER_CACHE) { *ptep = L2_S_PROTO | pa | pte_l2_s_cache_mode | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE, flags & KENTER_USER); } else { *ptep = L2_S_PROTO | pa | L2_S_REF; pmap_set_prot(ptep, VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE, 0); } PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n", (uint32_t) ptep, opte, *ptep)); if (!l2pte_valid(opte) && (opte == 0)) { l2b->l2b_occupancy++; } PTE_SYNC(ptep); cpu_tlb_flushID_SE(va); cpu_cpwait(); } 2014-03-20 14:02 GMT+01:00 Ian Lepore : > On Thu, 2014-03-20 at 08:42 +0100, Wojciech Macek wrote: > > Hi Ian, > > > > Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is > > still something wrong on A15 core. Your changes in pmap_kenter_internal > do > > cause panics during startup. Apparently we still need to do > > cpu_tlb_flushID_SE(va) at the end of that function... but that is weird. > I > > made this small "fix" and I'm able to boot the system. I'm going to run > > stress tests now to see if it is stable. > > > > Regarding DEBUG, that is really interesting. It you see that on A9 that > > seems to be even worse, because suggests a flaw in pmap logic... > > > > Wojtek > > Hmmm, do you have r263251? > > I just noticed that my version of the change to pmap_kenter_internal > uses cpu_tlb_flushD_SE(), yours uses cpu_tlb_flushID_SE(). I wonder if > changing mine to ID is all it takes to make your system boot? > > -- Ian > > >