From owner-freebsd-ppc@freebsd.org Tue Nov 15 16:47:15 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 0566EC437AD for ; Tue, 15 Nov 2016 16:47:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 AEF861227; Tue, 15 Nov 2016 16:47:14 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ua0-x236.google.com with SMTP id 51so92246467uai.1; Tue, 15 Nov 2016 08:47:14 -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=n7HYjv4gQyI3GiLk3avEXMaf8it4XFrFLshToPbVn0A=; b=nKlFitNvRZsJcwwQVFqQm6Ti1Hr4zLcJfj+CiiF2V7T5ZVHhgwm4muZAM3IsCFFBge mMiPM7P0Lqnjpmg72+rtWyrmB0QFPp6uZn/NuJrFS034cuQG4WRMonaYNnS4I1gHrbt3 hVF6SLpVNt9YhN/4Ew45QSHKH8v9Q6GR+1W5n9WwbYld77qSVDH1nUGo6wPEpAZEuPd6 JCXELhEeyLdgF33KwbihwRkkAh9rw3oXwkckkhx2XVYXzX/Y/+tt4C3nNJpUa14Z5d7a Ix7SIFtTwzc/vyCYn2i7La8eKQFXwVk57ZrZukq7K0yzlhCVejYovFcynYnSmz62ymnY XgaQ== 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=n7HYjv4gQyI3GiLk3avEXMaf8it4XFrFLshToPbVn0A=; b=cHonbh1qMyepQG8NS88oOU67C/Ze8KFGR6U7ZWxO+xxOaT9eLToO/jPRXeGET5kujB NqS8eFSLIVBpAqFNlV+MVWPI6O/+89+PdyUg/LSq/ato5AnmLfxmk9MQwXdBIVeEydgI RqrMyJYCSHFl4laoSzgV7x13KrvIBt+nxu/WWuqZ4+sRNss3vpAw0DgrkOO8+6HN2McC +fWxPCgeCElzhtF9pT31huU00SD8krxkHe5vnEptCL97WRQkPO9HQCwCcSF47w1Y7q5P gifphj6NOAKXkILkUNMrHhM7oQ+tPXjxJQtdcw/K8sm4jR4GdWYiQlvEGs7Lw1F6bJ/q kL6Q== X-Gm-Message-State: ABUngve93GczWrcLBJKKoJH6J65SFWR5F+z9XAHxYD0WvVew5ELTcrG2+LOPw1PNjIW/i00wI/DQEWwHP7T2CA== X-Received: by 10.176.0.147 with SMTP id 19mr11531256uaj.20.1479228433591; Tue, 15 Nov 2016 08:47:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.150.66 with HTTP; Tue, 15 Nov 2016 08:47:13 -0800 (PST) In-Reply-To: <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> <5C253E59-265B-4F5F-A4C5-E4FB7EEBF084@gmail.com> From: Justin Hibbits Date: Tue, 15 Nov 2016 10:47:13 -0600 Message-ID: Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] To: Jukka Ukkonen Cc: Mark Millard , Nathan Whitehorn , FreeBSD PowerPC ML , Peter Grehan Content-Type: text/plain; charset=UTF-8 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 16:47:15 -0000 Can you point me to documentation that states sprg0 must point to separate buffer areas? IIRC, when we make OF calls, at least on Apple hardware, we suspend all other CPUs, so they shouldn't be doing anything in OF. - Justin On Tue, Nov 15, 2016 at 6:04 AM, Jukka Ukkonen wrote: > > 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 >>