From owner-freebsd-ppc@freebsd.org Tue May 7 18:07:01 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BBEF158F39D for ; Tue, 7 May 2019 18:07:01 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33B216E1DA for ; Tue, 7 May 2019 18:07:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it1-x12f.google.com with SMTP id q65so26550859itg.2 for ; Tue, 07 May 2019 11:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=uLax5J5tyrYt16N0rI+eCan4OiVLccE4RSkkgoVKqr8=; b=Omz1cR/C/GsBEr5AbeyZOfBkAzLWkUNWU0H+ThAiyj8HoeijSNCSJYc+Ma1YAMya0s y0ZgH/K+/0HrqDdJgvg13ZcxqzMAigU6ByL0jkmCf+iDmW8de33A/yHvTCrKhJCPO/oP jQbRT/iL5MCh/JJlcpafZ7A9ZxwSJLGqexvvBHZ+hTdAtxOaPbFKB+lbwJaTyDTWspbz iGbD4wRmE1U0l9tF5AzQXkA35WGnDFVnPE/nIccfT33iveBLSCtvLCdhVB5rJ7hlaUr0 dUE09IH5jzIKnKRkjeawZRH0+7f513GzoqdGH0e5ZluMhajSsonpzG0shO8uJlTPZXQx QgZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uLax5J5tyrYt16N0rI+eCan4OiVLccE4RSkkgoVKqr8=; b=e4DUQ26igxNsKEInYrtL3HAm6FAZD4qJK7C7RZ7DBX1gYBP2bT1gDmttZSRJc2uP1A nINuXvS8s5Lit5Zv8knEqTuTu2HpQLAMQSELSxwfqLLjQIaFc4Aj04UOEab5ic/1GtuU O8I7Q7yfOf0TkQoRznPrXyG4UNg40UAlZdo4kYqp3kKdFr2TSeeY+yF8VO2FZVcwdv/y zk2KTJjYCVGCcb741J8XOADBXgQVd1bNJr7rpDfKgb5Clt4HvA0qxQRj72bb/erIDH/e GR/hFKmcUj2nvdO89JeFtrVtNMd2gp5RTU1LjpGIFsIDOwwvE9Tdaehlovfg5GAQh9ay 1a2g== X-Gm-Message-State: APjAAAUHLdvyMDlT64pgbLUsZLOFkfOMV36RyDfJAinO8GBio0lzAn8r fDKELDkt4Z5Z45H0wZWR/bQ= X-Google-Smtp-Source: APXvYqxmAB7zjt6jUb+8PVOs+LWgOKbvwt36dKbh5VFaIo3JnEvld40llFioEfH4vEvSqEXoBJ7fTg== X-Received: by 2002:a02:708c:: with SMTP id f134mr22728095jac.89.1557252419327; Tue, 07 May 2019 11:06:59 -0700 (PDT) Received: from titan.knownspace (173-25-245-129.client.mchsi.com. [173.25.245.129]) by smtp.gmail.com with ESMTPSA id j5sm6508432ita.16.2019.05.07.11.06.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 May 2019 11:06:58 -0700 (PDT) Date: Tue, 7 May 2019 13:06:54 -0500 From: Justin Hibbits To: Mark Millard Cc: FreeBSD PowerPC ML Subject: Re: head -r347003 on 2-socket/2-cores-each G5 PowerMac11,2's: one type of boot-blocking context found Message-ID: <20190507130654.20a269f6@titan.knownspace> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 33B216E1DA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Omz1cR/C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-6.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.91)[ip: (-9.00), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.26), country: US(-0.06)] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 18:07:01 -0000 On Mon, 6 May 2019 22:43:36 -0700 Mark Millard wrote: > Every example of boot failure during cpu_mp_unleash, > where I've had the tracking in place, has had 1 or more > examples of srr0 handle_kernel_slb_spill before cpu_mp_unleash tries to > start its first ap. > > Every example of boot success, where I've had the tracking > in place, has had no examples of srr0 (EXC_ISE) in handle_kernel_slb_spill before the > cpu_mp_unleash finished. (Successful boots are rare > in my current test context, so there are fewer examples > of this.) > > In other words: the original live-G5 information > for the segment was still present throughout that > time frame, thus avoiding a slbtrap for such a > fetch address over the time frame involved. > > > > In the the code: > > rstvec = rstvec_virtbase + reset; > printf("powermac_smp_start_cpu: about to use *rstvec==4\n"); > *rstvec = 4; > powerpc_sync(); > (void)(*rstvec); > powerpc_sync(); > DELAY(1); > printf("powermac_smp_start_cpu: about to use *rstvec==0\n"); > *rstvec = 0; > powerpc_sync(); > (void)(*rstvec); > powerpc_sync(); > printf("powermac_smp_start_cpu: done using *rstvec==0\n"); > > Every boot failure has had the last line reported by > FireWire dcons use as the first of those 3 printf's, > for CPU 2 as the target (of 0-3). > > The above code appears to me to execute with MSR.IR=1 > on the bsp. > > But, then, what would *rstvec do if there is no ESID=0 > V=1 combination active for the live-G5 information at > the time? Does that block the exception code that > is in what would be ESID=0's address range, effectively > preventing slbtrap from being invoked to enable ESID=0? > > In other words: when MSR.IR=1, does there always > need to be a ESID=0 V=1 entry? Is it appropriate > to reserve one for ESID=0 V=1 (after invalidating > any arbitrarily placed ESID=0 V=1 entry present > before the kernel even started)? Hi Mark, Thanks for continuing to look into this. In this case you're presenting, a ISE shouldn't really matter, because the SLB miss handler is written to run entirely from real mode to handle the miss. Can you determine what the addresses were that faulted in the failure cases? We shouldn't be touching anything below DMAP_BASE at this time, since we're not yet in userspace, and all mappings should be either KVA or DMAP. - Justin