From owner-freebsd-ppc@freebsd.org Mon Nov 14 10:32:08 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 B3FACC3EB6E for ; Mon, 14 Nov 2016 10:32:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-44.reflexion.net [208.70.210.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2FA1BF2 for ; Mon, 14 Nov 2016 10:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25150 invoked from network); 14 Nov 2016 10:33:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Nov 2016 10:33:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Mon, 14 Nov 2016 05:32:06 -0500 (EST) Received: (qmail 21459 invoked from network); 14 Nov 2016 10:32:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Nov 2016 10:32:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ED35DEC7B30; Mon, 14 Nov 2016 02:31:59 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: LLDB vs. powerpc (32-bit) atomic 8-byte operations that are missing: Should llvm bugzilla "blocks powerpc FreeBSD" list this? Message-Id: <80A296A3-6E41-4E2F-9EA8-B419DC24C87A@dsl-only.net> Date: Mon, 14 Nov 2016 02:31:59 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) 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: Mon, 14 Nov 2016 10:32:08 -0000 Its been a while since I checked but last I knew both of the following = were true for powerpc (32-bit): A) LLDB requires 8-byte wide atomic operations B) FreeBSD/clang3.8.0 do not provide implementations of at least some of = those operations for powerpc (32-bit). Is this something for FreeBSD to address? llvm? Is this something else that llvm bugzilla should also list as an item = that blocks FreeBSD having clang/lldb as the system toolchain for 32-bit = powerpc FreeBSD? ("Yes" if llvm has to provide the fixes; "no" if llvm = is not to provide the fixes.) (I do not list here the other things pending for llvm to allow clang as = the FreeBSD system compiler for powerpc (32-bit) or for powerpc64. This = year llvm trunk had fixes checked in to several of the issues.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Nov 15 05:53:22 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 088E4C42387 for ; Tue, 15 Nov 2016 05:53:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A92091EBC for ; Tue, 15 Nov 2016 05:53:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23498 invoked from network); 15 Nov 2016 05:53:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Nov 2016 05:53:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Tue, 15 Nov 2016 00:53:25 -0500 (EST) Received: (qmail 6175 invoked from network); 15 Nov 2016 05:53:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2016 05:53:25 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D21A5EC7B30; Mon, 14 Nov 2016 21:53:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: <01cfa4e9-954f-3e86-c8d7-36ec8523dde0@freebsd.org> Date: Mon, 14 Nov 2016 21:53:18 -0800 Cc: "Jukka A. Ukkonen" , Justin Hibbits , FreeBSD PowerPC ML , Peter Grehan Content-Transfer-Encoding: 7bit Message-Id: 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: Nathan Whitehorn X-Mailer: Apple Mail (2.3251) 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 05:53:22 -0000 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 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 > 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 >> From owner-freebsd-ppc@freebsd.org Tue Nov 15 18:52:21 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 227B7C431BA for ; Tue, 15 Nov 2016 18:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6F111BF9 for ; Tue, 15 Nov 2016 18:52:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31734 invoked from network); 15 Nov 2016 18:52:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Nov 2016 18:52:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Tue, 15 Nov 2016 13:52:28 -0500 (EST) Received: (qmail 22536 invoked from network); 15 Nov 2016 18:52:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2016 18:52:28 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C8C0DEC8FDF; Tue, 15 Nov 2016 10:52:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: <5C253E59-265B-4F5F-A4C5-E4FB7EEBF084@gmail.com> Date: Tue, 15 Nov 2016 10:52:17 -0800 Cc: Nathan Whitehorn , Justin Hibbits , FreeBSD PowerPC ML , Peter Grehan Content-Transfer-Encoding: quoted-printable Message-Id: <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> 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> To: Jukka Ukkonen X-Mailer: Apple Mail (2.3251) 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 18:52:21 -0000 On 2016-Nov-15, at 4: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. >=20 > --jau >=20 Ignoring for the moment why explicit run-time loads might not work. . . You might be able to create and use your own kernel configuration that pre-builds the modules that you want into the kernel. This might avoid the problems. I do not touch the standard FreeBSD KERNCONF's but include them in mine. Below is what I do that adds sc and and that turns off INVARIANTS, WITNESS, and the like even if the original GENERIC64 has them turned on. I normally do not worry about duplicating something from the included KERNCONF but instead force what I'm interested in at the time. # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 # # GENERIC -- Custom configuration for the powerpc/powerpc64 # include "GENERIC64" ident GENERIC64vtsc-NODGB makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones You might not want to enable DDB (and/or GDB). In the early boot things are not ready for user input to ddb. I actually modify ddb to execute an internal script automatically before it gets to the prompt. DDB input does work for problems that happen late enough. (GDB may well be irrelevant. It is carry over from my first experiments and I've never disabled it but also have never used it.) I specify KERNCONF=3DGENERIC64vtsc-NODBG in my kernel building activities for powerpc64 in order to use the above. It the past you have listed the following as problems: tmpfs mqueuefs iicsmb Have you tried putting these into the kernel itself? options TMPFS options P1003_1B_MQUEUE device iicsmb If being in the kernel gets rid of the problems: A) You then have a workaround. B) It is evidence that might eventually contribute to understanding the failing case (compare and contrast with runtime loading). I do not know if run-time loaded modules are supposed to stay in low memory or not (vs. being relocated). That would be a question for Nathan I'd guess. iicsmb depends on iicbus, and iicbus is a device in the kernel = (GENERIC64). So iicbus relocates if/when the kernel is relocated. That would mean = that iicsmb would have to track such relocations if they happen after iicsmb = is loaded. (I do not know the detailed ordering of things. I'd have to go analyze the source code to figure it out.) I will note that so far I've not seen anything that even suggests if SPRG registers are involved in your problems or not. My memory of = what I saw in the kernel code back when I was finding the hack matches up = with what Justin said about OFW calls on the PowerMacs: only one CPU/core is active at the time. Openfirmware calls interfere with concurrency in = order to protect the system: they have rather high overhead in the system. (Of course if openfirmware itself ever started a CPU/core there likely would be uncontrolled consequences.) It is too bad that "set usefdt=3D1" failed when I tried it on the quad = core. May be I should try it again now that I'm running a more recent version = of head instead of -r302214. What I got under -r302214 was: Ok set usefdt=3D1 Ok boot Booting... Error -2 adding node /ht@0,f2000000/pci@8/macio@7/i2c@18000/i2c-bus@0 = (i2c-bus@0), skipping kernel entry at 0x100120 Invalid memory access at %SRR0: 00000000.00100120 %SRR1: = 10000000.00083030 It then reported the Apple model and firmware version and and some other Apple text and got stuck. (Power switch time.) Without the "set usefdt=3D1" it booted normally. I have access to the powerpc's and powerpc64's again (at least for now). So technically it is possible for me to do experiments again. Because of my bias to testing and reporting clang/clang++ issues for powerpc64 and powerpc I run head or the clang import project on the powerpc*'s. I'm waiting on a couple of llvm powerpc64 and powerpc fixes being = applied to projects/clang390-import before switching to it so currently I'm running head (-r308247 at the moment). >> On 15 Nov 2016, at 7.53, Mark Millard wrote: >>=20 >> On 2016-Sep-21, at 3:01 PM, Peter Grehan = wrote: >>=20 >>>> 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. >>>=20 >>> That's the machine that caused the sprg save/restore. >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D151891 >>>=20 >>> later, >>>=20 >>> Peter. >>=20 >> 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: >>=20 >> # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c=20 >> Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /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" >> + : "=3D&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" >>=20 >> (The comment does not reflect the modern discussion of why the >> change works: the code has been around a long time.) >>=20 >> 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.) >>=20 >> Jukka did experiments with eliminating more --and not just for >> AIM-capable __powerpc64__ but some other PowerMac contexts as >> well. >>=20 >> But I kept to the minimal generated-code change which appeared >> to fix the problematical behavior. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Nov 15 21:42:43 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 EBCAAC43450 for ; Tue, 15 Nov 2016 21:42:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF0E11F0A for ; Tue, 15 Nov 2016 21:42:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14632 invoked from network); 15 Nov 2016 21:42:27 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Nov 2016 21:42:27 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Tue, 15 Nov 2016 16:42:51 -0500 (EST) Received: (qmail 10498 invoked from network); 15 Nov 2016 21:42:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2016 21:42:51 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 19120EC884C; Tue, 15 Nov 2016 13:42:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> Date: Tue, 15 Nov 2016 13:42:40 -0800 Cc: Nathan Whitehorn , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> 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> <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> To: Jukka Ukkonen X-Mailer: Apple Mail (2.3251) 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 21:42:44 -0000 [Top post of an experiment with loading iicsmb.ko from the loader = prompt.] I stopped a PowerMac G5 "Quad Core" at the loader prompt (not using /boot/loader.conf or other such) and did a: load iicsmb boot (smbus.ko also loads --and so for my earlier "in kernel" suggestion "device smbus" should also be listed in the KERNCONF file.) It booted fine. Afterwards kldstat reported: # kldstat Id Refs Address Size Name 1 6 0x100000 16901b0 kernel 2 1 0x1792000 14598 iicsmb.ko 3 2 0x17a7000 13f80 smbus.ko Those are not the addresses that were reported at the loader prompt for iicsmb and smbus: .text for iccsmb was listed as at 0x28e0 if I remember right .text for smbus was listed as at 0x2800 if I remember right The .data for each were listed at the loader prompt as each starting in the 0x6xxx range as I remember. I'm not sure that what the loader prompt context listed was actually the load addresses at that time. I do not know if you get similar results or not. If the loader prompt loads always work and the loader.conf loads do not that might also be interesting evidence about the problem(s) involved. I do not know how to tell if iicsmb and smbus are working or not. It may be that explicit loads from the loader prompt are another workaround. I have not yet tried: unload load iccsmb boot Context details (with my boot-hack for PowerMac G5's and such): # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Fri Nov = 4 03:18:34 PDT 2016 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/= src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200014 1200014 # svnlite status /usr/src/ M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp M /usr/src/lib/csu/powerpc64/Makefile ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/exec_machdep.c (exec_machdep.c has my "red-zone for signals" hack for 32-bit powerpc to deal with clang's stack-handling ABI violations in the powerpc 32-bit code that it generates. That allowed me to continue and find other clang code generation problems for the context.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-15, at 10:52 AM, Mark Millard wrote: On 2016-Nov-15, at 4: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. >=20 > --jau >=20 Ignoring for the moment why explicit run-time loads might not work. . . You might be able to create and use your own kernel configuration that pre-builds the modules that you want into the kernel. This might avoid the problems. I do not touch the standard FreeBSD KERNCONF's but include them in mine. Below is what I do that adds sc and and that turns off INVARIANTS, WITNESS, and the like even if the original GENERIC64 has them turned on. I normally do not worry about duplicating something from the included KERNCONF but instead force what I'm interested in at the time. # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 # # GENERIC -- Custom configuration for the powerpc/powerpc64 # include "GENERIC64" ident GENERIC64vtsc-NODGB makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones You might not want to enable DDB (and/or GDB). In the early boot things are not ready for user input to ddb. I actually modify ddb to execute an internal script automatically before it gets to the prompt. DDB input does work for problems that happen late enough. (GDB may well be irrelevant. It is carry over from my first experiments and I've never disabled it but also have never used it.) I specify KERNCONF=3DGENERIC64vtsc-NODBG in my kernel building activities for powerpc64 in order to use the above. It the past you have listed the following as problems: tmpfs mqueuefs iicsmb Have you tried putting these into the kernel itself? options TMPFS options P1003_1B_MQUEUE device iicsmb If being in the kernel gets rid of the problems: A) You then have a workaround. B) It is evidence that might eventually contribute to understanding the failing case (compare and contrast with runtime loading). I do not know if run-time loaded modules are supposed to stay in low memory or not (vs. being relocated). That would be a question for Nathan I'd guess. iicsmb depends on iicbus, and iicbus is a device in the kernel = (GENERIC64). So iicbus relocates if/when the kernel is relocated. That would mean = that iicsmb would have to track such relocations if they happen after iicsmb = is loaded. (I do not know the detailed ordering of things. I'd have to go analyze the source code to figure it out.) I will note that so far I've not seen anything that even suggests if SPRG registers are involved in your problems or not. My memory of = what I saw in the kernel code back when I was finding the hack matches up = with what Justin said about OFW calls on the PowerMacs: only one CPU/core is active at the time. Openfirmware calls interfere with concurrency in = order to protect the system: they have rather high overhead in the system. (Of course if openfirmware itself ever started a CPU/core there likely would be uncontrolled consequences.) It is too bad that "set usefdt=3D1" failed when I tried it on the quad = core. May be I should try it again now that I'm running a more recent version = of head instead of -r302214. What I got under -r302214 was: Ok set usefdt=3D1 Ok boot Booting... Error -2 adding node /ht@0,f2000000/pci@8/macio@7/i2c@18000/i2c-bus@0 = (i2c-bus@0), skipping kernel entry at 0x100120 Invalid memory access at %SRR0: 00000000.00100120 %SRR1: = 10000000.00083030 It then reported the Apple model and firmware version and and some other Apple text and got stuck. (Power switch time.) Without the "set usefdt=3D1" it booted normally. I have access to the powerpc's and powerpc64's again (at least for now). So technically it is possible for me to do experiments again. Because of my bias to testing and reporting clang/clang++ issues for powerpc64 and powerpc I run head or the clang import project on the powerpc*'s. I'm waiting on a couple of llvm powerpc64 and powerpc fixes being = applied to projects/clang390-import before switching to it so currently I'm running head (-r308247 at the moment). >> On 15 Nov 2016, at 7.53, Mark Millard wrote: >>=20 >> On 2016-Sep-21, at 3:01 PM, Peter Grehan = wrote: >>=20 >>>> 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. >>>=20 >>> That's the machine that caused the sprg save/restore. >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D151891 >>>=20 >>> later, >>>=20 >>> Peter. >>=20 >> 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: >>=20 >> # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c=20 >> Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /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" >> + : "=3D&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" >>=20 >> (The comment does not reflect the modern discussion of why the >> change works: the code has been around a long time.) >>=20 >> 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.) >>=20 >> Jukka did experiments with eliminating more --and not just for >> AIM-capable __powerpc64__ but some other PowerMac contexts as >> well. >>=20 >> But I kept to the minimal generated-code change which appeared >> to fix the problematical behavior. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Nov 15 23:08:11 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 9F7BFC44DC6 for ; Tue, 15 Nov 2016 23:08:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4496E15B9 for ; Tue, 15 Nov 2016 23:08:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5185 invoked from network); 15 Nov 2016 23:01:14 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Nov 2016 23:01:14 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Tue, 15 Nov 2016 18:01:39 -0500 (EST) Received: (qmail 29299 invoked from network); 15 Nov 2016 23:01:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2016 23:01:39 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A16ADEC9022; Tue, 15 Nov 2016 15:01:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> Date: Tue, 15 Nov 2016 15:01:28 -0800 Cc: FreeBSD PowerPC ML , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: 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> <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> To: Jukka Ukkonen X-Mailer: Apple Mail (2.3251) 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 23:08:11 -0000 On 2016-Nov-15, at 1:42 PM, Mark Millard wrote: > [Top post of an experiment with loading iicsmb.ko from the loader = prompt.] >=20 > I stopped a PowerMac G5 "Quad Core" at the loader prompt (not > using /boot/loader.conf or other such) and did a: >=20 > load iicsmb > boot >=20 > (smbus.ko also loads --and so for my earlier "in kernel" suggestion > "device smbus" should also be listed in the KERNCONF file.) >=20 > It booted fine. Afterwards kldstat reported: >=20 > # kldstat > Id Refs Address Size Name > 1 6 0x100000 16901b0 kernel > 2 1 0x1792000 14598 iicsmb.ko > 3 2 0x17a7000 13f80 smbus.ko >=20 > Those are not the addresses that were reported at the loader prompt = for > iicsmb and smbus: >=20 > .text for iccsmb was listed as at 0x28e0 if I remember right > .text for smbus was listed as at 0x2800 if I remember right >=20 > The .data for each were listed at the loader prompt as each starting = in > the 0x6xxx range as I remember. One too many x's: 0x6c8 and 0x600 were the figures. > I'm not sure that what the loader prompt context listed was actually = the > load addresses at that time. >=20 > I do not know if you get similar results or not. >=20 > If the loader prompt loads always work and the loader.conf loads do = not > that might also be interesting evidence about the problem(s) involved. >=20 > I do not know how to tell if iicsmb and smbus are working or not. >=20 > It may be that explicit loads from the loader prompt are another > workaround. >=20 >=20 > I have not yet tried: >=20 > unload > load iccsmb > boot (typo above: iicsmb is what I loaded.) That did not work: the kernel needs to be loaded first. . . unload load kernel load iicsmb boot did work. The kldstat then ends up being: # kldstat Id Refs Address Size Name 1 6 0x100000 16901b0 kernel 2 1 0x1791000 14598 iicsmb.ko 3 2 0x17a6000 13f80 smbus.ko (Not much different --but not identical to before for 2 of the Address = values.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Nov 16 00:18: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 AAEF4C4436A for ; Wed, 16 Nov 2016 00:18:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-33.reflexion.net [208.70.210.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DA8119E3 for ; Wed, 16 Nov 2016 00:18:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3296 invoked from network); 16 Nov 2016 00:18:22 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Nov 2016 00:18:22 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Tue, 15 Nov 2016 19:18:21 -0500 (EST) Received: (qmail 12942 invoked from network); 16 Nov 2016 00:18:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Nov 2016 00:18:21 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B048DEC9022; Tue, 15 Nov 2016 16:18:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: Date: Tue, 15 Nov 2016 16:18:35 -0800 Cc: Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: 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> <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> To: Jukka Ukkonen X-Mailer: Apple Mail (2.3251) 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: Wed, 16 Nov 2016 00:18:38 -0000 On 2016-Nov-15, at 3:01 PM, Mark Millard wrote: > On 2016-Nov-15, at 1:42 PM, Mark Millard = wrote: >=20 >> [Top post of an experiment with loading iicsmb.ko from the loader = prompt.] >>=20 >> I stopped a PowerMac G5 "Quad Core" at the loader prompt (not >> using /boot/loader.conf or other such) and did a: >>=20 >> load iicsmb >> boot >>=20 >> (smbus.ko also loads --and so for my earlier "in kernel" suggestion >> "device smbus" should also be listed in the KERNCONF file.) >>=20 >> It booted fine. Afterwards kldstat reported: >>=20 >> # kldstat >> Id Refs Address Size Name >> 1 6 0x100000 16901b0 kernel >> 2 1 0x1792000 14598 iicsmb.ko >> 3 2 0x17a7000 13f80 smbus.ko >>=20 >> Those are not the addresses that were reported at the loader prompt = for >> iicsmb and smbus: >>=20 >> .text for iccsmb was listed as at 0x28e0 if I remember right >> .text for smbus was listed as at 0x2800 if I remember right >>=20 >> The .data for each were listed at the loader prompt as each starting = in >> the 0x6xxx range as I remember. >=20 > One too many x's: 0x6c8 and 0x600 were the figures. >=20 >> I'm not sure that what the loader prompt context listed was actually = the >> load addresses at that time. >>=20 >> I do not know if you get similar results or not. >>=20 >> If the loader prompt loads always work and the loader.conf loads do = not >> that might also be interesting evidence about the problem(s) = involved. >>=20 >> I do not know how to tell if iicsmb and smbus are working or not. >>=20 >> It may be that explicit loads from the loader prompt are another >> workaround. >>=20 >>=20 >> I have not yet tried: >>=20 >> unload >> load iccsmb >> boot >=20 > (typo above: iicsmb is what I loaded.) >=20 > That did not work: the kernel needs to be loaded first. . . >=20 > unload > load kernel > load iicsmb > boot >=20 > did work. The kldstat then ends up being: >=20 > # kldstat > Id Refs Address Size Name > 1 6 0x100000 16901b0 kernel > 2 1 0x1791000 14598 iicsmb.ko > 3 2 0x17a6000 13f80 smbus.ko >=20 > (Not much different --but not identical to before for 2 of the Address = values.) Based on: # more /boot/loader.conf #verbose_loading=3D"YES" kernel=3D"kernel" kern.vty=3Dvt dumpdev=3D"/dev/label/FBSDG5Lswap" smbus_load=3D"YES" iicsmb_load=3D"YES" I have no trouble booting the PowerMac G5 (with my version of the boot hack in place). (I do not use any hack for 32-bit powerpc.) # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Fri Nov = 4 03:18:34 PDT 2016 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/= src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200014 1200014 Unfortunately we then hit my odd context from doing libc++ based builds for powerpc64, including self-hosted builds, and my experimenting with clang. I use devel/powerpc-xtoolchain-gcc (and so devel/powerpc64-gcc) to buildworld buildkernel for powerpc64, be it cross compiling from amd64 or on the powerpc64 itself (self hosted cross build). (A work around is required to get it installed on a powerpc64 FreeBSD.) I use a libc++ based build --something gcc 4.2.1 will not do. For self hosting on powerpc64 I use lang/gcc49 as the so-called "system compiler" and devel/powerpc64-gcc as the "cross" compiler for buildworld buildkernel . So my src.conf sort of content and related context is probably not like yours (showing for self-hosted below). I list several files with details of my buildworld buildkernel environment. (There are long lines likely implicitly wrapped in the below --in addition to \ end-of-line notation.) # more = ~/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_clang_x= toolchain-powerpc64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-powerpc64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-= host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64" = \ make $* # more ~/src.configs/make.conf=20 CFLAGS.gcc+=3D -v # more ~/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3D${TO_TYPE} TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but not xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11= -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 .export CC .export CXX .export CPP = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size #NO-SUCH: = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings STRINGS=3D/usr/local/bin/strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 # # GENERIC -- Custom configuration for the powerpc/powerpc64 # include "GENERIC64" ident GENERIC64vtsc-NODGB makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c=20 Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /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" + : "=3D&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" You have not sent out such materials for anyone to look at so I've no clue what all the differences might be in what you have. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Nov 16 14:33:29 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 35646C45A49 for ; Wed, 16 Nov 2016 14:33:29 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 B68DE1178; Wed, 16 Nov 2016 14:33:28 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id t79so76644549wmt.0; Wed, 16 Nov 2016 06:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IcOCJ6skqypuWuCKmezcWHtXXk6ATiYpecUcNwe+5dg=; b=MYTw4fCuu4GK2voeqKPSr8C6wBadrO6AQv9LY2FOnoTLVuMe00eVQHh4Y3MdyG/7bb wzcPzN/LJJRF68eUYmQE85WmTVm5XNLAJCp4Tw7SkVqw5391oG9/H15J0EE58O1TmoMd VYq8BLiKB8rGzJ9ZA3dYCaicaIgRlA4N4gUwh4ao559mnxurc1NfNFeQ+3StVTh/401b LO1kuvHFzpZRP7PDyxdOqorxpVyfwGKIghU3Gs9rRtDnI1fu0RdkKmNvgjbzyGLbWmkS Oi4lAezSn1D1cW7dEqSCTaPlOPbJh920FYVwWrfJpu9Gw/rIAumKVb0WPwtvXxtUer7L NNgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IcOCJ6skqypuWuCKmezcWHtXXk6ATiYpecUcNwe+5dg=; b=J5BCdT2CM5fsiko3qKRh58vry+Aqc1n/8GEUub4ybKRjRCDcfCXHyGAamNYAgy/WAL otrTsZbRi/XY2tN7/xl4WUU3xTIczFkDo+TrOlr5zp/xTtHZA6NIPo6Yv4Z3OHcXSk7N dgyFYqiOwa/14awDcimkHLHNqFf8wrlPyJCLntDHYxgHG7jdAfJ9CKY7kD15Ior7ABcF Q2VPay83K9i7+34GRBAfYeY/Qp7hAuTmMH7ZpySuZuc/dOlYD/eV3vbOlbsJ+IpHEwOS jF+Bf85M8cJnbQQ4a5aAefhu9vR0Qc+2cYG0dHUM3lSRdCq35rXDHqX0gPusR5ea3vYD YueQ== X-Gm-Message-State: ABUngvciDxKJHGKngPxjc1MC0Ji7bXauxa0hL5qdONIHmhJrkhXXHqN0u9eIzdt+FAxKyQ== X-Received: by 10.25.193.196 with SMTP id r187mr1364998lff.21.1479306807207; Wed, 16 Nov 2016 06:33:27 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id k94sm5361417lfi.5.2016.11.16.06.33.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 06:33:26 -0800 (PST) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] To: Justin Hibbits 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> Cc: Mark Millard , Nathan Whitehorn , FreeBSD PowerPC ML , Peter Grehan From: "Jukka A. Ukkonen" Message-ID: Date: Wed, 16 Nov 2016 16:33:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Wed, 16 Nov 2016 14:33:29 -0000 On 11/15/16 18:47, Justin Hibbits wrote: > 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. I sent a copy directly to Justin, but I do not wish to send a 722 page PDF file to everybody on the mailing list. If you wish to get a copy by e-mail, please, request for one in a separate personal e-mail, not on the mailing list. I guess the document should be available also on the IBM web site. The title of the document is... IBM PowerPC Microprocessor Family: The Programming Environment Manual for 32 and 64-bit Microprocessors Version 2.3 March 31, 2005 The detail about sprg0 is on page 75/722 in a table at the bottom of the page. --jau From owner-freebsd-ppc@freebsd.org Wed Nov 16 14:44:58 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 3937FC45CDF for ; Wed, 16 Nov 2016 14:44:58 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFD321760 for ; Wed, 16 Nov 2016 14:44:57 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) X-MSFBL: zKegfabCdy5G+6/dx8hLwke7V/nqotpxz18j0XTSwtk=|eyJnIjoiU25zdGVsZWN vbV9kZWRpY2F0ZWRfcG9vbCIsImIiOiI3NF85MV84NV8yMzgiLCJyIjoiZnJlZWJ zZC1wcGNAZnJlZWJzZC5vcmcifQ== Received: from [192.168.80.22] ([192.168.80.22:38692] helo=rs-ord-mta02-in2.smtp.com) by rs-ord-mta03-4.smtp.com (envelope-from ) (ecelerity 4.2.1.55028 r(Core:4.2.1.12)) with ESMTP id 1A/11-14625-7C26C285; Wed, 16 Nov 2016 13:44:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1479303879; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=uvFWiCy7mmVflL9mwUFGHJ7Hu9mtpbeSomAXdlMVQ9s=; b=DYyxCGw/ScG8O9zD/G2bIENiIhrPP7sHDaJUV41/SIK3WagK27IYhBPtWqOagHxH +P+cX1nTnwfKes0xnzi1FkwUHCBfkl4gnwLszwfE5Mn/GFBgX36UEjsR8Z1wqBFO jNDnPjXgX2MA14eo1RIqlgti2majqRUcox3xEF6zAhw=; Received: from [70.79.69.78] ([70.79.69.78:43028] helo=S01061c1b689e28c7.vc.shawcable.net) by rs-ord-mta02-in2.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id BF/7D-21039-7C26C285; Wed, 16 Nov 2016 13:44:39 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsresearchreports.com To: freebsd-ppc@freebsd.org Subject: mHealth (Mobile Healthcare) Ecosystem: 2017 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Wed, 16 Nov 2016 05:43:45 -0800 Message-ID: <101884010099201829222491@Ankur> X-Report-Abuse: SMTP.com is an email service provider. Our abuse team cares about your feedback. Please contact abuse@smtp.com for further investigation. X-SMTPCOM-Tracking-Number: 75ab7b6c-de78-4839-93a7-101d5a286dcc X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Wed, 16 Nov 2016 14:44:58 -0000 mHealth (Mobile Healthcare) Ecosystem: 2017 =96 2030 =96 Opportunities, Cha= llenges, Strategies & Forecasts (Report) Hello Let me offer you the latest SNS Research report to you and your team, "mHea= lth (Mobile Healthcare) Ecosystem: 2017 =96 2030 =96 Opportunities, Challen= ges, Strategies & Forecasts" Below is the report highlight and if you like = I can send you sample pages for your details inside.=20 =20 Driven by the thriving ecosystem, SNS Research estimates that the mHealth m= arket will account for over $23 Billion in 2017 alone. Despite barriers rel= ating to regulation, patient acceptance and privacy concerns, SNS Research = estimates further growth at a CAGR of more than 35% over the next three yea= rs. Report Information: Release Date: Nov 2016 Number of Pages: 424 Number of Tables and Figures: 106 Key Questions Answered: =20 What are the key market drivers and challenges for mHealth=3F What are the key applications of mHealth=3F How is the mHealth value chain structured and how will it evolve overtime=3F How big is the mHealth opportunity, and how much revenue will it generate i= n 2020=3F What will be the installed base of IoT connections for mHealth applications= in 2020=3F How many mHealth centric wearable devices will be shipped in 2020=3F Which regions, countries and submarkets will see the highest percentage of = growth=3F Who are the key market players and what are their strategies=3F What level of cost savings can mHealth facilitate for healthcare service pr= oviders in each region=3F What are the key applications of LTE and 5G networks in the mHealth market=3F What considerations should be taken into account to devise a successful mHe= alth strategy for a hospital=3F What strategies should mobile operators, enabling technology providers, mHe= alth device OEMs, healthcare service providers, pharmaceutical companies an= d application developers adopt to capitalize on the mHealth opportunity=3F Key Findings: The report has the following key findings: Driven by the thriving ecosystem, SNS Research estimates that the mHealth m= arket will account for over $23 Billion in 2017 alone. Despite barriers rel= ating to regulation, patient acceptance and privacy concerns, SNS Research = estimates further growth at a CAGR of more than 35% over the next three yea= rs. While the use of mHealth devices and apps is already widespread in clinical= trials, pharmaceutical giants are now setting their sights on connected dr= ug delivery platforms that will automatically detect and log patients=92 me= dication use to improve adherence. SNS Research estimates that mHealth centric wearable devices will account f= or over 60 Million unit shipments by the end of 2017. In order to gain valu= able insights from the data generated by these devices, healthcare service = providers and other stakeholders are increasingly investing in Big Data and= analytics technology. mHealth has the potential to dramatically reduce the costs of healthcare op= erations, while improving the quality of healthcare. SNS Research estimates= that by the end of 2017, mHealth could represent up to $370 Billion in ann= ual healthcare cost savings worldwide. The report covers the following topics: The scope and implementation of mHealth across the globe mHealth technology Market drivers and key benefits of mHealth Challenges and inhibitors to the mHealth ecosystem mHealth standardization and regulatory initiatives mHealth opportunities, use cases and applications mHealth deployment case studies Value chain analysis of the mHealth ecosystem and the recognition of key pl= ayers in each segment of the value chain mHealth industry roadmap: 2017 =96 2030 Key trends in the mHealth ecosystem; mHealth regulation, security, adoption= of cloud based mHealth services, alliances for ecosystem fortification, an= d the impact of LTE/5G deployments The role of IoT and wearable technology in the mHealth ecosystem Profiles and strategies of over 230 leading ecosystem players Strategic recommendations for mobile operators, enabling technology provide= rs, mHealth device OEMs, application developers, healthcare service provide= rs and pharmaceutical companies In-depth analysis for 5 individual submarkets and their associated mHealth = application use cases: Pharmaceutical Applications Medical Information & Healthcare Management Healthcare & Fitness Remote Consultation/Diagnostic Services IoT, Wearable Technology, Sensor & Monitoring Applications Historical revenue figures and forecasts till 2030 Forecast Segmentation: Market forecasts and historical revenue figures are provided for each of th= e following 5 submarkets and their 23 use case categories: Pharmaceutical Applications Safety Data Collection Consumer Education Medical Education Post=96Market Monitoring Drug Authentication Social Media Patient Compliance & Retention: Clinical Trials Information & Healthcare Management Electronic Health/Medical Records & Tracking Tools Diagnostic Tools & Medical Reference Continuing Medical Education Awareness Through Alerts Logistical & Payment Support Healthcare & Fitness Medical Compliance Fitness & Nutrition Apps Clinical Decision Support Systems Prescribable Mobile Apps Remote Consultation/Diagnostic Services Mobile Video Consultations, Collaboration & Surgery Non-Video Consultations & Collaboration Remote Collaboration in Emergency Situations IoT, Wearable Technology, Sensor & Monitoring Applications Health and Wellness Monitoring Disease Surveillance/Remote Monitoring Diagnostic Tools Technical Logistics Revenue is also split by ecosystem player: Ecosystem Player Segmentation Mobile Operators & Connectivity Providers Mobile & mHealth Device OEMs Content & Application Providers Healthcare Service Providers Pharmaceutical Industry The following regional and country markets are also covered: Regional Markets Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Country Markets Argentina, Australia, Brazil, Canada, China, Czech Republic, Denmark, Finla= nd, France, Germany, India, Indonesia, Israel, Italy, Japan, Malaysia, Mex= ico, Norway, Pakistan, Philippines, Poland, Qatar, Russia, Saudi Arabia, Si= ngapore, South Africa, South Korea, Spain, Sweden, Taiwan, Thailand, UAE, U= K, USA Additional forecasts are provided for the following: IoT connections for mHealth applications mHealth centric wearable device shipments Mobile video calling users Annual throughput of mobile network data traffic Smartphone, feature phone, tablet, desktop PC and notebook shipments Mobile network subscriptions by region Cost saving potential of mHealth by region Big Data & analytics technology investments in the healthcare sector =20 Report Pricing: =20 Single User License: USD 2,500 Company Wide License: USD 3,500 =20 Ordering Process: =20 Please provide the following information: Report Title - Report License - (Single User/Company Wide) Name - Email - Job Title - Company - Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned in report are given below for= more inside. I look forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com =20 _________________________________________________________________________ Table of Contents(page number): =20 1 Chapter 1: Introduction 21 1.1 Executive Summary 21 1.2 Topics Covered 23 1.3 Forecast Segmentation 25 1.4 Key Questions Answered 28 1.5 Key Findings 30 1.6 Methodology 31 1.7 Target Audience 32 1.8 Companies & Organizations Mentioned 33 =20 2 Chapter 2: An Overview of mHealth 35 2.1 What is mHealth=3F 35 2.2 The Evolution from eHealth to mHealth 35 2.3 Telemedicine 36 2.4 Health Informatics 36 2.5 The mHealth Business Case 37 2.6 Key Market Drivers 37 2.6.1 Increasing Penetration of Smartphones, Tablets & Wearables 37 2.6.2 Proliferation of Mobile Broadband Networks 40 2.6.3 The Rise of Chronic Diseases 41 2.6.4 Growing Adoption of mHealth Apps: Reduction in Lead Time 41 2.6.5 Government & Regulatory Initiatives 41 2.6.6 Physicians at Forefront of Mobility Adoption 42 2.6.7 The Cost Saving Potential of mHealth 42 2.6.8 Increasing Adoption of Open Source Software 43 2.6.9 The Role of Developed Economies 44 2.6.10 The Role of Emerging Economies 44 2.7 Barriers to Growth 45 2.7.1 Security/Privacy Concerns & Absence of Legal Guidelines 45 2.7.2 Regulation & Efficacy of Applications 45 2.7.3 Operational Maintenance & Control 45 2.7.4 Human Behavior: Disbelief Among Patients 46 2.7.5 Lack of Clear mHealth Strategies 46 2.7.6 Funding Challenges 46 2.8 Key Enabling Technologies for mHealth 47 2.8.1 Smartphones & Tablets 47 2.8.2 Mobile Apps 47 2.8.3 Mobile Broadband: The LTE & 5G Era 47 2.8.4 Wearable Devices & Sensor Technologies 48 2.8.5 IoT & M2M Connectivity 49 2.8.6 Mobile Video Calling & Multimedia Capabilities 53 2.9 mHealth Use Case Categories 54 2.9.1 Pharmaceutical Applications 55 2.9.2 Medical Information & Healthcare Management 55 2.9.3 Healthcare & Fitness 56 2.9.4 Remote Consultation/Diagnostic Services 56 2.9.5 IoT, Wearable Technology, Sensor & Monitoring Applications 57 =20 3 Chapter 3: mHealth Value Chain and Industry Roadmap 58 3.1 The mHealth Value Chain 58 3.1.1 Enabling Technology Providers and mHealth Device OEMs 59 3.1.2 Mobile Operators 59 3.1.3 Healthcare Professionals & Providers 60 3.1.4 Insurers and Government Health Systems 60 3.1.5 The Pharmaceutical Industry 60 3.1.6 Application Developers & Integrators 61 3.1.7 Patients 61 3.2 The mHealth Industry Roadmap: 2017 =96 2030 62 3.2.1 2017 =96 2020: Commercialization of Consumer Centric mHealth Apps & D= evices 62 3.2.2 2020 =96 2025: Growing Adoption of Connected Drug Delivery & Prescrib= able Medical Apps 63 3.2.3 2025 =96 2030: The Era of mHealth Analytics 63 =20 4 Chapter 4: mHealth Use Cases 64 4.1 Pharmaceutical Applications 64 4.1.1 Safety Data Collection 64 4.1.2 Consumer Education 64 4.1.3 Medical Education 64 4.1.4 Post-Market Monitoring 65 4.1.5 Drug Authentication 65 4.1.6 Social Media 65 4.1.7 Patient Compliance & Retention: Clinical Trials 66 4.2 Medical Information & Healthcare Management 66 4.2.1 EHRs (Electronic Health Records) & Tracking Tools 66 4.2.2 Diagnostic Tools & Medical Reference 66 4.2.3 Continuing Medical Education 67 4.2.4 Awareness through Alerts 67 4.2.5 Logistical & Payment Support 67 4.3 Healthcare & Fitness 68 4.3.1 Medical Compliance 68 4.3.2 Fitness & Nutrition Apps 68 4.3.3 Clinical Decision Support Systems 69 4.3.4 Prescribable Mobile Apps 69 4.4 Remote Consultation & Diagnostics Services 69 4.4.1 Mobile Video Consultations, Collaboration & Surgery 69 4.4.2 Non-Video Consultations & Collaboration 70 4.4.3 Remote Collaboration in Emergency Situations 70 4.5 IoT, Wearable Technology, Sensor & Monitoring Applications 70 4.5.1 Health & Wellness Monitoring 70 4.5.2 Disease Surveillance/Remote Monitoring 71 4.5.3 Diagnostic Tools 71 4.5.4 Technical Logistics 71 =20 5 Chapter 5: mHealth Case Studies 72 5.1 Apollo Hospitals Group: Enabling mHealth for the Masses 72 5.2 Appirio: Cutting Health Insurance Costs with Wearable Activity Trackers= 73 5.3 AT&T: Connected Healthcare Monitoring for the Elderly 74 5.4 London Air Ambulance: Saving Lives with mHealth Apps and 4G Connectivit= y 75 5.5 Novartis: Connected Drug Delivery for COPD (Chronic Obstructive Pulmona= ry Disease) 76 5.6 Orange Healthcare: Fighting Counterfeit Drugs with Text Messaging 77 5.7 Praekelt Foundation: Raising HIV/AIDS Awareness with mHealth 78 5.8 Qualcomm Life: Extending Healthcare Beyond Hospital Walls 79 5.9 Roche: Enhancing Clinical Trials with mHealth Apps 80 5.10 WellDoc: Managing Chronic Diseases with mHealth Apps 81 =20 6 Chapter 6: mHealth Solution Provider Profiles 83 6.1 270 Vision 83 6.2 3L Labs 85 6.3 3M 86 6.4 4DForce 88 6.5 4iii Innovations 89 6.6 Abbott Laboratories 90 6.7 Accenture 91 6.8 AdhereTech 92 6.9 Adherium 93 6.10 Adidas 94 6.11 Aerotel Medical Systems 96 6.12 Aetna 97 6.13 Agfa Healthcare 98 6.14 AiRISTA 99 6.15 AirStrip Technologies 100 6.16 Alego Health 102 6.17 AliveCor 103 6.18 AllScripts Healthcare 104 6.19 AMD Global Telemedicine 105 6.20 Amiigo 106 6.21 Apple 107 6.22 ASICS Corporation 109 6.23 AstraZeneca 110 6.24 AT&T 112 6.25 Athenahealth 114 6.26 Atlas Wearables 115 6.27 Augmendix 116 6.28 BettrLife 117 6.29 Big Cloud Analytics 118 6.30 Biosensics 119 6.31 BioTelemetry Technology 121 6.32 Biotricity 122 6.33 BlackBerry 123 6.34 Boehringer Ingelheim 124 6.35 Boston Scientific Corporation 125 6.36 Breakthrough Technologies 126 6.37 BSX Athletics 127 6.38 BTS Bioengineering 128 6.39 Cambridge Consultants 129 6.40 CardioComm Solutions 130 6.41 CardioNet 131 6.42 Carre Technologies 132 6.43 Catapult Sports 134 6.44 CEEK VR 136 6.45 CellTrust Corporation 137 6.46 CenTrak 138 6.47 Cerner Corporation 139 6.48 Chetu 140 6.49 CirrusMD 141 6.50 Cisco Systems 142 6.51 Cityzen Sciences 143 6.52 Codoon 144 6.53 Cohero Health 145 6.54 Companion Medical 146 6.55 Comtech Telecommunications Corporation 147 6.56 Conversa Health 148 6.57 CRF Health 149 6.58 CTC (Cambridge Temperature Concepts) 150 6.59 Cupris Health 151 6.60 Cyberdyne 152 6.61 Cypress Semiconductor Corporation 153 6.62 Diversinet 154 6.63 DocbookMD 156 6.64 dorsaVi 157 6.65 Dreamtrap Commercials 158 6.66 DT (Deutsche Telekom) 159 6.67 Ducere Technologies 160 6.68 EB Sport Group 161 6.69 eClinicalWorks 162 6.70 EE 163 6.71 Ekso Bionics 164 6.72 EMN (European Medical Network) 165 6.73 Emotiv Systems 166 6.74 Epic Systems Corporation 167 6.75 Epion Health 168 6.76 Ericsson 169 6.77 Evena Medical 170 6.78 Extension Healthcare 171 6.79 Fatigue Science 172 6.80 Finis 173 6.81 Fitbit 174 6.82 Flyfit 176 6.83 FRUCT MD 177 6.84 Fujitsu 178 6.85 Gait Up 179 6.86 Garmin 180 6.87 GE Healthcare 181 6.88 Gemalto 182 6.89 Genesis Health Technologies 183 6.90 Ginger.io 184 6.91 Google 185 6.92 GOQii 187 6.93 Grameen Foundation 188 6.94 GSK (GlaxoSmithKline) 189 6.95 Guandong Biolight Meditech 191 6.96 HealBe 192 6.97 Honeywell Life Care Solutions 193 6.98 H=F6vding 194 6.99 HPE (Hewlett Packard Enterprise) 195 6.100 Huawei 196 6.101 Human API 197 6.102 i4C Innovations 198 6.103 IBM Corporation 199 6.104 ICEdot 200 6.105 Ideal Life 201 6.106 iHealth Labs 202 6.107 Imec 203 6.108 ImPACT Applications 204 6.109 Imprivata 205 6.110 Instabeat 207 6.111 Integron Corporation 208 6.112 Intel Corporation 209 6.113 InteraXon 210 6.114 Intermountain Healthcare 211 6.115 InTouch Health 212 6.116 InvenSense 213 6.117 Invision Heart 214 6.118 IQMax 215 6.119 iRhythm Technologies 217 6.120 Jawbone 218 6.121 Jaybird 220 6.122 Johnson & Johnson 221 6.123 KDDI Corporation 222 6.124 Ki Performance 223 6.125 KORE Wireless Group 224 6.126 Kreyos 225 6.127 Lark Technologies 226 6.128 Lenovo 227 6.129 LG Electronics 228 6.130 LMD (Leman Micro Devices) 229 6.131 Lumo BodyTech 230 6.132 Magellan (MiTAC Digital Corporation) 231 6.133 McKinsey & Company 232 6.134 MDLIVE 233 6.135 Medecin Direct 234 6.136 Medella Health 235 6.137 Medisafe 236 6.138 MedM 237 6.139 MedSignals/VitalSignals 238 6.140 Medtronic 239 6.141 MedWeb 241 6.142 Melon 242 6.143 mHealthAlert 243 6.144 Microsoft 244 6.145 Mio Global 246 6.146 Misfit 247 6.147 Moov 249 6.148 Moticon 250 6.149 Motion Fitness 251 6.150 mQure 252 6.151 Myontec 253 6.152 Neurometrix 254 6.153 NeuroPro 255 6.154 Nike 256 6.155 No Isolation 258 6.156 Nokia 259 6.157 Nonin Medical 260 6.158 Notch Interfaces 261 6.159 Novartis 262 6.160 Novo Nordisk 264 6.161 NTT DoCoMo 265 6.162 Nuubo 267 6.163 NXP Semiconductors 268 6.164 NZN Labs 269 6.165 Omron Corporation 270 6.166 OMsignal 271 6.167 OPKO Health 272 6.168 Optalert 273 6.169 Orange 274 6.170 Orpyx Medical Technologies 275 6.171 O=96Synce 276 6.172 Owlet Baby Care 277 6.173 Panasonic Corporation 278 6.174 Pharmica Consulting 279 6.175 Phyode 280 6.176 Polar Electro 281 6.177 Pragmasystems 282 6.178 Preventice 283 6.179 Propeller Health 284 6.180 Proteus Digital Health 285 6.181 PUSH 286 6.182 Qardio 287 6.183 Qloudlab 288 6.184 Qualcomm Life 289 6.185 Reflexion Health 291 6.186 Rest Devices 292 6.187 Roche Holding (F. Hoffmann-La Roche) 293 6.188 Royal Philips 295 6.189 RSL Steeper Group 296 6.190 S3 Group 297 6.191 Samsung Group 298 6.192 Sanofi 300 6.193 Santech 301 6.194 SAP 302 6.195 SCOTTY Group 303 6.196 Sensible Baby 304 6.197 Senso Solutions 305 6.198 Sentimoto 306 6.199 Seraphim Sense 307 6.200 Siemens Healthcare 308 6.201 SK Telecom 309 6.202 SmartCap Technologies 310 6.203 Snaptracs 311 6.204 SoftBank Corporation 312 6.205 SoftServe 314 6.206 Somaxis 315 6.207 Sonitus Medical 316 6.208 Sony Corporation 317 6.209 Sotera Wireless 318 6.210 Stanley Healthcare 319 6.211 STMicroelectronics 320 6.212 Swisscom 321 6.213 Tactio Health Group 322 6.214 Telcare 323 6.215 Tele2 324 6.216 Telecom Italia 325 6.217 Telenor 326 6.218 Teva Pharmaceutical Industries 327 6.219 TI (Texas Instruments) 328 6.220 Toshiba Corporation 329 6.221 Tricella 330 6.222 Tunstall Group 331 6.223 U-blox 332 6.224 Valencell 333 6.225 Validic (Motivation Science) 334 6.226 Vancive Medical Technologies 335 6.227 Verizon Communications 336 6.228 Vitaphone 337 6.229 Vodafone Group 338 6.230 Voxiva 339 6.231 Wearable Intelligence 340 6.232 WellDoc 341 6.233 Wellograph 342 6.234 Xiaomi 343 6.235 Xplore Technologies 344 6.236 Xsensio 345 6.237 Zinc Software 346 6.238 Zoll Medical Corporation 347 =20 7 Chapter 7: Standardization, Regulation & Development Initiatives 348 7.1 Standardization Bodies & Alliances 348 7.1.1 ECHAlliance (European Connected Health Alliance) 348 7.1.2 Global Digital Health Network 349 7.1.3 GSMA=92s Mobile for Development mHealth Program 349 7.1.4 HIMSS (Healthcare Information and Management Systems Society) 350 7.1.5 HL7 (Health Level Seven International) 351 7.1.6 IEEE (Institute of Electrical and Electronics Engineers) 351 7.1.7 ISO (International Organization for Standardization) 352 7.1.8 ITU (International Telecommunications Union) 352 7.1.9 JHU-GmI (Johns Hopkins University Global mHealth Initiative) 353 7.1.10 PCHA (Personal Connected Health Alliance) 353 7.1.11 United Nations Foundation 354 7.1.12 WHO (World Health Organization) 355 7.1.13 WLSA (Wireless=96Life Services Alliance) 355 7.2 Key Standards & Legislation 357 7.2.1 ISO/IEEE 11073 PHD (Personal Health Device) Standards 357 7.2.2 HL7=92s PHMR (Personal Health Monitoring Report) 358 7.2.3 Continua Design Guidelines 358 7.2.4 ITU=92s E-Health Standards 359 7.2.5 HIPAA (Health Insurance Portability and Accountability Act) 359 7.2.6 HITECH (Heath Information Technology for Economic and Clinical Health= ) 360 =20 8 Chapter 8: Market Analysis & Forecasts 362 8.1 Global Outlook of mHealth Revenue: 2017 =96 2030 362 8.2 Submarket Segmentation 363 8.3 Pharmaceutical Applications Submarket Revenue: 2017 =96 2030 364 8.3.1 Safety Data Collection Use Case 365 8.3.2 Consumer Education Use Case 365 8.3.3 Medical Education Use Case 366 8.3.4 Post=96Market Monitoring Use Case 366 8.3.5 Drug Authentication Use Case 367 8.3.6 Social Media Use Case 367 8.3.7 Patient Compliance & Retention (Clinical Trials) Use Case 368 8.4 Medical Information & Healthcare Management Submarket Revenue: 2017 =96= 2030 369 8.4.1 Electronic Health/Medical Records & Tracking Tools Use Case 370 8.4.2 Diagnostic Tools & Medical Reference Use Case 370 8.4.3 Continuing Medical Education Use Case 371 8.4.4 Awareness through Alerts Use Case 371 8.4.5 Logistical & Payment Support Use Case 372 8.5 Healthcare & Fitness Submarket Revenue: 2017 =96 2030 373 8.5.1 Medical Compliance Use Case 374 8.5.2 Fitness & Nutrition Apps Use Case 374 8.5.3 Clinical Decision Support Systems Use Case 375 8.5.4 Prescribable Mobile Apps Use Case 375 8.6 Remote Consultation/Diagnostic Services Submarket Revenue: 2017 =96 203= 0 376 8.6.1 Mobile Video Consultations, Collaboration & Surgery Use Case 377 8.6.2 Non=96Video Consultations & Collaboration Use Case 377 8.6.3 Remote Collaboration in Emergency Situations Use Case 378 8.7 IoT, Wearable Technology, Sensor & Monitoring Applications Submarket Re= venue: 2017 =96 2030 379 8.7.1 Health and Wellness Monitoring Use Case 380 8.7.2 Disease Surveillance/Remote Monitoring Use Case 380 8.7.3 Diagnostic Tools Use Case 381 8.7.4 Technical Logistics Use Case 381 8.8 Segmentation by Ecosystem Player 382 8.8.1 Mobile Operators & Connectivity Providers 382 8.8.2 Mobile & mHealth Device OEMs 383 8.8.3 Content & Application Providers 383 8.8.4 Healthcare Service Providers 384 8.8.5 Pharmaceutical Industry 384 8.9 Regional Outlook 385 8.10 Asia Pacific mHealth Revenue: 2017 =96 2030 386 8.10.1 Country Level Segmentation 386 8.10.2 Australia 387 8.10.3 China 387 8.10.4 India 388 8.10.5 Japan 388 8.10.6 South Korea 389 8.10.7 Pakistan 389 8.10.8 Thailand 390 8.10.9 Indonesia 390 8.10.10 Malaysia 391 8.10.11 Taiwan 391 8.10.12 Philippines 392 8.10.13 Singapore 392 8.10.14 Rest of Asia Pacific 393 8.11 Eastern Europe mHealth Revenue: 2017 =96 2030 394 8.11.1 Country Level Segmentation 394 8.11.2 Czech Republic 395 8.11.3 Poland 395 8.11.4 Russia 396 8.11.5 Rest of Eastern Europe 396 8.12 Latin & Central America mHealth Revenue: 2017 =96 2030 397 8.12.1 Country Level Segmentation 397 8.12.2 Argentina 398 8.12.3 Brazil 398 8.12.4 Mexico 399 8.12.5 Rest of Latin & Central America 399 8.13 Middle East & Africa mHealth Revenue: 2017 =96 2030 400 8.13.1 Country Level Segmentation 400 8.13.2 Israel 401 8.13.3 Qatar 401 8.13.4 Saudi Arabia 402 8.13.5 South Africa 402 8.13.6 UAE 403 8.13.7 Rest of the Middle East & Africa 403 8.14 North America mHealth Revenue: 2017 =96 2030 404 8.14.1 Country Level Segmentation 404 8.14.2 USA 405 8.14.3 Canada 405 8.15 Western Europe mHealth Revenue: 2017 =96 2030 406 8.15.1 Country Level Segmentation 406 8.15.2 Denmark 407 8.15.3 Finland 407 8.15.4 France 408 8.15.5 Germany 408 8.15.6 Italy 409 8.15.7 Spain 409 8.15.8 Sweden 410 8.15.9 Norway 410 8.15.10 UK 411 8.15.11 Rest of Western Europe 411 =20 9 Chapter 9: Conclusion & Strategic Recommendations 412 9.1 Moving Towards Connected Drug Delivery Platforms 412 9.2 Are Prescribable mHealth Apps a Threat to the Pharmaceutical Industry= =3F 413 9.3 Will mHealth Requirements Drive HD Mobile Video Deployments=3F 413 9.4 Is mHealth Security an All-or-Nothing Decision=3F 414 9.5 Healthcare Industry Approval & Accreditation: Key to Success 414 9.6 Improving Operational Efficiency and Reducing Costs 415 9.7 Collaborations Help in Promoting mHealth 416 9.8 The Importance of End User Belief 416 9.9 Wearable Technology: Prospects in the mHealth Ecosystem 417 9.10 Are Mobile Operators Simply Connectivity Providers for mHealth=3F 418 9.11 Driving Investments in Big Data & Analytics 419 9.12 Implementing Successful mHealth Strategies in Hospitals 420 9.13 Strategic Recommendations 421 9.13.1 Recommendations for Mobile Operators 421 9.13.2 Recommendations for Enabling Technology Providers and mHealth Device= OEMs 421 9.13.3 Recommendations for Application Developers 422 9.13.4 Recommendations for Healthcare Professionals and Providers 422 9.13.5 Recommendations for the Pharmaceutical Industry 422 =20 =20 List of Figures (page number) =20 Figure 1: Global Connected Consumer Mobile Device vs. PC Shipments: 2017 = =96 2030 (Millions of Units) 41 Figure 2: Mobile Network Subscriptions by Region: 2017 =96 2030 (Millions) = 42 Figure 3: Annual Throughput of Mobile Network Data Traffic by Region: 2017 = =96 2030 (Exabytes) 43 Figure 4: Cost Saving Potential of mHealth by Region: 2017 =96 2030 ($ Mill= ion) 45 Figure 5: The IoT Vision 52 Figure 6: IoT Network Architecture 53 Figure 7: Global IoT Connections for mHealth Applications: 2017 =96 2030 (M= illions) 55 Figure 8: Global Mobile Video Calling Users: 2017 =96 2030 (Millions) 56 Figure 9: mHealth Use Case Categories 57 Figure 10: The mHealth Value Chain 61 Figure 11: mHealth Industry Roadmap: 2017 =96 2030 65 Figure 12: Global mHealth Revenue: 2017 =96 2030 ($ Million) 365 Figure 13: Global mHealth Revenue by Submarket: 2017 =96 2030 ($ Million) 3= 66 Figure 14: Global Pharmaceutical Applications Submarket Revenue: 2017 =96 2= 030 ($ Million) 367 Figure 15: Global Pharmaceutical Applications Submarket Revenue by Use Case= Category: 2017 =96 2030 ($ Million) 367 Figure 16: Global Safety Data Collection Use Case Revenue: 2017 =96 2030 ($= Million) 368 Figure 17: Global Consumer Education Use Case Revenue: 2017 =96 2030 ($ Mil= lion) 368 Figure 18: Global Medical Education Use Case Revenue: 2017 =96 2030 ($ Mill= ion) 369 Figure 19: Global Post=96Market Monitoring Use Case Revenue: 2017 =96 2030 = ($ Million) 369 Figure 20: Global Drug Authentication Use Case Revenue: 2017 =96 2030 ($ Mi= llion) 370 Figure 21: Global Social Media Use Case Revenue: 2017 =96 2030 ($ Million) = 370 Figure 22: Global Patient Compliance & Retention (Clinical Trials) Use Case= Revenue: 2017 =96 2030 ($ Million) 371 Figure 23: Global Medical Information & Healthcare Management Submarket Rev= enue: 2017 =96 2030 ($ Million) 372 Figure 24: Global Medical Information & Healthcare Management Submarket Rev= enue by Use Case Category: 2017 =96 2030 ($ Million) 372 Figure 25: Global Electronic Health/Medical Records & Tracking Tools Use Ca= se Revenue: 2017 =96 2030 ($ Million) 373 Figure 26: Global Diagnostic Tools & Medical Reference Use Case Revenue: 20= 17 =96 2030 ($ Million) 373 Figure 27: Global Continuing Medical Education Use Case Revenue: 2017 =96 2= 030 ($ Million) 374 Figure 28: Global Awareness through Alerts Use Case Revenue: 2017 =96 2030 = ($ Million) 374 Figure 29: Global Logistical & Payment Support Use Case Revenue: 2017 =96 2= 030 ($ Million) 375 Figure 30: Global Healthcare & Fitness Submarket Revenue: 2017 =96 2030 ($ = Million) 376 Figure 31: Global Healthcare & Fitness Submarket Revenue by Use Case Catego= ry: 2017 =96 2030 ($ Million) 376 Figure 32: Global Medical Compliance Use Case Revenue: 2017 =96 2030 ($ Mil= lion) 377 Figure 33: Global Fitness & Nutrition Apps Use Case Revenue: 2017 =96 2030 = ($ Million) 377 Figure 34: Global Clinical Decision Support Systems Use Case Revenue: 2017 = =96 2030 ($ Million) 378 Figure 35: Global Prescribable Mobile Apps Use Case Revenue: 2017 =96 2030 = ($ Million) 378 Figure 36: Global Remote Consultation/Diagnostic Services Submarket Revenue= : 2017 =96 2030 ($ Million) 379 Figure 37: Global Remote Consultation/Diagnostic Services Submarket Revenue= by Use Case Category: 2017 =96 2030 ($ Million) 379 Figure 38: Global Mobile Video Consultations, Collaboration & Surgery Use C= ase Revenue: 2017 =96 2030 ($ Million) 380 Figure 39: Global Non=96Video Consultations & Collaboration Use Case Revenu= e: 2017 =96 2030 ($ Million) 380 Figure 40: Global Remote Collaboration in Emergency Situations Use Case Rev= enue: 2017 =96 2030 ($ Million) 381 Figure 41: Global IoT, Wearable Technology, Sensor & Monitoring Application= s Submarket Revenue: 2017 =96 2030 ($ Million) 382 Figure 42: Global IoT, Wearable Technology, Sensor & Monitoring Application= s Submarket Revenue by Use Case Category: 2017 =96 2030 ($ Million) 382 Figure 43: Global Health and Wellness Monitoring Use Case Revenue: 2017 =96= 2030 ($ Million) 383 Figure 44: Global Disease Surveillance/Remote Monitoring Use Case Revenue: = 2017 =96 2030 ($ Million) 383 Figure 45: Global Diagnostic Tools Use Case Revenue: 2017 =96 2030 ($ Milli= on) 384 Figure 46: Global Technical Logistics Use Case Revenue: 2017 =96 2030 ($ Mi= llion) 384 Figure 47: Global mHealth Revenue by Ecosystem Player: 2017 =96 2030 ($ Mil= lion) 385 Figure 48: Global Mobile Network Operator & Connectivity Provider mHealth R= evenue: 2017 =96 2030 ($ Million) 385 Figure 49: Global Mobile & mHealth Device OEMs Revenue: 2017 =96 2030 ($ Mi= llion) 386 Figure 50: Global mHealth Content & Application Providers Revenue: 2017 =96= 2030 ($ Million) 386 Figure 51: Global Healthcare Service Providers mHealth Revenue: 2017 =96 20= 30 ($ Million) 387 Figure 52: Global Pharmaceutical Industry mHealth Revenue: 2017 =96 2030 ($= Million) 387 Figure 53: mHealth Revenue by Region: 2017 =96 2030 ($ Million) 388 Figure 54: Asia Pacific mHealth Revenue: 2017 =96 2030 ($ Million) 389 Figure 55: Asia Pacific mHealth Revenue by Country: 2017 =96 2030 ($ Millio= n) 389 Figure 56: Australia mHealth Revenue: 2017 =96 2030 ($ Million) 390 Figure 57: China mHealth Revenue: 2017 =96 2030 ($ Million) 390 Figure 58: India mHealth Revenue: 2017 =96 2030 ($ Million) 391 Figure 59: Japan mHealth Revenue: 2017 =96 2030 ($ Million) 391 Figure 60: South Korea mHealth Revenue: 2017 =96 2030 ($ Million) 392 Figure 61: Pakistan mHealth Revenue: 2017 =96 2030 ($ Million) 392 Figure 62: Thailand mHealth Revenue: 2017 =96 2030 ($ Million) 393 Figure 63: Indonesia mHealth Revenue: 2017 =96 2030 ($ Million) 393 Figure 64: Malaysia mHealth Revenue: 2017 =96 2030 ($ Million) 394 Figure 65: Taiwan mHealth Revenue: 2017 =96 2030 ($ Million) 394 Figure 66: Philippines mHealth Revenue: 2017 =96 2030 ($ Million) 395 Figure 67: Philippines mHealth Revenue: 2017 =96 2030 ($ Million) 395 Figure 68: mHealth Revenue in the Rest of Asia Pacific: 2017 =96 2030 ($ Mi= llion) 396 Figure 69: Eastern Europe mHealth Revenue: 2017 =96 2030 ($ Million) 397 Figure 70: Eastern Europe mHealth Revenue by Country: 2017 =96 2030 ($ Mill= ion) 397 Figure 71: Czech Republic mHealth Revenue: 2017 =96 2030 ($ Million) 398 Figure 72: Poland mHealth Revenue: 2017 =96 2030 ($ Million) 398 Figure 73: Russia mHealth Revenue: 2017 =96 2030 ($ Million) 399 Figure 74: mHealth Revenue in the Rest of Eastern Europe: 2017 =96 2030 ($ = Million) 399 Figure 75: Latin & Central America mHealth Revenue: 2017 =96 2030 ($ Millio= n) 400 Figure 76: Latin & Central America mHealth Revenue by Country: 2017 =96 203= 0 ($ Million) 400 Figure 77: Argentina mHealth Revenue: 2017 =96 2030 ($ Million) 401 Figure 78: Brazil mHealth Revenue: 2017 =96 2030 ($ Million) 401 Figure 79: Mexico mHealth Revenue: 2017 =96 2030 ($ Million) 402 Figure 80: mHealth Revenue in the Rest of Latin & Central America: 2017 =96= 2030 ($ Million) 402 Figure 81: Middle East & Africa mHealth Revenue: 2017 =96 2030 ($ Million) = 403 Figure 82: Middle East & Africa mHealth Revenue by Country: 2017 =96 2030 (= $ Million) 403 Figure 83: Israel mHealth Revenue: 2017 =96 2030 ($ Million) 404 Figure 84: Qatar mHealth Revenue: 2017 =96 2030 ($ Million) 404 Figure 85: Saudi Arabia mHealth Revenue: 2017 =96 2030 ($ Million) 405 Figure 86: South Africa mHealth Revenue: 2017 =96 2030 ($ Million) 405 Figure 87: UAE mHealth Revenue: 2017 =96 2030 ($ Million) 406 Figure 88: mHealth Revenue in the Rest of the Middle East & Africa: 2017 = =96 2030 ($ Million) 406 Figure 89: North America mHealth Revenue: 2017 =96 2030 ($ Million) 407 Figure 90: North America mHealth Revenue by Country: 2017 =96 2030 ($ Milli= on) 407 Figure 91: USA mHealth Revenue: 2017 =96 2030 ($ Million) 408 Figure 92: Canada mHealth Revenue: 2017 =96 2030 ($ Million) 408 Figure 93: Western Europe mHealth Revenue: 2017 =96 2030 ($ Million) 409 Figure 94: Western Europe mHealth Revenue by Country: 2017 =96 2030 ($ Mill= ion) 409 Figure 95: Denmark mHealth Revenue: 2017 =96 2030 ($ Million) 410 Figure 96: Finland mHealth Revenue: 2017 =96 2030 ($ Million) 410 Figure 97: France mHealth Revenue: 2017 =96 2030 ($ Million) 411 Figure 98: Germany mHealth Revenue: 2017 =96 2030 ($ Million) 411 Figure 99: Italy mHealth Revenue: 2017 =96 2030 ($ Million) 412 Figure 100: Spain mHealth Revenue: 2017 =96 2030 ($ Million) 412 Figure 101: Sweden mHealth Revenue: 2017 =96 2030 ($ Million) 413 Figure 102: Norway mHealth Revenue: 2017 =96 2030 ($ Million) 413 Figure 103: UK mHealth Revenue: 2017 =96 2030 ($ Million) 414 Figure 104: mHealth Revenue in the Rest of Western Europe: 2017 =96 2030 ($= Million) 414 Figure 105: Global mHealth Centric Wearable Device Shipments: 2017 =96 2030= (Millions of Units) 420 Figure 106: Global Big Data & Analytics Technology Investments in the Healt= hcare Sector: 2017 =96 2030 ($ Million) 422 =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com =20 =20 To unsubscribe please click on the link below or send an email with unsubsc= ribe in the subject line to: remove@snsreports.com =20 From owner-freebsd-ppc@freebsd.org Wed Nov 16 22:02:14 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 8804BC450D3 for ; Wed, 16 Nov 2016 22:02:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4059E132B for ; Wed, 16 Nov 2016 22:02:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1362 invoked from network); 16 Nov 2016 22:01:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Nov 2016 22:01:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Wed, 16 Nov 2016 17:02:16 -0500 (EST) Received: (qmail 4943 invoked from network); 16 Nov 2016 22:02:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Nov 2016 22:02:16 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A125CEC76EB; Wed, 16 Nov 2016 14:02:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] From: Mark Millard In-Reply-To: Date: Wed, 16 Nov 2016 14:02:05 -0800 Cc: Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <56703830-B39E-41DE-A5FA-B9C3673EA643@dsl-only.net> 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> <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> To: Jukka Ukkonen X-Mailer: Apple Mail (2.3251) 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: Wed, 16 Nov 2016 22:02:14 -0000 [This reports on not having the problem on a PowerMac7,2 as well. Also on possibilities for going forward.] On 2016-Nov-15, at 4:18 PM, Mark Millard wrote: > On 2016-Nov-15, at 3:01 PM, Mark Millard = wrote: >=20 >=20 >> On 2016-Nov-15, at 1:42 PM, Mark Millard = wrote: >>=20 >>> [Top post of an experiment with loading iicsmb.ko from the loader = prompt.] >>>=20 >>> I stopped a PowerMac G5 "Quad Core" at the loader prompt (not >>> using /boot/loader.conf or other such) and did a: >>>=20 >>> load iicsmb >>> boot >>>=20 >>> (smbus.ko also loads --and so for my earlier "in kernel" suggestion >>> "device smbus" should also be listed in the KERNCONF file.) >>>=20 >>> It booted fine. Afterwards kldstat reported: >>>=20 >>> # kldstat >>> Id Refs Address Size Name >>> 1 6 0x100000 16901b0 kernel >>> 2 1 0x1792000 14598 iicsmb.ko >>> 3 2 0x17a7000 13f80 smbus.ko >>>=20 >>> Those are not the addresses that were reported at the loader prompt = for >>> iicsmb and smbus: >>>=20 >>> .text for iccsmb was listed as at 0x28e0 if I remember right >>> .text for smbus was listed as at 0x2800 if I remember right >>>=20 >>> The .data for each were listed at the loader prompt as each starting = in >>> the 0x6xxx range as I remember. >>=20 >> One too many x's: 0x6c8 and 0x600 were the figures. >>=20 >>> I'm not sure that what the loader prompt context listed was actually = the >>> load addresses at that time. >>>=20 >>> I do not know if you get similar results or not. >>>=20 >>> If the loader prompt loads always work and the loader.conf loads do = not >>> that might also be interesting evidence about the problem(s) = involved. >>>=20 >>> I do not know how to tell if iicsmb and smbus are working or not. >>>=20 >>> It may be that explicit loads from the loader prompt are another >>> workaround. >>>=20 >>>=20 >>> I have not yet tried: >>>=20 >>> unload >>> load iccsmb >>> boot >>=20 >> (typo above: iicsmb is what I loaded.) >>=20 >> That did not work: the kernel needs to be loaded first. . . >>=20 >> unload >> load kernel >> load iicsmb >> boot >>=20 >> did work. The kldstat then ends up being: >>=20 >> # kldstat >> Id Refs Address Size Name >> 1 6 0x100000 16901b0 kernel >> 2 1 0x1791000 14598 iicsmb.ko >> 3 2 0x17a6000 13f80 smbus.ko >>=20 >> (Not much different --but not identical to before for 2 of the = Address values.) >=20 > Based on: >=20 > # more /boot/loader.conf > #verbose_loading=3D"YES" > kernel=3D"kernel" > kern.vty=3Dvt > dumpdev=3D"/dev/label/FBSDG5Lswap" > smbus_load=3D"YES" > iicsmb_load=3D"YES" >=20 > I have no trouble booting the PowerMac G5 (with my version of the boot > hack in place). (I do not use any hack for 32-bit powerpc.) I temporarily moved the SSD from that PowerMac11,3 to the PowerMac7,2 = that I have access to. The PowerMac7,2 behaves like the above as well: I've not been able to reproduce any boot time problems with using iicsmb_load=3D"YES" in /boot/loader.conf . I do not have access to any other types of PowerMac G5's (or to non-PowerMac powerpc64 systems). On the information that I currently have available it does not appear that I can help you track down what is going on in your environment. It appears I'd have to try to reproduce how you configure and build your kernel and possibly other details to have a chance to reproduce the problem. My results do tend to suggest that the SPRG0 handling in my hack for supporting PowerMac G5's booting reliably is not part of the problem (otherwise I'd likely have been able to reproduce the boot crashes that you report). (You experimented with variations on my hack and I do not know if your current variant and mine match for the code generated.) As I do not know how to test if iicsmb is working, you could let me know of a good way to check that if one is available on a basic PowerMac configuration. Another option is for you to try building using as much of the build configuration information that I've provided as you can to see if the problem goes away. If you have the PowerMac self-host buildworld buildkernel I'd also need to provide notes about getting powerpc64-gcc installed. (lang/gcc49 is also used but should install fine, at least if you select to avoid including the JAVA material.) If you cross build I could provide alternate src.conf content for that. (Actually I use SRC_ENV_CONF currently, per the script that I had included in what I reported.) Too bad we have not been able to figure this out (yet). > # uname -apKU > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Fri Nov = 4 03:18:34 PDT 2016 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/= src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200014 1200014 >=20 > Unfortunately we then hit my odd context from doing libc++ based = builds > for powerpc64, including self-hosted builds, and my experimenting with > clang. >=20 > I use devel/powerpc-xtoolchain-gcc (and so devel/powerpc64-gcc) to > buildworld buildkernel for powerpc64, be it cross compiling from amd64 > or on the powerpc64 itself (self hosted cross build). (A work around = is > required to get it installed on a powerpc64 FreeBSD.) I use a libc++ > based build --something gcc 4.2.1 will not do. >=20 > For self hosting on powerpc64 I use lang/gcc49 as the so-called = "system > compiler" and devel/powerpc64-gcc as the "cross" compiler for = buildworld > buildkernel . >=20 > So my src.conf sort of content and related context is probably not = like > yours (showing for self-hosted below). I list several files with = details > of my buildworld buildkernel environment. >=20 > (There are long lines likely implicitly wrapped in the below --in > addition to \ end-of-line notation.) >=20 > # more = ~/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_clang_x= toolchain-powerpc64-host.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-powerpc64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-= host" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64"= \ > make $* >=20 >=20 > # more ~/src.configs/make.conf=20 > CFLAGS.gcc+=3D -v >=20 >=20 > # more ~/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > FROM_TYPE=3D${TO_TYPE} > TOOLS_FROM_TYPE=3D${FROM_TYPE} > VERSION_CONTEXT=3D12.0 > # > KERNCONF=3DGENERIC64vtsc-NODBG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried > # but the LIB32 does not work [crtbeginS code problem(s)] > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # For FROM (host) stages . . . > # =46rom gccXY (such as gcc49 but not xtoolchain) > # TOOLS_FROM_TYPE's appropriate binutils. . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 -L/usr/lib > CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11= -nostdinc++ -L/usr/lib > CPP=3D/usr/local/bin/cpp49 > .export CC > .export CXX > .export CPP > = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s > = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r > = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d > = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m > = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy > = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump > = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib > = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size > #NO-SUCH: = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings > STRINGS=3D/usr/local/bin/strings > .export AS > .export AR > .export LD > .export NM > .export OBJCOPY > .export OBJDUMP > .export RANLIB > .export SIZE > .export STRINGS > .endif >=20 > # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 > # > # GENERIC -- Custom configuration for the powerpc/powerpc64 > # >=20 > include "GENERIC64" >=20 > ident GENERIC64vtsc-NODGB >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > options GDB # HACK!!! ... >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting > device sc > #device kbdmux # HACK: already listed by vt > options SC_OFWFB # OFW frame buffer > options SC_DFLT_FONT # compile font in > makeoptions SC_DFLT_FONT=3Dcp437 >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones >=20 >=20 > # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c=20 > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /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" > + : "=3D&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" >=20 >=20 >=20 >=20 > You have not sent out such materials for anyone to look at > so I've no clue what all the differences might be in what > you have. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net As for building powerpc64-gcc on a powerpc64 environment (self hosting): I use portmaster and its -DK options to leave the material in place: portmaster -DK devel/powerpc64-xtoolchain-gcc I let it run until it fails. Then I fix up 6 files it mishandles for self-hosting (the below show my personal file path prefix choice: /usr/obj/portswork/ for where ports are built --adjust as necessary): (the lines below are very long and will likely wrap) # more powerpc64-gcc_fixup.sh #!/bin/sh cp -ax = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= powerpc64-portbld-freebsd12.0-gcov cp -ax = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov-tool= = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= powerpc64-portbld-freebsd12.0-gcov-tool gzip -c = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/cpp.1 = > = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/powerpc64-portbld-freebsd12.0-cpp.1.gz gzip -c = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/g++.1= > = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/powerpc64-portbld-freebsd12.0-g++.1.gz gzip -c = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/gcc.1= > = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/powerpc64-portbld-freebsd12.0-gcc.1.gz gzip -c = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/gcov.1= > = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/powerpc64-portbld-freebsd12.0-gcov.1.gz I then use -C as well in portmaster to have it continue without first cleaning up the prior material: portmaster -CDK devel/powerpc64-xtoolchain-gcc =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Wed Nov 16 22:40:55 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 760FEC458F3 for ; Wed, 16 Nov 2016 22:40:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3457390D for ; Wed, 16 Nov 2016 22:40:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23438 invoked from network); 16 Nov 2016 22:40:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Nov 2016 22:40:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Wed, 16 Nov 2016 17:40:58 -0500 (EST) Received: (qmail 6154 invoked from network); 16 Nov 2016 22:40:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Nov 2016 22:40:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 40C96EC76EB; Wed, 16 Nov 2016 14:40:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r302214 - head/sys/powerpc/aim ["set usefdt=1" test fails on PowerMac7,2 as well] From: Mark Millard In-Reply-To: Date: Wed, 16 Nov 2016 14:40:51 -0800 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <307CB919-E9AC-4DD6-B695-DF47CE3F6CF9@dsl-only.net> References: To: Nathan Whitehorn X-Mailer: Apple Mail (2.3251) 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: Wed, 16 Nov 2016 22:40:55 -0000 [Top post of a new "set usefdt=3D1" test on a different type of = PowerMac.] I now have the SSD at -r308247 of head and have also tried "set = usefdt=3D1" at the loader prompt on a PowerMac7,2 (before it was a PowerMac11,3 that = was tested). > Ok set usefdt=3D1 > Ok boot still failed. (My SPRG0 PowerMac G5 boot-reliability hack is present in = what I tested.) It got another "Error -2 adding node" but was adding a CPU node = (PPC970). It hung just after the "kernel entry at 0x100120" message (earlier than the prior report relative to the message outputs shown). All I have access to for powerpc64 are a couple of PowerMac11,3's and = the one PowerMac7,2 so those are all that I can test. [The PowerMac11,3 test likely was using sc but this PowerMac7,2 was = using vt --in case that might matter for something.] If it is likely to make a difference I could try without the SPRG0 hack. = But so far you have not reported that "set usefdt=3D1" would be likely to = depend on such details. Otherwise as far as I know there is no more that I have context to help = with for this type of attempt to avoid depending on Apple's OpenFirmware in = the kernel. So far the SPRG0 hack has been the most useful technique for = booting reliably on PowerMac G5's. (And I've not been able to reproduce Jukka = U.'s iicsmb_load=3D"YES" in /boot/loader.conf problems so the run-time module loading issue is likely a distinct issue.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Oct-18, at 5:30 PM, Mark Millard wrote: [I've finally got a access to the powerpc's and powerpc64's, at least = for a little bit. But other things may take much of my time.] Nathan Whitehorn nwhitehorn at freebsd.org wrote on Sun Jun 26 23:38:36 = UTC 2016 [back in 11-CURRENT days]: >> . . . >>> Author: nwhitehorn >>> Date: Sun Jun 26 18:43:42 2016 >>> New Revision: 302214 >>> URL: >>> https://svnweb.freebsd.org/changeset/base/302214 >>>=20 >>>=20 >>> Log: >>> Enter 64-bit mode as early as possible in the 64-bit PowerPC boot = sequence. >>> Most of the effect of setting MSR[SF] is that the CPU will stop = ignoring >>> the high 32 bits of registers containing addresses in load/store >>> instructions. As such, the kernel was setting it only when it began = to >>> need access to high memory. MSR[SF] also affects the operation of = some >>> conditional instructions, however, and so setting it at late times = could >>> subtly break code at very early times. This fixes use of the FDT = mode in >>> loader, and FDT boot more generally, on 64-bit PowerPC systems. >>>=20 >>> Hardware provided by: IBM LTC >>> Approved by: re (kib) >>>=20 >>> Modified: >>> head/sys/powerpc/aim/aim_machdep.c >>> head/sys/powerpc/aim/locore64.S >> . . . >=20 > . . . >=20 > One thing it would be great to have some testing on after this change = is=20 > the FDT layer in loader. If you set usefdt=3D1 from the loader prompt,=20= > loader will distill the OF device tree into an FDT and then stop Open=20= > Firmware completely before transferring control to FreeBSD. This = should=20 > avoid any possible problems accessing Open Firmware from the kernel, = as=20 > well as making boot a little faster. > -Nathan I updated the old 2016-June-1 SSD contents to head's -r302214 and did buildworld and buildkernel and installed them, but with my PowerMac G5 boot-hack still present. This was to be the first test if things went well for "set usefdst=3D1". They did not so no tests without the hack = were made. A normal boot works fine for -r203214 but use of "set usefdt=3D1" before "boot" fails. A hand transcribed report of the visible "set usefdt=3D1" results are: > Ok set usefdt=3D1 > Ok boot > Booting... > Error -2 adding node /ht@0,f2000000/pci@8/macio@7/i2c@18000/i2c-bus@0 = (i2c-bus@0), skipping >=20 > kernel entry at 0x100120 > Invalid memory access at %SRR0: 00000000.00100120 %SRR1: = 10000000.00083030 It then reports the Apple model and firmware version and and some other Apple text and gets stuck. (Power switch time.) Note: I've not updated /usr/ports so the modern binutils poewrpc64 issue is not involved: > #svnlite info /usr/ports/ | grep "Re[lv]" > Relative URL: ^/head > Revision: 415874 > Last Changed Rev: 415874 > # uname -apKU > FreeBSD FBSDG5C0 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #40 r302214M: Tue Oct = 18 06:11:02 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100120 1100120 devel/powrepc64-gcc was used to do the system builds and it is a libc++ based build. > # svnlite info /usr/src/ | grep "Re[lv]" > Relative URL: ^/head > Revision: 302214 > Last Changed Rev: 302214 > # svnlite status /usr/src > ? /usr/src/.snap > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/restoresymtable > ? /usr/src/sys/arm/conf/RPI2-NODBG > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Wed Nov 16 23:47:58 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 F4048C456FB for ; Wed, 16 Nov 2016 23:47:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9DD7C86 for ; Wed, 16 Nov 2016 23:47:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4674 invoked from network); 16 Nov 2016 23:47:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Nov 2016 23:47:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Wed, 16 Nov 2016 18:47:41 -0500 (EST) Received: (qmail 30765 invoked from network); 16 Nov 2016 23:47:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Nov 2016 23:47:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E7FCDEC7F2C; Wed, 16 Nov 2016 15:47:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r302214 - head/sys/powerpc/aim ["set usefdt=1" gets farther if I unload first; result more interesting] From: Mark Millard In-Reply-To: <307CB919-E9AC-4DD6-B695-DF47CE3F6CF9@dsl-only.net> Date: Wed, 16 Nov 2016 15:47:54 -0800 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <62056AA2-E9EA-4070-9603-523E231BFEB7@dsl-only.net> References: <307CB919-E9AC-4DD6-B695-DF47CE3F6CF9@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3251) 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: Wed, 16 Nov 2016 23:47:58 -0000 [I pondered some more and came up with another test with different results: gets farther before crashing.] On 2016-Nov-16, at 2:40 PM, Mark Millard wrote: > [Top post of a new "set usefdt=3D1" test on a different type of = PowerMac.] >=20 > I now have the SSD at -r308247 of head and have also tried "set = usefdt=3D1" at > the loader prompt on a PowerMac7,2 (before it was a PowerMac11,3 that = was > tested). >=20 >> Ok set usefdt=3D1 >> Ok boot >=20 > still failed. (My SPRG0 PowerMac G5 boot-reliability hack is present = in what > I tested.) >=20 > It got another "Error -2 adding node" but was adding a CPU node = (PPC970). > It hung just after the "kernel entry at 0x100120" message (earlier = than > the prior report relative to the message outputs shown). >=20 > All I have access to for powerpc64 are a couple of PowerMac11,3's and = the > one PowerMac7,2 so those are all that I can test. >=20 > [The PowerMac11,3 test likely was using sc but this PowerMac7,2 was = using > vt --in case that might matter for something.] >=20 > If it is likely to make a difference I could try without the SPRG0 = hack. But > so far you have not reported that "set usefdt=3D1" would be likely to = depend > on such details. >=20 > Otherwise as far as I know there is no more that I have context to = help with > for this type of attempt to avoid depending on Apple's OpenFirmware in = the > kernel. So far the SPRG0 hack has been the most useful technique for = booting > reliably on PowerMac G5's. (And I've not been able to reproduce Jukka = U.'s > iicsmb_load=3D"YES" in /boot/loader.conf problems so the run-time = module > loading issue is likely a distinct issue.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net On the PowerMac11,3 I've now tried at the loader prompt: Ok unload Ok set usefdt=3D1 Ok boot (or autoboot). This does get farther in the boot sequence (from hand written notes): . . . cpu3: dev=3D0xc7f0 random: unblocking device random: entropy device external interface kdb0 at kdbmux0 fatal kernel trap exception =3D 0x700 (program) srr0 =3D 0x10c384 srr1 =3D 0x9000000000081032 curthread =3D 0x12177a0 pid =3D 0 comm =3D swapper [thread pid 0 tid 100000] stopped at .xpt_lock_buses: illegal instruction 0 db> Multiple tries stopped at this same point with the same text showing. It is not far enough along to take input to the db> prompt. But I could rebuild with an internal db script that executes before the db> prompt appears. objdump -d /boot/kernel/kernel shows: . . . 10c374: 4e 80 00 20 blr 10c378: 00 00 00 00 .long 0x0 10c37c: 00 00 00 01 .long 0x1 10c380: 80 05 00 00 lwz r0,0(r5) 000000000010c384 <.xpt_lock_buses>: 10c384: 7c 08 02 a6 mflr r0 10c388: f8 01 00 10 std r0,16(r1) 10c38c: fb e1 ff f8 std r31,-8(r1) 10c390: f8 21 ff 81 stdu r1,-128(r1) 10c394: 7c 3f 0b 78 mr r31,r1 10c398: 7d a4 6b 78 mr r4,r13 10c39c: 60 00 00 00 nop 10c3a0: e9 22 83 58 ld r9,-31912(r2) 10c3a4: 2b a9 00 04 cmpldi cr7,r9,4 10c3a8: 40 9e 00 44 bne cr7,10c3ec = <.xpt_lock_buses+0x68> . . . That does not match 0 as the encoding at 0x10c384, suggesting that the code has not been correctly loaded and made available to the processor. Older notes. . . On 2016-Oct-18, at 5:30 PM, Mark Millard wrote: > [I've finally got a access to the powerpc's and powerpc64's, at least = for a little bit. But other things may take much of my time.] >=20 > Nathan Whitehorn nwhitehorn at freebsd.org wrote on Sun Jun 26 = 23:38:36 UTC 2016 [back in 11-CURRENT days]: >=20 >>> . . . >>>> Author: nwhitehorn >>>> Date: Sun Jun 26 18:43:42 2016 >>>> New Revision: 302214 >>>> URL: >>>> https://svnweb.freebsd.org/changeset/base/302214 >>>>=20 >>>>=20 >>>> Log: >>>> Enter 64-bit mode as early as possible in the 64-bit PowerPC boot = sequence. >>>> Most of the effect of setting MSR[SF] is that the CPU will stop = ignoring >>>> the high 32 bits of registers containing addresses in load/store >>>> instructions. As such, the kernel was setting it only when it began = to >>>> need access to high memory. MSR[SF] also affects the operation of = some >>>> conditional instructions, however, and so setting it at late times = could >>>> subtly break code at very early times. This fixes use of the FDT = mode in >>>> loader, and FDT boot more generally, on 64-bit PowerPC systems. >>>>=20 >>>> Hardware provided by: IBM LTC >>>> Approved by: re (kib) >>>>=20 >>>> Modified: >>>> head/sys/powerpc/aim/aim_machdep.c >>>> head/sys/powerpc/aim/locore64.S >>> . . . >>=20 >> . . . >>=20 >> One thing it would be great to have some testing on after this change = is=20 >> the FDT layer in loader. If you set usefdt=3D1 from the loader = prompt,=20 >> loader will distill the OF device tree into an FDT and then stop Open=20= >> Firmware completely before transferring control to FreeBSD. This = should=20 >> avoid any possible problems accessing Open Firmware from the kernel, = as=20 >> well as making boot a little faster. >> -Nathan >=20 > I updated the old 2016-June-1 SSD contents to head's -r302214 and did > buildworld and buildkernel and installed them, but with my PowerMac G5 > boot-hack still present. This was to be the first test if things went > well for "set usefdst=3D1". They did not so no tests without the hack = were > made. >=20 > A normal boot works fine for -r203214 but use of "set usefdt=3D1" = before > "boot" fails. >=20 > A hand transcribed report of the visible "set usefdt=3D1" results are: >=20 >> Ok set usefdt=3D1 >> Ok boot >> Booting... >> Error -2 adding node /ht@0,f2000000/pci@8/macio@7/i2c@18000/i2c-bus@0 = (i2c-bus@0), skipping >>=20 >> kernel entry at 0x100120 >> Invalid memory access at %SRR0: 00000000.00100120 %SRR1: = 10000000.00083030 >=20 > It then reports the Apple model and firmware version and and some = other > Apple text and gets stuck. (Power switch time.) >=20 >=20 > Note: I've not updated /usr/ports so the modern binutils poewrpc64 = issue > is not involved: >=20 >> #svnlite info /usr/ports/ | grep "Re[lv]" >> Relative URL: ^/head >> Revision: 415874 >> Last Changed Rev: 415874 >=20 >> # uname -apKU >> FreeBSD FBSDG5C0 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #40 r302214M: Tue = Oct 18 06:11:02 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100120 1100120 >=20 > devel/powrepc64-gcc was used to do the system builds and it is a = libc++ > based build. >=20 >> # svnlite info /usr/src/ | grep "Re[lv]" >> Relative URL: ^/head >> Revision: 302214 >> Last Changed Rev: 302214 >=20 >> # svnlite status /usr/src >> ? /usr/src/.snap >> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >> M /usr/src/lib/csu/powerpc64/Makefile >> ? /usr/src/restoresymtable >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> M /usr/src/sys/conf/Makefile.powerpc >> M /usr/src/sys/conf/kern.mk >> M /usr/src/sys/conf/kmod.mk >> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Nov 17 07:59:31 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 E3F2FC4605D for ; Thu, 17 Nov 2016 07:59:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-33.reflexion.net [208.70.210.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 950811CF9 for ; Thu, 17 Nov 2016 07:59:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29412 invoked from network); 17 Nov 2016 07:59:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Nov 2016 07:59:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Thu, 17 Nov 2016 02:59:09 -0500 (EST) Received: (qmail 32757 invoked from network); 17 Nov 2016 07:59:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Nov 2016 07:59:09 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6935AEC7B11; Wed, 16 Nov 2016 23:59:23 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: head -r308247 (12-CURRENT) PowerMac G5 powerpc64: ddb's dump gets "panic: vm_fault: fault on nofault entry, addr: c000000000022000" Message-Id: <49B30113-21D7-458C-BC8A-C5B32A02849D@dsl-only.net> Date: Wed, 16 Nov 2016 23:59:22 -0800 To: FreeBSD PowerPC ML , FreeBSD Current X-Mailer: Apple Mail (2.3251) 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: Thu, 17 Nov 2016 07:59:32 -0000 [A version of the below has been submitted to bugzilla as 214598. The = specific powerpc64 context is a PowerMac11,3 PowerMac G5 "Quad Core" = --actually 2 sockets with each having 2 cores.] The failure was: "panic: vm_fault: fault on nofault entry, addr: = c000000000022000" Details. . . I manually entered ddb and gave it the dump command. 2 of 3 chunks = worked. This is new since last I tried (long ago): it used to be it = complained about the DMA request size being too large. (I've not tried = in a long time, under some 10. .) So this got a lot farther than I've = ever seen before for this type of context. Transcribed from a camera picture of the screen. . . (Typos?) (Also: I will drop off various leading zeros and some formatting will be = different.) KDB: enter: manual escape to debugger [ thread pid 12 tid 10018 ] Stopped at .kdb_enter+0x70: ori r0, r0, 0x0 db> dump Dumping 9 MB (3 chunks) chunk 0: 10MB (2510 pages) ... ok chunk 1: 1MB (24 pages) ... ok chunk 2: 1MB (2 pages)panic: vm_fault: fault on nofault entry, addr: = c000000000022000 cpuid =3D 1 KDB: stack backtrace: 0xf93cd0: at .kdb_backtrace+0x6c 0xf93df0: at .vpanic+0x178 0xf93eb0: at .panic+0x34 0xf93f30: at .vm_fault_hold+0x1ac 0xf94120: at .vm_fault+0x98 0xf941c0: at .trap_pfault+0xe8 0xf94240: at .trap+0x1e44 0xf944b0: at .powerpc_interrupt+0x1e0 0xf94550: kernel DSI read trap 0 0xc000000000022ff8 by .memcpy+0x144: ssr1=3D0x9000000000001032 r1 =3D 0xf94800 cr =3D0x40000424 xer =3D0x20000000 ctr =3D 0x200 r2 =3D 0x10de000 sr =3D0x40000000 0xf94800: at .moea64_kextract+0x124 0xf94840: at tmpstk+0x297c 0xf948c0: at ._bus_dmamap_sync+0x124 0xf94960: at .ata_dmaload+0x1e8 0xf94a00: at .ata_begin_transaction+0x240 0xf94aa0: at .ataaction+0x4e0 0xf94b50: at .xpt_run_devq+0x934 0xf94c40: at .xpt_action_default+0x3a8 0xf94cf0: at .ata_action+0x3c8 0xf94d80: at .xpt_actino+0x44 0xf94e00: at .xpt_polled_action+0x60c 0xf94ec0: at .adadump+0x33c 0xf954e0: at .dump_write+0x88 0xf954e0: at .dump_sys_cb_dumpdata+0x124 0xf955c0: at .dumpsys_foreach_chunk+0x68 0xf95660: at .dumpsys_generic+0x26c 0xf95770: at .doadump+0xbc 0xf95800: at .db_dump+0x44 0xf95880: at .db_command+0x3f4 (I omit the rest going back to "0xc0000000b6b4f920: at = blocked_loop+0x38".) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Nov 17 09:12:22 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 B3A0FC44EE8 for ; Thu, 17 Nov 2016 09:12:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2BCE690 for ; Thu, 17 Nov 2016 09:12:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAH9CMCo068353 for ; Thu, 17 Nov 2016 09:12:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 214598] head -r308247: dump from ddb unsuccessful on a powerpc64 PowerMac G5f. . . Date: Thu, 17 Nov 2016 09:12:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 17 Nov 2016 09:12:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214598 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-ppc@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Thu Nov 17 09:18:01 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 BA97CC455CD for ; Thu, 17 Nov 2016 09:18:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7B3ABC0 for ; Thu, 17 Nov 2016 09:18:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAH9I1QF028663 for ; Thu, 17 Nov 2016 09:18:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 214598] head -r308247: dump from ddb unsuccessful on a powerpc64 PowerMac G5. . . Date: Thu, 17 Nov 2016 09:18:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 17 Nov 2016 09:18:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214598 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|head -r308247: dump from |head -r308247: dump from |ddb unsuccessful on a |ddb unsuccessful on a |powerpc64 PowerMac G5f. . . |powerpc64 PowerMac G5. . . --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Nov 18 07:17:47 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 55803C47E4D for ; Fri, 18 Nov 2016 07:17:47 +0000 (UTC) (envelope-from tehnosistem@ptt.rs) Received: from mtaout2.isp.ptt.rs (mtaout2.isp.ptt.rs [212.62.57.37]) by mx1.freebsd.org (Postfix) with ESMTP id 15450F02 for ; Fri, 18 Nov 2016 07:17:46 +0000 (UTC) (envelope-from tehnosistem@ptt.rs) MIME-version: 1.0 Received: from ptt.rs ([212.62.57.119]) by mtaout2.isp.ptt.rs (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0OGT000C4QKOSY70@mtaout2.isp.ptt.rs> for freebsd-ppc@freebsd.org; Fri, 18 Nov 2016 07:12:24 +0100 (CET) Received: from [212.62.57.55] by msfe4.isp.ptt.rs (mshttpd); Fri, 18 Nov 2016 07:17:37 +0100 From: tehnosistem To: freebsd-ppc@freebsd.org Message-id: Date: Fri, 18 Nov 2016 07:17:37 +0100 X-Mailer: Sun Java(tm) System Messenger Express 6.3-4.01 (built Aug 3 2007; 32bit) Content-language: sr Subject: Re: 21759 tehnosistem X-Accept-Language: sr Priority: normal In-reply-to: <147941512155.31196.11519057466359173952@144.12.76.28> References: <147941512155.31196.11519057466359173952@144.12.76.28> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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, 18 Nov 2016 07:17:47 -0000 Molim Vas ponovite mejl koji ste nam poslali=2E Pozdav! ----- Originalna poruka ----- Po=A8iljalac=3A freebsd-ppc=40freebsd=2Eorg Datum=3A Cetvrtak=2C Novembar 17=2C 2016 21=3A39 Tema=3A 21759 tehnosistem Primalac=3A tehnosistem=40ptt=2Ers From owner-freebsd-ppc@freebsd.org Fri Nov 18 19:59:06 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 7B4A2C48875 for ; Fri, 18 Nov 2016 19:59:06 +0000 (UTC) (envelope-from jimukyoku@kpa.ees.kyushu-u.ac.jp) Received: from eesserv2.ees.kyushu-u.ac.jp (ckt.ees.kyushu-u.ac.jp [133.5.152.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C270515C9 for ; Fri, 18 Nov 2016 19:59:05 +0000 (UTC) (envelope-from jimukyoku@kpa.ees.kyushu-u.ac.jp) Received: from [216.45.54.23] (216.45.54.23.static.greencloudvps.com [216.45.54.23] (may be forged)) (authenticated bits=0) by eesserv2.ees.kyushu-u.ac.jp (8.14.4/8.14.4) with ESMTP id uAIJWGQD012443 for ; Sat, 19 Nov 2016 04:59:04 +0900 Message-Id: <201611181959.uAIJWGQD012443@eesserv2.ees.kyushu-u.ac.jp> MIME-Version: 1.0 Subject: Google Award Notification To: freebsd-ppc@freebsd.org From: "Google Inc." Date: Fri, 18 Nov 2016 11:59:07 -0800 Reply-To: mikhaylovichbrinsergey@gmail.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body 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, 18 Nov 2016 19:59:06 -0000 Dear Google User, Congratulation for being selected as a winner, find attached email with fur= ther information. Sergey M. Brin, Co-Founder/Foreign Bureau Administrator.