From owner-freebsd-ppc@freebsd.org Tue Nov 15 12:04:56 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 C421DC42824 for ; Tue, 15 Nov 2016 12:04:56 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 7B6C787C; Tue, 15 Nov 2016 12:04:56 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id u144so25063050wmu.0; Tue, 15 Nov 2016 04:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=obUCpYuHzvRGNZBpGdHJKILRHokkCi0+S499wSxlki4=; b=RTUM6lBAsrwp6LTffzHrN1zq4TXwf7XZbMaeN/jxUhm8UukwVco6Jgp2IJKRDMBn1O OiEwe6YrHEioQOO7FLwmMU3nbGdRWhQAnft0ojoW4lUd0LYRVfXsCAYh4fHadb384+AG 4Y6/tZO7jdP/R77U4In4fwAOyIOgUhE4fEWJSwp+l/p0imOP1pvOVRpyHwqQYxn3JGSY VJ1FzVwyJaIQ+KdEpjz1K1+3/q+0QSq5l9k3RF7W8GU5eLo6mvO4YiP6NbX0ss3FB7cC F6kei8hMCt3Wos5wbvWzsYs6wIzk49bq/4lVO2yb7g2PhW26OjxElgGQVuaYAEiZnuah pzLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=obUCpYuHzvRGNZBpGdHJKILRHokkCi0+S499wSxlki4=; b=WIAfSi7wikyaV8q8SBiCQhQ+MqjAFbFxyLcEhrSVVGG1NLFP2+FkYMncWaDLgOIhhH jMTKOaxtpDOoogWm6/MroEAX3gcrn+wODIVXPi3EPnj8H1ftCtLpPqW9MXVeccAXeRWk X3UAVP+/oUKm8/Lz2LLnYMLt9WW0XmO62iXhERILr75KohCbVgw1aCN75oRmITeZ1i++ xcPvweT/tlLSErREucL1gsnLhDfPxBDBIXWz8puk1dUHcVEQ5wtGGrqsFWSONuo2zHsK A10IAB/KkQC3AxseIvAfOdJJJbpS/0BJ9VAwmAC+FTWPWJL/TA6K6s1uCnZK/R0quWiN fEGg== X-Gm-Message-State: ABUngve81WYJAld/mb+NFfpLIIVD36uKJp6Rqm1LchVW0iWgQMLesJK+udUkEzk6C9/EHA== X-Received: by 10.25.17.88 with SMTP id g85mr8867511lfi.10.1479211494121; Tue, 15 Nov 2016 04:04:54 -0800 (PST) Received: from [192.168.1.193] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.gmail.com with ESMTPSA id 73sm6378268ljb.6.2016.11.15.04.04.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 04:04:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Jukka Ukkonen X-Mailer: iPad Mail (14B100) In-Reply-To: Date: Tue, 15 Nov 2016 14:04:47 +0200 Cc: Nathan Whitehorn , Justin Hibbits , FreeBSD PowerPC ML , Peter Grehan Content-Transfer-Encoding: 7bit Message-Id: <5C253E59-265B-4F5F-A4C5-E4FB7EEBF084@gmail.com> References: <917EFF5A-D054-4424-9D7D-4E4BEF6072EF@gmail.com> <4bb1046a-225d-66b2-7b00-067f0d6f6c60@gmail.com> <465041D5-C1A2-48F4-9CA7-DD03B094FAE4@dsl-only.net> <01cfa4e9-954f-3e86-c8d7-36ec8523dde0@freebsd.org> To: Mark Millard 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: Tue, 15 Nov 2016 12:04:56 -0000 The bad news is that with this modification my G5 is still prone to panic during the very early phases of booting depending on which kernel modules are preloaded by loader. Some preloaded modules do not cause a panic, but they do not work either until they are unloaded and the loaded again when the kernel is already in control of everything. Preloaded modules end up in relatively low addresses. The modules loaded under the control of the kernel itself end up in very high addresses. I assume there is some sort of memory corruption which tends to make a mess in the lower addresses and some modules are very sensitive to such corruption causing panics while others are less sensitive and simply refuse to operate normally. I guess this might be related to the initialization of sprg0. IBM's documentation says sprg0 must point to a separate buffer area for each CPU, but I have failed to convince myself that sprg0 actually refers a separate CPU specific buffer space for each CPU at all times when ofw is called. The old values of the sprg# registers and something else get apparently stored in the buffer pointed by sprg0. --jau > On 15 Nov 2016, at 7.53, Mark Millard wrote: > > On 2016-Sep-21, at 3:01 PM, Peter Grehan wrote: > >>> I've never had my hands on an eMac. I'm not sure if it has the same >>> SPRGx requirements as other G4's or not. >> >> That's the machine that caused the sprg save/restore. >> https://svnweb.freebsd.org/base?view=revision&revision=151891 >> >> later, >> >> Peter. > > My patch/hack as I have always had it for booting PowerMac G5's does not > change the content for G4's (such as eMac G4's). I made a separate case > for __powerpc64__ --and only for AIM-capable as well. My code has been: > > # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =================================================================== > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 308247) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -111,6 +111,24 @@ > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > +#if defined(AIM) && defined(__powerpc64__) > +/* HACK: PowerMac G5 specific code to avoid demonstrated hangs in > + * the early boot time frame: avoid mtsprg0 use. > + * This would need a live test for PowerMac vs. not in order > + * to remove HACK status --but without calling into > + * OpenFirmware or the problem would be recreated. > + */ > + if (1) > + __asm __volatile("mfsprg0 %0\n\t" > + "mtsprg1 %1\n\t" > + "mtsprg2 %2\n\t" > + "mtsprg3 %3\n\t" > + : "=&r"(ofw_sprg0_save) > + : "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > + else > +#endif > __asm __volatile("mfsprg0 %0\n\t" > "mtsprg0 %1\n\t" > "mtsprg1 %2\n\t" > > (The comment does not reflect the modern discussion of why the > change works: the code has been around a long time.) > > I do not know if there are any AIM-capable __powerpc64__ > contexts for which the change is inappropriate. It would be > nice if it was always appropriate to that kind of context > and could be added to head and stable/11 and stable/10 . > (I've no experience before stable/10: so untested prior to > that.) > > Jukka did experiments with eliminating more --and not just for > AIM-capable __powerpc64__ but some other PowerMac contexts as > well. > > But I kept to the minimal generated-code change which appeared > to fix the problematical behavior. > > === > Mark Millard > markmi at dsl-only.net >