From owner-freebsd-ppc@freebsd.org Sun Sep 11 00:13:02 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 63458BD68DD for ; Sun, 11 Sep 2016 00:13:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 27FADF03 for ; Sun, 11 Sep 2016 00:13:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8369 invoked from network); 11 Sep 2016 00:13:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Sep 2016 00:13:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 10 Sep 2016 20:12:46 -0400 (EDT) Received: (qmail 14795 invoked from network); 11 Sep 2016 00:12:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2016 00:12:46 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id A0FC6EC8B81; Sat, 10 Sep 2016 17:12:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx From: Mark Millard In-Reply-To: Date: Sat, 10 Sep 2016 17:12:52 -0700 Cc: Jukka Ukkonen , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> To: Krzysztof Parzyszek X-Mailer: Apple Mail (2.3124) 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: Sun, 11 Sep 2016 00:13:02 -0000 On 2016-Sep-10, at 1:41 PM, Krzysztof Parzyszek wrote: >=20 > On 9/9/2016 3:21 PM, Mark Millard wrote: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 (from = 2015-Dec-20) >>=20 >> It reports as the technique: >>=20 >>> The change is in ofw_sprg_prepare of sys/powerpc/ofw/ofw_machdep.c = and could look something like (presented in a form to show = new/PowerMacG5-Specific code and old general code): >>>=20 >>> #ifdef POWERMAC_G5_SPECIFIC_BUILD >>> __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 >>> // The historical code: >>> __asm __volatile("mfsprg0 %0\n\t" >>> "mtsprg0 %1\n\t" >>> "mtsprg1 %2\n\t" >>> "mtsprg2 %3\n\t" >>> "mtsprg3 %4\n\t" >>> : "=3D&r"(ofw_sprg0_save) >>> : "r"(ofmsr[1]), >>> "r"(ofmsr[2]), >>> "r"(ofmsr[3]), >>> "r"(ofmsr[4])); >>> #endif >>>=20 >>> In other words: for PowerMac G5's omit the mtsprg0 from ofmsr[1]: = leave the register as it already is instead of resetting it. The value = in ofmsr[1] is inappropriate to the context. I deliberately kept the = change minimal and left in all other code related to the register. >>=20 >=20 > Hi Mark, >=20 > I reinstalled 10.3, and it boots *sometimes*. I cannot try this = change though, because it hangs well before the kernel finishes = building. >=20 > The custom kernel I had before was quite stable, once it booted, but = at the moment I cannot get any kernel to build. >=20 > -Krzysztof An interesting question might be: Does the TARGET_ARCH=3Dpowerpc build = still work well on the PowerMac G5? Historically it has (but can not use = the extra memory if present). I usually do most of my = TARGET_ARCH=3Dpowerpc use on a PowerMac G5. But I also use G4's. It has = been some time since the iMac G3 example worked, however. (The only G3 = context I ever had access to.) FreeBSD stable/10 stopped booting the G3 = example long before before I ever had tried 11.0-CURRENT if I remember = right. I've only had 2 boot problem contexts for my normal powerpc64 and = powerpc use: A) TARGET_ARCH=3Dpowerpc64 on PowerMac G5's (until my hack made my = booting reliable) B) TARGET_ARCH=3Dpowerpc on the iMac G3 example Once booted I've not had problems on G5's. The G3 has only booted with = older 10.x versions and back then booted and operated reliably for my = use. (I can not identify when for the G3 change-of-status at this point. = As I remember I sent some notes to the list at the time I discovered the = problem.) But my context for powerpc64 and powerpc activity stopped in early = 2016-Jun and likely will not restart until 2016-Oct sometime: I = temporarily lost access to the powerpc64's and powerpc's. Your report that you have some sort of failure after booting during the = likes of buildkernel is new as far as I know. Sending the list (and/or a = bugzilla report) about the failure mode and related information may be = appropriate and help in the future. (May be I missed an already existing = report.) Just so you know more about the context I've been using since it is odd. = . . I had been using powerpc64 stable/10 for a long time before switching = primarily to 11.0-CURRENT's head. In essence I've never tried anything = before 10.0. If I remember right I still have a stable/10 boot media = that I'd update on occasion (until I temporarily lost powerpc64 and = powerpc access). As I remember this booted and operated fine on the = PowerMac G5's last I updated --but it might have been fairly old, even = as of early 2016-Jun . (It has my kernel hack for the boot issue.) But my stable/10 context was a xtoolchain style build via = devel/powerpc64-gcc, using libc++, no gcc 4.2.1 present. I did this via = what is in essence a "self hosted xtoolchain style build", using = devel/powerpc64-gcc on the powerpc64. (There were some workarounds = involved in getting this to work --even for getting devel/powerpc64-gcc = installed.) My 11.0-??? powerpc64 activity also was this sort of build. = I have the builds include building the system clang most of the time = --but clang is not used for powerpc64 buildworld or buildkernel. (My transition from gcc 4.2.1 to xtoolchain for powerpc64 was a very = long time ago. I do not remember much about how I got it done. I was not = as familiar with various things back then either. More luck was = involved.) [Note: I've never gotten lib32 to work via builds by = devel/powerpc64-gcc.] Back when projects/clang380 was active I switched to it from = 11.0-CURRENT's head for my primary activity. When projects/clang380 merged back into head I switched as well. I kept = with 11.0-CURRENT's head until I temporarily lost powerpc64 and powerpc = access. For powerpc64 and powerpc I will at some point switch to where = clang 3.9.0 has some of its powerpc64 and powerpc problems fixed. (In my non-powerpc FreeBSD contexts I'm currently tracking stable/11 via = updating once and a while.) The history is even messier but my more modern 11.0-??? = TARGET_ARCH=3Dpowerpc builds (non-64) have for some time been a kernel = built with gcc 4.2.1 and a world built with clang 3.8.0. There are = kernel hacks to do this sufficiently for buildworld to operate on the = result ("red-zone" for signals). I tended to cross build these and send = the updates to the PowerMac in use and then locally update from that = material. But not always. [Note: clang++ 3.8.0 greatly messes up its code generation for exception = handling for both powerpc64 and powerpc. This limits what range of = things work well in each of those contexts when clang++ 3.8.0 was used = to compile things.] [I use svn for /usr/src and /usr/ports.] So for a long time my activity has been primarily 11.0-??? based. I do = not remember just what my 10.x context was back in early June when my = access to the powerpc64s and powerpcs stopped temporarily. But it was = stable/10 at some revision. For my 11.0-CURRENT variants: They were = updated only a few days before losing access to the machines = temporarily, so late 2016-May or early 2016-Jun sometime. =46rom what I've read in folks reports since early 2016-Jun it looks = like I'll need to progress carefully on the powerpc64 and powerpc = variants when I get access again, both for stable/10 and stable/11 --and = eventually for head (12.0-CURRENT). I'll probably get more boot media so = I can setup to revert trivially to known-good (kernel and world). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Sep 11 01:23:27 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 0A50CBCF805 for ; Sun, 11 Sep 2016 01:23:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (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 B07F67C1 for ; Sun, 11 Sep 2016 01:23:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8751 invoked from network); 11 Sep 2016 01:23:25 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2016 01:23:25 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 10 Sep 2016 21:23:29 -0400 (EDT) Received: (qmail 31078 invoked from network); 11 Sep 2016 01:23:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2016 01:23:29 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id C5A94EC8B81; Sat, 10 Sep 2016 18:23:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: From llvm: Fwd: [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) [fixed in llvm -r280705] From: Mark Millard In-Reply-To: <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> Date: Sat, 10 Sep 2016 18:23:23 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <08136189-299F-4BD6-9E49-8D39A8913D62@dsl-only.net> <0E2783E3-277F-47F1-B696-46FCFF0DB0F1@dsl-only.net> <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> To: Dimitry Andric , Krzysztof Parzyszek X-Mailer: Apple Mail (2.3124) 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: Sun, 11 Sep 2016 01:23:27 -0000 On 2016-Sep-10, at 10:18 AM, Dimitry Andric wrote: > On 06 Sep 2016, at 15:04, Mark Millard wrote: >>=20 >> llvm's bugzilla reports that the stack-handling SVR4 ABI violation = for TARGET_ARCH=3Dpowerpc has been fixed r280705 (likely on trunk)! >=20 > I merged the upstream fix to projects/clang390-import: >=20 > https://svnweb.freebsd.org/changeset/base/305686 >=20 > -Dimitry Looking at things for this again I've submitted a question to = https://llvm.org/bugs/show_bug.cgi?id=3D26519 asking if the post-amble = code's side if things was also adjusted (instead of just the = pre-amble/"claim" code side of things). [I'm not clang/llvm literate so I may have missed interpreted something = when I looked.] My original submittal also noted the stack pointer adjustment-timing = problem existed on the post-amble side in 3.8.0's code generation (when = removing the frame from the stack): > 0x1801b8c : lwz r30,24(r31) > 0x1801b90 : lwz r29,20(r31) > 0x1801b94 : lwz r28,16(r31) > 0x1801b98 : lwz r27,12(r31) > 0x1801b9c : lwz r26,8(r31) > 0x1801ba0 : addi r1,r1,32 # Stack pointer = adjusted first > 0x1801ba4 : lwz r0,4(r1) > 0x1801ba8 : lwz r31,-4(r1) # Then Frame Pointer = load happens > # "outside" the new = stack range. > 0x1801bac : mtlr r0 > 0x1801bb0 : blr If such code can still be generated there would still be a time frame = needing a red-zone to protect stack the contents from signals. Hopefully I'm just wrong and this was fixed too. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Sep 11 01:56:35 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 A2435BD27AB for ; Sun, 11 Sep 2016 01:56:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-186.reflexion.net [208.70.211.186]) (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 4EA0DA0E for ; Sun, 11 Sep 2016 01:56:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25781 invoked from network); 11 Sep 2016 01:57:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Sep 2016 01:57:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 10 Sep 2016 21:56:24 -0400 (EDT) Received: (qmail 22751 invoked from network); 11 Sep 2016 01:56:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2016 01:56:24 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B49AEC8B81; Sat, 10 Sep 2016 18:56:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: From llvm: Fwd: [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) [fixed in llvm -r280705] From: Mark Millard In-Reply-To: Date: Sat, 10 Sep 2016 18:56:31 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> References: <08136189-299F-4BD6-9E49-8D39A8913D62@dsl-only.net> <0E2783E3-277F-47F1-B696-46FCFF0DB0F1@dsl-only.net> <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3124) 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: Sun, 11 Sep 2016 01:56:35 -0000 Quick top post: Krzysztof has re-opened llvm bugzilla 26519 because the = post-amble side of things has not been fixed yet. . . Krzysztof Parzyszek changed bug 26519=20 What Removed Added Status RESOLVED REOPENED Resolution FIXED --- Comment # 9 on bug 26519 from Krzysztof Parzyszek The post-amble has not been fixed. You are receiving this mail because: =E2=80=A2 You reported the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Sep-10, at 6:23 PM, Mark Millard wrote: >=20 > On 2016-Sep-10, at 10:18 AM, Dimitry Andric = wrote: >=20 >> On 06 Sep 2016, at 15:04, Mark Millard = wrote: >>>=20 >>> llvm's bugzilla reports that the stack-handling SVR4 ABI violation = for TARGET_ARCH=3Dpowerpc has been fixed r280705 (likely on trunk)! >>=20 >> I merged the upstream fix to projects/clang390-import: >>=20 >> https://svnweb.freebsd.org/changeset/base/305686 >>=20 >> -Dimitry >=20 > Looking at things for this again I've submitted a question to = https://llvm.org/bugs/show_bug.cgi?id=3D26519 asking if the post-amble = code's side if things was also adjusted (instead of just the = pre-amble/"claim" code side of things). >=20 > [I'm not clang/llvm literate so I may have missed interpreted = something when I looked.] >=20 > My original submittal also noted the stack pointer adjustment-timing = problem existed on the post-amble side in 3.8.0's code generation (when = removing the frame from the stack): >=20 >> 0x1801b8c : lwz r30,24(r31) >> 0x1801b90 : lwz r29,20(r31) >> 0x1801b94 : lwz r28,16(r31) >> 0x1801b98 : lwz r27,12(r31) >> 0x1801b9c : lwz r26,8(r31) >> 0x1801ba0 : addi r1,r1,32 # Stack = pointer adjusted first >> 0x1801ba4 : lwz r0,4(r1) >> 0x1801ba8 : lwz r31,-4(r1) # Then Frame = Pointer load happens >> # "outside" the new = stack range. >> 0x1801bac : mtlr r0 >> 0x1801bb0 : blr >=20 > If such code can still be generated there would still be a time frame = needing a red-zone to protect stack the contents from signals. >=20 > Hopefully I'm just wrong and this was fixed too. >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-ppc@freebsd.org Sun Sep 11 19:04:16 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 96E17BD64C0 for ; Sun, 11 Sep 2016 19:04:16 +0000 (UTC) (envelope-from kristof@swissmail.org) Received: from smtp.swissmail.org (smtpout.swissmail.org [212.25.22.149]) (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 534F4F4 for ; Sun, 11 Sep 2016 19:04:15 +0000 (UTC) (envelope-from kristof@swissmail.org) Received: from vm-mailout2.vm.swissmail.org (vm-mailout2.vm.swissmail.org [212.25.22.135]) by smtp.swissmail.org (Postfix) with ESMTPS id 2CA0680770; Sun, 11 Sep 2016 20:58:56 +0200 (CEST) Received: from vm-pemfos1.intra.swissmail.org (unknown [192.168.173.54]) by vm-mailout2.vm.swissmail.org (Postfix) with ESMTP id 20B119FBA5; Sun, 11 Sep 2016 21:04:13 +0200 (CEST) Received: from vm-pemfos1.intra.swissmail.org (localhost [127.0.0.1]) by localhost (Postfix-local-10025) with ESMTP id 11D564A002; Sun, 11 Sep 2016 21:04:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (PEmFoS/1619.3522.a1); Sun, 11 Sep 2016 21:04:12 +0200 (CEST) X-Pemfos-Policyd: accepted (FjHJ9W38rJqEZzTTULtaJHE1QiNtO0s4kEwHJn8EICktGSYgBl02c0cNYBYKEj8P) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx To: Mark Millard References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> Cc: Jukka Ukkonen , freebsd-ppc@freebsd.org From: Krzysztof Parzyszek Message-ID: <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> Date: Sun, 11 Sep 2016 14:04:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at vm-mailout2 X-Virus-Status: Clean 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: Sun, 11 Sep 2016 19:04:16 -0000 On 9/10/2016 7:12 PM, Mark Millard wrote: > > Your report that you have some sort of failure after booting during the likes of buildkernel is new as far as I know. Sending the list (and/or a bugzilla report) about the failure mode and related information may be appropriate and help in the future. (May be I missed an already existing report.) I think the issues with hangs are related to the temperature sensors. I was getting console messages that the media temp sensor was reporting 120C! I realized that as I replaced the hard drive, I changed the position of the drive in a way that exposed the sensor to the wind from the fans (it used to be angled a bit). Following this line of thought, I stuck a piece of paper in front of the sensor and things seem to work. At least work better than before. I have ordered a replacement sensor from eBay, so hopefully that problem will go away. Regarding your "hack": it works perfectly! So far, my system (10.3 at the moment) has booted every single time, no exceptions, traps, unexpected conditions. This is too good to remain as a "hack". I have no experience debugging the kernel and I don't know ABI the OFW follows, but I wouldn't mind digging a bit deeper into it, if someone shared some pointers. This is all with powerpc64. I'll try checking if it helps with 11.0 next. -Krzysztof From owner-freebsd-ppc@freebsd.org Sun Sep 11 20:43:00 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 E70B4BD7E46 for ; Sun, 11 Sep 2016 20:43:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 A7684615 for ; Sun, 11 Sep 2016 20:42:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8975 invoked from network); 11 Sep 2016 20:43:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2016 20:43:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sun, 11 Sep 2016 16:42:57 -0400 (EDT) Received: (qmail 7619 invoked from network); 11 Sep 2016 20:42:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2016 20:42:57 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 71B59EC892A; Sun, 11 Sep 2016 13:42:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx From: Mark Millard In-Reply-To: <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> Date: Sun, 11 Sep 2016 13:42:51 -0700 Cc: Jukka Ukkonen , FreeBSD PowerPC ML , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <4ED78F93-6C3F-43AC-8BFB-95C54B5F50E2@dsl-only.net> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> To: Krzysztof Parzyszek X-Mailer: Apple Mail (2.3124) 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: Sun, 11 Sep 2016 20:43:01 -0000 On 2016-Sep-11, at 12:04 PM, Krzysztof Parzyszek = wrote: > On 9/10/2016 7:12 PM, Mark Millard wrote: >>=20 >> Your report that you have some sort of failure after booting during = the likes of buildkernel is new as far as I know. Sending the list = (and/or a bugzilla report) about the failure mode and related = information may be appropriate and help in the future. (May be I missed = an already existing report.) >=20 > I think the issues with hangs are related to the temperature sensors. = I was getting console messages that the media temp sensor was reporting = 120C! I realized that as I replaced the hard drive, I changed the = position of the drive in a way that exposed the sensor to the wind from = the fans (it used to be angled a bit). Following this line of thought, I = stuck a piece of paper in front of the sensor and things seem to work. = At least work better than before. I have ordered a replacement sensor = from eBay, so hopefully that problem will go away. >=20 > Regarding your "hack": it works perfectly! So far, my system (10.3 at = the moment) has booted every single time, no exceptions, traps, = unexpected conditions. This is too good to remain as a "hack". I have no = experience debugging the kernel and I don't know ABI the OFW follows, = but I wouldn't mind digging a bit deeper into it, if someone shared some = pointers. >=20 > This is all with powerpc64. >=20 > I'll try checking if it helps with 11.0 next. >=20 > -Krzysztof One of the worries about the hack is that other PowerMac G5 variants = than I and you have tested on might behave differently. After all your = experiments with my hack you might want to add notes about the results = to the bugzilla report = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 . It would be = good to be explicit about the type of PowerMac G5(s). Various folks = believe that the amount of RAM contributes to the issue based on their = observations so reporting that is likely important. I likely need to add notes about the two types of PowerMac G5 variants = and the RAM configurations that my activities involved. (The list = history has this information but it would be a pain to find.) Going in a different direction. . . If you are willing you might want to help Nathan Whitehorn with testing = that I'll not be able to do until I get access to the powerpc64's (and = powerpc's) again. See, for example, = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-June/008275.html : >> Author: nwhitehorn >> Date: Sun Jun 26 18:43:42 2016 >> New Revision: 302214 >> URL: >> https://svnweb.freebsd.org/changeset/base/302214 >> >> >> 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) >> >> Modified: >> head/sys/powerpc/aim/aim_machdep.c >> head/sys/powerpc/aim/locore64.S In addition he wrote in the specific message: > 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. (I had temporarily lost access to the powerpc64's (and powerpc's) = already.) I expect that he would like some testing without my hack present that = eliminates. . . > "mtsprg0 %1\n\t" > and > "r"(ofmsr[1]), If there are still problems then testing with my hack present would be a = good idea as well. This activity might produce more material appropriate to report at = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Sep 11 21:22:20 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 87180BD7A27 for ; Sun, 11 Sep 2016 21:22:20 +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 7600413F for ; Sun, 11 Sep 2016 21:22:20 +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 u8BLMKJU024095 for ; Sun, 11 Sep 2016 21:22:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Sun, 11 Sep 2016 21:22:20 +0000 X-Bugzilla-Reason: CC 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: patch 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-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Sun, 11 Sep 2016 21:22:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #1 from Mark Millard --- I should have noted the specifics of the types of PowerMac G5's that my activity with this hack has been in use on: 2 PowerMac7,11 examples, one with 16 GBytes RAM and one with 12 GBytes RAM, each with 2 dual-core processors ("Quad core G5" examples). 1 PowerMac7,2 with 8 GBytes RAM, 2 single-core processors. One of the worries about the hack is that other PowerMac/iMac G5 variants t= han I have tested on might behave differently. I've no evidence for any other type of PowerMac G5 variant. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Sep 12 19:22:37 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 C57C6BD8198 for ; Mon, 12 Sep 2016 19:22:37 +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 B443A69B for ; Mon, 12 Sep 2016 19:22:37 +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 u8CJMbXW054843 for ; Mon, 12 Sep 2016 19:22:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Mon, 12 Sep 2016 19:22:37 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@swissmail.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Mon, 12 Sep 2016 19:22:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 Krzysztof Parzyszek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kristof@swissmail.org --- Comment #2 from Krzysztof Parzyszek --- It works great with 10.3 on PowerMac11,2, quad core with 16GB of memory. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Sep 12 19:32:16 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 CC8DEBD8521 for ; Mon, 12 Sep 2016 19:32:16 +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 BB8B7CC0 for ; Mon, 12 Sep 2016 19:32:16 +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 u8CJWGcp074270 for ; Mon, 12 Sep 2016 19:32:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Mon, 12 Sep 2016 19:32:16 +0000 X-Bugzilla-Reason: CC 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: patch 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-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Mon, 12 Sep 2016 19:32:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #1) My PowerMac7,11 reference for the Quad Core (copied from an old note) must = be wrong: PowerMac11,2 would be right. [It is still weeks before I'll have access to directly look.] --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Sep 12 20:10: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 242D7BD8E60 for ; Mon, 12 Sep 2016 20:10:31 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08A53231 for ; Mon, 12 Sep 2016 20:10:30 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vz-proxy-m004.mx.aol.com ([64.236.83.8]) by vms173007.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0ODE008P4NWIXRA0@vms173007.mailsrvcs.net> for freebsd-ppc@freebsd.org; Mon, 12 Sep 2016 14:09:55 -0500 (CDT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=btqxfxui c=1 sm=1 tr=0 a=Bcm0RCOkHTZ4We9DUxtllQ==:117 a=GW1xBdLrtEIA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=IBH610gTdCVRMjYfO0cA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=0p3rzuodeASB4O7U1u4A:9 a=r9A_-6cMEizNLnGq:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 Received: by 108.56.157.92 with SMTP id 3ba5a320; Mon, 12 Sep 2016 19:09:55 GMT From: "Curtis Hamilton" To: Subject: Re: binutils 2.27 Date: Mon, 12 Sep 2016 15:09:50 -0400 Message-id: <011c01d20d29$3d33c970$b79b5c50$@verizon.net> MIME-version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-index: AdINJbfX6QDk8rckQKSPpqKY3cnflQ== Content-language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: Mon, 12 Sep 2016 20:10:31 -0000 I've experienced the same issues after upgrading to binutils 2.27. It looks like the problem is related to the use of the Binary File Descriptor (BFD) library. Check if you see several messages beginning with "BFD:". I downgraded back to binutils 2.25, which was previously installed, and everything works properly. I skipped binutils 2.26, but will give that a try. Regards, Curtis On 9/9/2016 4:32 PM, Bill Sorenson wrote: >Everything I've built with the new binutils using either GCC 4.9, 5.4 or >6.2 instantly dumps when run. This is on an Xserve G5. Is this just me or >is there something genuinely broken here? > >Thanks, >Bill From owner-freebsd-ppc@freebsd.org Mon Sep 12 21:01:20 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 1888CBD8E2E for ; Mon, 12 Sep 2016 21:01:20 +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 073DA6E9 for ; Mon, 12 Sep 2016 21:01:20 +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 u8CL1IfF024980 for ; Mon, 12 Sep 2016 21:01:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Mon, 12 Sep 2016 21:01:18 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nwhitehorn@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc 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: Mon, 12 Sep 2016 21:01:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 Nathan Whitehorn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |nwhitehorn@FreeBSD.org --- Comment #4 from Nathan Whitehorn --- I've finally understood why this patch does anything useful. Open Firmware = runs in virtual mode on the Powermac G5. This runs inside the kernel page table, which preserves all address translations made by OF before the kernel start= s; as a result, the kernel address space is a strict superset of OF's. Where this explodes is if OF uses an unmapped SLB entry. The SLB fault hand= ler runs in real mode and refers to the PCPU pointer in SPRG0, which blows up t= he kernel. Having a value of SPRG0 that works for the kernel is less fatal than preserving OF's value in this case. I believe that OF's SPRG0 is maintained only for compatibility with some G4 Apple hardware, the eMac in particular, but will check and we can move on w= ith this. I think it should be safe to wrap this in an #ifdef __powerpc64__. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Sep 12 21:11: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 AD210BD2139 for ; Mon, 12 Sep 2016 21:11:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 919CCD69 for ; Mon, 12 Sep 2016 21:11:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u8CL0i3g019153 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Sep 2016 14:00:44 -0700 Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx To: Krzysztof Parzyszek , Mark Millard References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> Cc: freebsd-ppc@freebsd.org From: Nathan Whitehorn Message-ID: <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> Date: Mon, 12 Sep 2016 14:00:45 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa//iWD1MyTUvEk48UW5FKGITESQ/EESOMZxwGiczgBdepWB11aH8L/xJlvVZpxTKXJ7IIa0NcqvhH8XYjoTanYTNkWnnlX7iE= X-Sonic-ID: C;9MZ9+Ct55hGM4a/hcgQksw== M;gCW7+Ct55hGM4a/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 12 Sep 2016 21:11:55 -0000 On 09/11/16 12:04, Krzysztof Parzyszek wrote: > On 9/10/2016 7:12 PM, Mark Millard wrote: >> >> Your report that you have some sort of failure after booting during >> the likes of buildkernel is new as far as I know. Sending the list >> (and/or a bugzilla report) about the failure mode and related >> information may be appropriate and help in the future. (May be I >> missed an already existing report.) > > I think the issues with hangs are related to the temperature sensors. > I was getting console messages that the media temp sensor was > reporting 120C! I realized that as I replaced the hard drive, I > changed the position of the drive in a way that exposed the sensor to > the wind from the fans (it used to be angled a bit). Following this > line of thought, I stuck a piece of paper in front of the sensor and > things seem to work. At least work better than before. I have ordered > a replacement sensor from eBay, so hopefully that problem will go away. > > Regarding your "hack": it works perfectly! So far, my system (10.3 at > the moment) has booted every single time, no exceptions, traps, > unexpected conditions. This is too good to remain as a "hack". I have > no experience debugging the kernel and I don't know ABI the OFW > follows, but I wouldn't mind digging a bit deeper into it, if someone > shared some pointers. I've finally understood why this helps. Open Firmware runs in virtual mode on the Powermac G5. This runs inside the kernel page table, which preserves all address translations made by OF before the kernel starts; as a result, the kernel address space is a strict superset of OF's. Where this explodes is if OF uses an unmapped SLB entry. The SLB fault handler runs in real mode and refers to the PCPU pointer in SPRG0, which blows up the kernel. Having a value of SPRG0 that works for the kernel is less fatal than preserving OF's value in this case. I believe that OF's SPRG0 is maintained only for compatibility with some G4 Apple hardware, the eMac in particular, but will check and we can move on with this. I think it should be safe to wrap this in an #ifdef __powerpc64__. -Nathan > > This is all with powerpc64. > > I'll try checking if it helps with 11.0 next. > > -Krzysztof > > _______________________________________________ > 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 Mon Sep 12 21:50:41 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 C15C6BD2D66 for ; Mon, 12 Sep 2016 21:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-186.reflexion.net [208.70.211.186]) (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 856FEEDE for ; Mon, 12 Sep 2016 21:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20514 invoked from network); 12 Sep 2016 21:50:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Sep 2016 21:50:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Mon, 12 Sep 2016 17:50:26 -0400 (EDT) Received: (qmail 10241 invoked from network); 12 Sep 2016 21:50:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Sep 2016 21:50:25 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 2AE71EC8073; Mon, 12 Sep 2016 14:50:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx From: Mark Millard In-Reply-To: <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> Date: Mon, 12 Sep 2016 14:50:32 -0700 Cc: Krzysztof Parzyszek , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EC34F05-EF27-404B-816E-9A104105D097@dsl-only.net> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) 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, 12 Sep 2016 21:50:41 -0000 On 2016-Sep-12, at 2:00 PM, Nathan Whitehorn = wrote: > On 09/11/16 12:04, Krzysztof Parzyszek wrote: >> On 9/10/2016 7:12 PM, Mark Millard wrote: >>>=20 >>> Your report that you have some sort of failure after booting during = the likes of buildkernel is new as far as I know. Sending the list = (and/or a bugzilla report) about the failure mode and related = information may be appropriate and help in the future. (May be I missed = an already existing report.) >>=20 >> I think the issues with hangs are related to the temperature sensors. = I was getting console messages that the media temp sensor was reporting = 120C! I realized that as I replaced the hard drive, I changed the = position of the drive in a way that exposed the sensor to the wind from = the fans (it used to be angled a bit). Following this line of thought, I = stuck a piece of paper in front of the sensor and things seem to work. = At least work better than before. I have ordered a replacement sensor = from eBay, so hopefully that problem will go away. >>=20 >> Regarding your "hack": it works perfectly! So far, my system (10.3 at = the moment) has booted every single time, no exceptions, traps, = unexpected conditions. This is too good to remain as a "hack". I have no = experience debugging the kernel and I don't know ABI the OFW follows, = but I wouldn't mind digging a bit deeper into it, if someone shared some = pointers. >=20 > I've finally understood why this helps. Open Firmware runs in virtual = mode on the Powermac G5. This runs inside the kernel page table, which = preserves all address translations made by OF before the kernel starts; = as a result, the kernel address space is a strict superset of OF's. >=20 > Where this explodes is if OF uses an unmapped SLB entry. The SLB fault = handler runs in real mode and refers to the PCPU pointer in SPRG0, which = blows up the kernel. Having a value of SPRG0 that works for the kernel = is less fatal than preserving OF's value in this case. Actual theory of operation material! Great! I've no clue how I would = have figured out the Apple Open Firmware side of the context so I'd = still be stuck with just observation of the overall change in behavior. Presuming that you are correct: no longer "just a hack". That is great = news. It does sound like the Open Firmware side gets some risk of picking up = the wrong address map with the change. So avoiding Open Firmware in the = kernel via the usefdt=3D1 sounds like it would still be appropriate. > I believe that OF's SPRG0 is maintained only for compatibility with = some G4 Apple hardware, the eMac in particular, but will check and we = can move on with this. I think it should be safe to wrap this in an = #ifdef __powerpc64__. > -Nathan Again I've no clue how I would figure such a thing out. But, if some = powerpc Macs are the only reason GENERIC preserves SPRG0 and preserving = works for the other powerpcs so that detecting PowerMac vs. not is not = really required to decide on the SPRG0 handling (at least for = powerpc64), that too is great news. Thanks for continuing to look into why the SPRG0 change might have a = solid justification! >>=20 >> This is all with powerpc64. >>=20 >> I'll try checking if it helps with 11.0 next. >>=20 >> -Krzysztof >>=20 >> _______________________________________________ >> 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" >>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Sep 13 01:41: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 76D80BD7C0E for ; Tue, 13 Sep 2016 01:41:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-191.reflexion.net [208.70.211.191]) (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 2876A880 for ; Tue, 13 Sep 2016 01:41:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30923 invoked from network); 13 Sep 2016 01:41:39 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 01:41:39 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Mon, 12 Sep 2016 21:40:42 -0400 (EDT) Received: (qmail 31361 invoked from network); 13 Sep 2016 01:40:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 01:40:42 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id AF6B4EC8073; Mon, 12 Sep 2016 18:40:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: From llvm: Fwd: [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) [fixed in llvm -r280705] From: Mark Millard In-Reply-To: <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> Date: Mon, 12 Sep 2016 18:40:48 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <08136189-299F-4BD6-9E49-8D39A8913D62@dsl-only.net> <0E2783E3-277F-47F1-B696-46FCFF0DB0F1@dsl-only.net> <09E211AC-6245-4A89-94DE-225A5EBA1FD2@FreeBSD.org> <827D7E4C-5719-456E-95D3-A95BBC341E7E@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2016 01:41:21 -0000 On 2016-Sep-10, at 6:56 PM, Mark Millard wrote: > Quick top post: Krzysztof has re-opened llvm bugzilla 26519 because = the post-amble side of things has not been fixed yet. . . >=20 >=20 >=20 > Krzysztof Parzyszek changed bug 26519=20 > What Removed Added > Status RESOLVED REOPENED > Resolution FIXED --- > Comment # 9 on bug 26519 from Krzysztof Parzyszek > The post-amble has not been fixed. >=20 > You are receiving this mail because: > =E2=80=A2 You reported the bug. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net There is now a code review active for this now, quoting the notice: > Comment # 10 on bug 26519 from Krzysztof Parzyszek > The epilogue part of the fix: https://reviews.llvm.org/D24466 >=20 >=20 > Hopefully there is nothing else missing. >=20 > You are receiving this mail because: > =E2=80=A2 You reported the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Sep-10, at 6:23 PM, Mark Millard wrote: >=20 > On 2016-Sep-10, at 10:18 AM, Dimitry Andric = wrote: >=20 >> On 06 Sep 2016, at 15:04, Mark Millard = wrote: >>>=20 >>> llvm's bugzilla reports that the stack-handling SVR4 ABI violation = for TARGET_ARCH=3Dpowerpc has been fixed r280705 (likely on trunk)! >>=20 >> I merged the upstream fix to projects/clang390-import: >>=20 >> https://svnweb.freebsd.org/changeset/base/305686 >>=20 >> -Dimitry >=20 > Looking at things for this again I've submitted a question to = https://llvm.org/bugs/show_bug.cgi?id=3D26519 asking if the post-amble = code's side if things was also adjusted (instead of just the = pre-amble/"claim" code side of things). >=20 > [I'm not clang/llvm literate so I may have missed interpreted = something when I looked.] >=20 > My original submittal also noted the stack pointer adjustment-timing = problem existed on the post-amble side in 3.8.0's code generation (when = removing the frame from the stack): >=20 >> 0x1801b8c : lwz r30,24(r31) >> 0x1801b90 : lwz r29,20(r31) >> 0x1801b94 : lwz r28,16(r31) >> 0x1801b98 : lwz r27,12(r31) >> 0x1801b9c : lwz r26,8(r31) >> 0x1801ba0 : addi r1,r1,32 # Stack = pointer adjusted first >> 0x1801ba4 : lwz r0,4(r1) >> 0x1801ba8 : lwz r31,-4(r1) # Then Frame = Pointer load happens >> # "outside" the new = stack range. >> 0x1801bac : mtlr r0 >> 0x1801bb0 : blr >=20 > If such code can still be generated there would still be a time frame = needing a red-zone to protect stack the contents from signals. >=20 > Hopefully I'm just wrong and this was fixed too. >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-ppc@freebsd.org Tue Sep 13 03:33:10 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 D10B8BD8B73 for ; Tue, 13 Sep 2016 03:33:10 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9889E48 for ; Tue, 13 Sep 2016 03:33:10 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u8D3X6mL016497 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Sep 2016 20:33:07 -0700 Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx To: Mark Millard References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> <3EC34F05-EF27-404B-816E-9A104105D097@dsl-only.net> Cc: Krzysztof Parzyszek , freebsd-ppc@freebsd.org From: Nathan Whitehorn Message-ID: <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org> Date: Mon, 12 Sep 2016 20:33:06 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3EC34F05-EF27-404B-816E-9A104105D097@dsl-only.net> Content-Type: multipart/mixed; boundary="------------495F03CC35D5207AF8FDE68F" X-Sonic-CAuth: UmFuZG9tSVZXbcEt7cGVoRpzAKdjjsGWmo8Kji3hjJUItgkGlLcxTDrrRkfDGk2je5hKwymtNvZWcNAfLv/2doDEtkGAbZleSXcleSPY3ds= X-Sonic-ID: C;3KcMyWJ55hG3oK/hcgQksw== M;XExMyWJ55hG3oK/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 13 Sep 2016 03:33:10 -0000 This is a multi-part message in MIME format. --------------495F03CC35D5207AF8FDE68F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/12/16 14:50, Mark Millard wrote: > On 2016-Sep-12, at 2:00 PM, Nathan Whitehorn wrote: > >> On 09/11/16 12:04, Krzysztof Parzyszek wrote: >>> On 9/10/2016 7:12 PM, Mark Millard wrote: >>>> Your report that you have some sort of failure after booting during the likes of buildkernel is new as far as I know. Sending the list (and/or a bugzilla report) about the failure mode and related information may be appropriate and help in the future. (May be I missed an already existing report.) >>> I think the issues with hangs are related to the temperature sensors. I was getting console messages that the media temp sensor was reporting 120C! I realized that as I replaced the hard drive, I changed the position of the drive in a way that exposed the sensor to the wind from the fans (it used to be angled a bit). Following this line of thought, I stuck a piece of paper in front of the sensor and things seem to work. At least work better than before. I have ordered a replacement sensor from eBay, so hopefully that problem will go away. >>> >>> Regarding your "hack": it works perfectly! So far, my system (10.3 at the moment) has booted every single time, no exceptions, traps, unexpected conditions. This is too good to remain as a "hack". I have no experience debugging the kernel and I don't know ABI the OFW follows, but I wouldn't mind digging a bit deeper into it, if someone shared some pointers. >> I've finally understood why this helps. Open Firmware runs in virtual mode on the Powermac G5. This runs inside the kernel page table, which preserves all address translations made by OF before the kernel starts; as a result, the kernel address space is a strict superset of OF's. >> >> Where this explodes is if OF uses an unmapped SLB entry. The SLB fault handler runs in real mode and refers to the PCPU pointer in SPRG0, which blows up the kernel. Having a value of SPRG0 that works for the kernel is less fatal than preserving OF's value in this case. > Actual theory of operation material! Great! I've no clue how I would have figured out the Apple Open Firmware side of the context so I'd still be stuck with just observation of the overall change in behavior. > > Presuming that you are correct: no longer "just a hack". That is great news. > > It does sound like the Open Firmware side gets some risk of picking up the wrong address map with the change. So avoiding Open Firmware in the kernel via the usefdt=1 sounds like it would still be appropriate. > >> I believe that OF's SPRG0 is maintained only for compatibility with some G4 Apple hardware, the eMac in particular, but will check and we can move on with this. I think it should be safe to wrap this in an #ifdef __powerpc64__. >> -Nathan > Again I've no clue how I would figure such a thing out. But, if some powerpc Macs are the only reason GENERIC preserves SPRG0 and preserving works for the other powerpcs so that detecting PowerMac vs. not is not really required to decide on the SPRG0 handling (at least for powerpc64), that too is great news. > > > Thanks for continuing to look into why the SPRG0 change might have a solid justification! Here's a patch that I think is commitable. I've tested it on a PowerMac 11,2 with no ill effect. I would appreciate testing on any other models of PowerMac G5 (or iMac G5) before committing. This only changes behavior on powerpc64 kernels running on Apple-branded systems, so no need for testing on non-Apple or non-G5 hardware. -Nathan --------------495F03CC35D5207AF8FDE68F Content-Type: text/plain; charset=UTF-8; name="sprg0-preserve-ppc64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sprg0-preserve-ppc64.patch" Index: sys/powerpc/ofw/ofw_machdep.c =================================================================== --- sys/powerpc/ofw/ofw_machdep.c (revision 305719) +++ sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -98,7 +98,12 @@ /* * Saved SPRG0-3 from OpenFirmware. Will be restored prior to the callback. + * Applies only to work around some broken on a few 32-bit Apple systems. + * Harmful on 64-bit systems, as this code can tread on registers used by + * the SLB fault handler, which can be invoked from inside firmware. */ + +#ifndef __powerpc64__ register_t ofw_sprg0_save; static __inline void @@ -140,6 +145,8 @@ } #endif +#endif + static int parse_ofw_memory(phandle_t node, const char *prop, struct mem_region *output) { @@ -344,11 +351,12 @@ ofmsr[0] = mfmsr(); #ifdef __powerpc64__ ofmsr[0] &= ~PSL_SF; - #endif + #else __asm __volatile("mfsprg0 %0" : "=&r"(ofmsr[1])); __asm __volatile("mfsprg1 %0" : "=&r"(ofmsr[2])); __asm __volatile("mfsprg2 %0" : "=&r"(ofmsr[3])); __asm __volatile("mfsprg3 %0" : "=&r"(ofmsr[4])); + #endif openfirmware_entry = openfirm; if (ofmsr[0] & PSL_DR) @@ -440,7 +448,9 @@ */ oldmsr = intr_disable(); +#ifndef __powerpc64__ ofw_sprg_prepare(); +#endif /* Save trap vectors */ ofw_save_trap_vec(save_trap_of); @@ -463,7 +473,9 @@ /* Restore trap vecotrs */ ofw_restore_trap_vec(save_trap_of); +#ifndef __powerpc64__ ofw_sprg_restore(); +#endif intr_restore(oldmsr); --------------495F03CC35D5207AF8FDE68F-- From owner-freebsd-ppc@freebsd.org Tue Sep 13 04:18:53 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 9FE2ABD750D for ; Tue, 13 Sep 2016 04:18:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 49BB6EE4 for ; Tue, 13 Sep 2016 04:18:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9957 invoked from network); 13 Sep 2016 03:52:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 03:52:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Mon, 12 Sep 2016 23:52:03 -0400 (EDT) Received: (qmail 2906 invoked from network); 13 Sep 2016 03:52:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 03:52:03 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 86F57EC8AEF; Mon, 12 Sep 2016 20:52:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx From: Mark Millard In-Reply-To: <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org> Date: Mon, 12 Sep 2016 20:52:09 -0700 Cc: Krzysztof Parzyszek , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <77F66C6E-CFA2-4C10-B296-9DBF62575480@dsl-only.net> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> <5fd3b681-1050-9602-b338-fe0dc5e10642@swissmail.org> <3177b120-625b-49bb-dbc8-46ea99e46097@freebsd.org> <3EC34F05-EF27-404B-816E-9A104105D097@dsl-only.net> <9f0bea97-7b14-05f3-4970-ca9dac9787ac@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2016 04:18:53 -0000 On 2016-Sep-12, at 8:33 PM, Nathan Whitehorn = wrote: > On 09/12/16 14:50, Mark Millard wrote: >> On 2016-Sep-12, at 2:00 PM, Nathan Whitehorn wrote: >>=20 >>> On 09/11/16 12:04, Krzysztof Parzyszek wrote: . . . >>>> Regarding your "hack": it works perfectly! So far, my system (10.3 = at the moment) has booted every single time, no exceptions, traps, = unexpected conditions. This is too good to remain as a "hack". I have no = experience debugging the kernel and I don't know ABI the OFW follows, = but I wouldn't mind digging a bit deeper into it, if someone shared some = pointers. >>> I've finally understood why this helps. Open Firmware runs in = virtual mode on the Powermac G5. This runs inside the kernel page table, = which preserves all address translations made by OF before the kernel = starts; as a result, the kernel address space is a strict superset of = OF's. >>>=20 >>> Where this explodes is if OF uses an unmapped SLB entry. The SLB = fault handler runs in real mode and refers to the PCPU pointer in SPRG0, = which blows up the kernel. Having a value of SPRG0 that works for the = kernel is less fatal than preserving OF's value in this case. >> Actual theory of operation material! Great! I've no clue how I would = have figured out the Apple Open Firmware side of the context so I'd = still be stuck with just observation of the overall change in behavior. >>=20 >> Presuming that you are correct: no longer "just a hack". That is = great news. >>=20 >> It does sound like the Open Firmware side gets some risk of picking = up the wrong address map with the change. So avoiding Open Firmware in = the kernel via the usefdt=3D1 sounds like it would still be appropriate. >>=20 >>> I believe that OF's SPRG0 is maintained only for compatibility with = some G4 Apple hardware, the eMac in particular, but will check and we = can move on with this. I think it should be safe to wrap this in an = #ifdef __powerpc64__. >>> -Nathan >> Again I've no clue how I would figure such a thing out. But, if some = powerpc Macs are the only reason GENERIC preserves SPRG0 and preserving = works for the other powerpcs so that detecting PowerMac vs. not is not = really required to decide on the SPRG0 handling (at least for = powerpc64), that too is great news. >>=20 >>=20 >> Thanks for continuing to look into why the SPRG0 change might have a = solid justification! >=20 > Here's a patch that I think is commitable. I've tested it on a = PowerMac 11,2 with no ill effect. I would appreciate testing on any = other models of PowerMac G5 (or iMac G5) before committing. This only = changes behavior on powerpc64 kernels running on Apple-branded systems, = so no need for testing on non-Apple or non-G5 hardware. > -Nathan > Unfortunately I'll not have access for a few weeks yet. Once I have = access again it would be a PowerMac7,2 that I'd test. The only other = G5's that I'd have access to are PowerMac11,2's (with varying amounts of = RAM). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Sep 13 06:31:05 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 9B9C1BD73F3 for ; Tue, 13 Sep 2016 06:31:05 +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 895D3FC5 for ; Tue, 13 Sep 2016 06:31:05 +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 u8D6V5o0025992 for ; Tue, 13 Sep 2016 06:31:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 13 Sep 2016 06:31:05 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 13 Sep 2016 06:31:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #5 from Mark Millard --- Nathan Whitehorn has put out a kernel patch that he is asking for help with testing on PowerMac/iMac G5 variations. See: https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html The patch is not just using __powerpc64__ instead of POWERMAC_G5_SPECIFIC_B= UILD in my presentation of my hack. Nathan has already tested a PowerMac11,2. If anyone reading this has any other type(s) of Apple G5's and is willing/a= ble it would be good to get in some testing before the change is made to the kernel. I expect that it does not mater much which version/variation of 10.x, 11.0,= or 12 is used if the original boot problems can sometimes be observed before t= he change. Although I'm not sure of the patch automatically applies nicely to = all possible vintages of those. As for me. . . It will be a few weeks before I'll again have access in order to test a PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll not have access to other Apple G5's. So my range of testing will be rather limited a= nd will not be soon. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Sep 13 08:03: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 1DE2ABD16A7 for ; Tue, 13 Sep 2016 08:03:38 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::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 92BC45F9 for ; Tue, 13 Sep 2016 08:03:37 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id s64so6878046lfs.2 for ; Tue, 13 Sep 2016 01:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=NavtNzQUH+TEpnAlmd16ivaRR9Gsom/EH7EOSk3i4tM=; b=TvEIzRoyGgnMAVbQ1bCzoPNbeHbR5NRLPh/Nmklq6tanlu4YvL16gCqjDZAIeUn67F GpZlJChQqQmZ/Vf2Ql+4DrnR3OC/B8X6HcsD6doL+D/O5zR2SPWLOCxO6rvC8IygX634 8cLB3UxuufLnvo08c7jNDIh4R9mDPB3I4zbcRhREtROPXLH13mucDWHzQvBoLq78oXpw 1kOH1tnDGTdo0GrGd3NENjraViMM5cuT1nWl+8uNGzEu69p6/s9IdxauooqDKCXtQM7S x+ZueHuKw7EdAH4qFNCNsiKFjd0REYOA6KnS2hi0FtkOev3LAh8sacDNv+oQ3U6lrDRE p1/w== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NavtNzQUH+TEpnAlmd16ivaRR9Gsom/EH7EOSk3i4tM=; b=UlFYWmPcvrNZiEh9BQZ45lph5hUJAGaDqjo6n6XxIokyrH9OWBhuNeS8AOGLAXsHdq 7qgq5DWBhuTMJYntVUz6fzKNpwZUEn/DBqgsaiPgVLLFqkJn79N+9dj2V2d8+YoNzPQO 4RpBldfGELk/a0tjWisZYuApMTbpcVD9PwXWhXQtx94Bw93wxVeppA/97So8TMNEHzRy dt5WtzFfuF28fbBoVUweXit9Ck4El3IVXSKXc1DX7Kktj6CyEIRT3DHWOFO+mWeDhvKx qRjikOUtCr0fRM1PmilFyU39qCQxTmtoxosQvlX5mtbEINTvtrfp4LGuDj9k9Y/JJh95 WQsw== X-Gm-Message-State: AE9vXwMHCR+/JWkW1sX/0Hgm/OY7+O3JbxYvzXl+FQmwvjsehDzUg2KzJWHFEpXOpX9Vng== X-Received: by 10.46.32.29 with SMTP id g29mr6547645ljg.32.1473753815424; Tue, 13 Sep 2016 01:03:35 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id s21sm3624304lfg.13.2016.09.13.01.03.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Sep 2016 01:03:34 -0700 (PDT) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: freebsd-ppc@freebsd.org References: From: "Jukka A. Ukkonen" Message-ID: <6da942cf-8e1e-c440-f255-a4ac78c1f8fa@gmail.com> Date: Tue, 13 Sep 2016 11:03:33 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Tue, 13 Sep 2016 08:03:38 -0000 On 09/13/16 09:31, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458 > > --- Comment #5 from Mark Millard --- > Nathan Whitehorn has put out a kernel patch that he is asking for help with > testing on PowerMac/iMac G5 variations. See: > > https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html > > The patch is not just using __powerpc64__ instead of POWERMAC_G5_SPECIFIC_BUILD > in my presentation of my hack. > > Nathan has already tested a PowerMac11,2. > > If anyone reading this has any other type(s) of Apple G5's and is willing/able > it would be good to get in some testing before the change is made to the > kernel. > > I expect that it does not mater much which version/variation of 10.x, 11.0, or > 12 is used if the original boot problems can sometimes be observed before the > change. Although I'm not sure of the patch automatically applies nicely to all > possible vintages of those. > > > As for me. . . > > It will be a few weeks before I'll again have access in order to test a > PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll not have > access to other Apple G5's. So my range of testing will be rather limited and > will not be soon. > I just tried the patch on a PowerMac G5 early 2005 model ... cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz cpu0: Features dc000000 cpu0: HID0 511081 which I think is a PowerMac7,3. It still panics right after it has reported VT(ofwfb). --jau From owner-freebsd-ppc@freebsd.org Tue Sep 13 08:45: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 127CFBD62B8 for ; Tue, 13 Sep 2016 08:45:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 A9B93E4D for ; Tue, 13 Sep 2016 08:45:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17255 invoked from network); 13 Sep 2016 08:46:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 08:46:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 04:45:33 -0400 (EDT) Received: (qmail 12709 invoked from network); 13 Sep 2016 08:45:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 08:45:33 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 652A7EC8073; Tue, 13 Sep 2016 01:45:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 13 Sep 2016 01:45:26 -0700 Message-Id: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> Cc: FreeBSD PowerPC ML , Nathan Whitehorn To: jau789@gamil.com Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2016 08:45:31 -0000 Jukka A. Ukkonen jau789 at gmail.com wrote on Tue Sep 13 08:03:38 UTC = 2016 : > On 09/13/16 09:31, bugzilla-noreply at freebsd.org wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 > >=20 > > --- Comment #5 from Mark Millard --- > > Nathan Whitehorn has put out a kernel patch that he is asking for = help with > > testing on PowerMac/iMac G5 variations. See: > >=20 > > = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html= > >=20 > > The patch is not just using __powerpc64__ instead of = POWERMAC_G5_SPECIFIC_BUILD > > in my presentation of my hack. > >=20 > > Nathan has already tested a PowerMac11,2. > >=20 > > If anyone reading this has any other type(s) of Apple G5's and is = willing/able > > it would be good to get in some testing before the change is made to = the > > kernel. > >=20 > > I expect that it does not mater much which version/variation of = 10.x, 11.0, or > > 12 is used if the original boot problems can sometimes be observed = before the > > change. Although I'm not sure of the patch automatically applies = nicely to all > > possible vintages of those. > >=20 > >=20 > > As for me. . . > >=20 > > It will be a few weeks before I'll again have access in order to = test a > > PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll = not have > > access to other Apple G5's. So my range of testing will be rather = limited and > > will not be soon. > >=20 >=20 > I just tried the patch on a PowerMac G5 early 2005 > model ... >=20 > cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz > cpu0: Features dc000000 > cpu0: HID0 511081 >=20 > which I think is a PowerMac7,3. It still panics right > after it has reported VT(ofwfb). >=20 > --jau [Be warned that it has been since early June since I've done any = on-powerpc activity. My memory need not be correct or complete enough = and I do not have the context to cross-check myself at this time.] I build world and kernel from source and build the kernel to have sc and = vt present (and PS3 disabled in order to allow that) but I only use sc = for the larger display that I sometimes use (2560x1440 as I remember). [Note: I've only used console mode for a long time. I've no clue if X11 = is even still possible via the ports. Although that also might get into = which video card is present. Someday I'll probably try that again.] If I remember right this sc-only use is because things did not work well = for vt with that large of display (last that I tried). But I do not = remember just where/how it stopped/failed. (I could be confusing an = older memory with more modern behavior to some extent.) At one time = there was an unchecked memory buffer overrun for console use for such = large screens, at least in some 10.x variant for at least one of vt vs. = sc. That background information means that "after it has reported VT(ofwfb)" = leads me to wonder if a vt/screen-size related issue might be involved. Another testing option (other than screen size variations) would be to = try my hack instead of Nathan's code. (I expect the same result. But if = not then that result would be interesting.) That change from = original/offcial source would be the deletion of "mtsprg0 %1\n\t" and "r"(ofmsr[1]), from: > __asm __volatile("mfsprg0 %0\n\t" > "mtsprg0 %1\n\t" > "mtsprg1 %2\n\t" > "mtsprg2 %3\n\t" > "mtsprg3 %4\n\t" > : "=3D&r"(ofw_sprg0_save) > : "r"(ofmsr[1]), > "r"(ofmsr[2]), > "r"(ofmsr[3]), > "r"(ofmsr[4])); in sys/powerpc/ofw/ofw_machdep.c . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:11:36 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 A08C2BD9A66 for ; Tue, 13 Sep 2016 17:11:36 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 1F8A97A7 for ; Tue, 13 Sep 2016 17:11:36 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id k12so7393173lfb.1 for ; Tue, 13 Sep 2016 10:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=fHcuNrByxPPdaelgmetpEc9mCHXhnGrw9iGYXiI+y4o=; b=V6nCOZieouvjiADYwsYT6JqvZv86QgtKxEWIcXz66R7VMH8VPT7JBwSHKRjfIQjGBr LnnRO89Ju/9uhFHNinCiDdXGp+ireI7GDWBgsCtggGGbJANKXtwBdcy1jc6Jia+cXNxd a1viVGo7NH58qEpSscKKXWybbK9xNE5RFyVWJhE0YMYz0TTuknWBDD9AdbznNelWHTbA E9hR78f4Y5ktl3fTd693gncn6/fFBSD9YmqxGWJjtnxixioZEA4SkPDrmkiCI6JYGrqZ OH/8Bq0JW2yEHSlwOFwEj6Ng0j99cUFIKPPVvqjKTMFEZ3HniHG/hFC7xmjLx6zhszRb HGdw== 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=fHcuNrByxPPdaelgmetpEc9mCHXhnGrw9iGYXiI+y4o=; b=I0vO9s+Hpv9JaRVy+C3fJZ5yrqhehEs/fhOd5ElPWkGvzOLlH5P2KJsnaNH47uMy1G o8eFdNfRTuF7tMTMXFWa4NwcRkJZVJHfBmc2rZQv4jpua+MOgPT1PdmDfWq1NB8P8oA9 tvq3BXXsJxCHnZnc4yzZrwIyyVGJK+wGYn5bFxuD9TyvssvS7ODi+AzAXEqiyCNCJU/b qYaworMeD5wOsXgxayDsSIplWU4qHcsdKw637unURJRAVQ/HvoOC7jUhMAgROJmoe2yS w6x5PPcSEPOj5r3z1G5nl4IHYQr41Gvlm98FFXEJLWfAsonciGZSHpD8BPHf3Z7R6arm y32w== X-Gm-Message-State: AE9vXwN53JQlSV5TbsxTNcd5m7FWHfLwhzIBw+XA3rzvLKYKY4zgUBpgZZozVsT6GttmKw== X-Received: by 10.46.0.93 with SMTP id 90mr7403140lja.39.1473786693188; Tue, 13 Sep 2016 10:11:33 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id c125sm4051889lfe.10.2016.09.13.10.11.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Sep 2016 10:11:32 -0700 (PDT) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: freebsd-ppc@freebsd.org References: From: "Jukka A. Ukkonen" Message-ID: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> Date: Tue, 13 Sep 2016 20:11:31 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------0F09F34F9C0F71223565B982" 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, 13 Sep 2016 17:11:36 -0000 This is a multi-part message in MIME format. --------------0F09F34F9C0F71223565B982 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 09/13/16 09:31, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458 > > --- Comment #5 from Mark Millard --- > Nathan Whitehorn has put out a kernel patch that he is asking for help with > testing on PowerMac/iMac G5 variations. See: > > https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html > > The patch is not just using __powerpc64__ instead of POWERMAC_G5_SPECIFIC_BUILD > in my presentation of my hack. > > Nathan has already tested a PowerMac11,2. > > If anyone reading this has any other type(s) of Apple G5's and is willing/able > it would be good to get in some testing before the change is made to the > kernel. > > I expect that it does not mater much which version/variation of 10.x, 11.0, or > 12 is used if the original boot problems can sometimes be observed before the > change. Although I'm not sure of the patch automatically applies nicely to all > possible vintages of those. > > > As for me. . . > > It will be a few weeks before I'll again have access in order to test a > PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll not have > access to other Apple G5's. So my range of testing will be rather limited and > will not be soon. > Following Mark's advice I tried an alternate change and now at least my PowerMac7,3 boots just fine through the autoconfigure phase. The first hiccup I see is with tmpfs mount to /tmp, but that, I hope, it is a completely unrelated issue. The patch I am now using on my PowerMac G5 is attached. The modification is Mark's, I just tested it. I don't have the foggiest idea where and how he figured out this change, but at least in my test on one system only it seems to work wonders. --jau PS. If someone knows why the tmpfs has started complaining mount: tmpfs: Operation not supported by device where it previously (last 11.0-BETA2) worked just fine, let me know. --------------0F09F34F9C0F71223565B982 Content-Type: text/x-patch; name="ppc64-ofw_machdep.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ppc64-ofw_machdep.c.patch" Index: 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 --- sys/powerpc/ofw/ofw_machdep.c (revision 305763) +++ sys/powerpc/ofw/ofw_machdep.c (working copy) @@ -112,12 +112,11 @@ * SPRG1-3 could be trashed */ __asm __volatile("mfsprg0 %0\n\t" - "mtsprg0 %1\n\t" - "mtsprg1 %2\n\t" - "mtsprg2 %3\n\t" - "mtsprg3 %4\n\t" + "mtsprg1 %1\n\t" + "mtsprg2 %2\n\t" + "mtsprg3 %3\n\t" : "=3D&r"(ofw_sprg0_save) - : "r"(ofmsr[1]), + :=20 "r"(ofmsr[2]), "r"(ofmsr[3]), "r"(ofmsr[4])); --------------0F09F34F9C0F71223565B982-- From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:15: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 AADCCBD9B95 for ; Tue, 13 Sep 2016 17:15: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 7FA7DB89 for ; Tue, 13 Sep 2016 17:15: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 u8DHF0iX002223 for ; Tue, 13 Sep 2016 17:15:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 13 Sep 2016 17:15:00 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 13 Sep 2016 17:15:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #6 from Mark Millard --- (In reply to Mark Millard from comment #5) Jukka A. Ukkonen has reported Nathan Whithorns patch to have failed to work= but my hack to have worked: In https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008416.ht= ml he reports the failure of Nathan's patch. . . I just tried the patch on a PowerMac G5 early 2005 model ... cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz cpu0: Features dc000000 cpu0: HID0 511081 which I think is a PowerMac7,3. It still panics right after it has reported VT(ofwfb). --jau But we had an E-mail exchange about him manually applying a simple edit to = get my patch and he reports in the end. . . I rebooted the box only a few minutes ago, and this time it booted just fine. Well, the tmpfs has started failing as follows... # mount /tmp mount: tmpfs: Operation not supported by device but supposedly this is an unrelated issue. At least I hope so. ;-) Now the function reads as shown below, and I guess this is exactly what you had in mind. static __inline void ofw_sprg_prepare(void) { if (ofw_real_mode) return; /* * Assume that interrupt are disabled at this point, or * SPRG1-3 could be trashed */ __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])); } So, from my point of view the PowerMac7,3 seems to be back to relative health with this change. I hope it works for all the other G5s as well. --jau --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:23: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 0CED0BD9E1C for ; Tue, 13 Sep 2016 17:23:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 C1D111AE for ; Tue, 13 Sep 2016 17:23:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26687 invoked from network); 13 Sep 2016 17:23:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 17:23:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 13:22:57 -0400 (EDT) Received: (qmail 31560 invoked from network); 13 Sep 2016 17:22:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 17:22:57 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 307EEEC9020; Tue, 13 Sep 2016 10:22:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) From: Mark Millard In-Reply-To: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> Date: Tue, 13 Sep 2016 10:22:51 -0700 Cc: FreeBSD PowerPC ML , jau789@gamil.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2016 17:23:01 -0000 On 2016-Sep-13, at 1:45 AM, Mark Millard wrote: > Jukka A. Ukkonen jau789 at gmail.com wrote on Tue Sep 13 08:03:38 UTC = 2016 : >=20 >> On 09/13/16 09:31, bugzilla-noreply at freebsd.org wrote: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 >>>=20 >>> --- Comment #5 from Mark Millard --- >>> Nathan Whitehorn has put out a kernel patch that he is asking for = help with >>> testing on PowerMac/iMac G5 variations. See: >>>=20 >>> = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html= >>>=20 >>> The patch is not just using __powerpc64__ instead of = POWERMAC_G5_SPECIFIC_BUILD >>> in my presentation of my hack. >>>=20 >>> Nathan has already tested a PowerMac11,2. >>>=20 >>> If anyone reading this has any other type(s) of Apple G5's and is = willing/able >>> it would be good to get in some testing before the change is made to = the >>> kernel. >>>=20 >>> I expect that it does not mater much which version/variation of = 10.x, 11.0, or >>> 12 is used if the original boot problems can sometimes be observed = before the >>> change. Although I'm not sure of the patch automatically applies = nicely to all >>> possible vintages of those. >>>=20 >>>=20 >>> As for me. . . >>>=20 >>> It will be a few weeks before I'll again have access in order to = test a >>> PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll = not have >>> access to other Apple G5's. So my range of testing will be rather = limited and >>> will not be soon. >>>=20 >>=20 >> I just tried the patch on a PowerMac G5 early 2005 >> model ... >>=20 >> cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz >> cpu0: Features dc000000 >> cpu0: HID0 511081 >>=20 >> which I think is a PowerMac7,3. It still panics right >> after it has reported VT(ofwfb). >>=20 >> --jau >=20 > [Be warned that it has been since early June since I've done any = on-powerpc activity. My memory need not be correct or complete enough = and I do not have the context to cross-check myself at this time.] >=20 > I build world and kernel from source and build the kernel to have sc = and vt present (and PS3 disabled in order to allow that) but I only use = sc for the larger display that I sometimes use (2560x1440 as I = remember). >=20 > [Note: I've only used console mode for a long time. I've no clue if = X11 is even still possible via the ports. Although that also might get = into which video card is present. Someday I'll probably try that again.] >=20 > If I remember right this sc-only use is because things did not work = well for vt with that large of display (last that I tried). But I do not = remember just where/how it stopped/failed. (I could be confusing an = older memory with more modern behavior to some extent.) At one time = there was an unchecked memory buffer overrun for console use for such = large screens, at least in some 10.x variant for at least one of vt vs. = sc. >=20 > That background information means that "after it has reported = VT(ofwfb)" leads me to wonder if a vt/screen-size related issue might be = involved. >=20 >=20 > Another testing option (other than screen size variations) would be to = try my hack instead of Nathan's code. (I expect the same result. But if = not then that result would be interesting.) That change from = original/offcial source would be the deletion of >=20 > "mtsprg0 %1\n\t" > and > "r"(ofmsr[1]), >=20 > from: >=20 >> __asm __volatile("mfsprg0 %0\n\t" >> "mtsprg0 %1\n\t" >> "mtsprg1 %2\n\t" >> "mtsprg2 %3\n\t" >> "mtsprg3 %4\n\t" >> : "=3D&r"(ofw_sprg0_save) >> : "r"(ofmsr[1]), >> "r"(ofmsr[2]), >> "r"(ofmsr[3]), >> "r"(ofmsr[4])); >=20 > in sys/powerpc/ofw/ofw_machdep.c . >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I had forgotten to say to deal with the Making the notation use %0, %1, = %2, %3 instead of %0, %2, %3, %4. So we had an E-mail exchange about him manually applying a simple edit = to get my patch and he reports in the end. . . > I rebooted the box only a few minutes ago, and this > time it booted just fine. > Well, the tmpfs has started failing as follows... >=20 > # mount /tmp > mount: tmpfs: Operation not supported by device >=20 > but supposedly this is an unrelated issue. At least I hope so. ;-) >=20 > Now the function reads as shown below, and I guess this is > exactly what you had in mind. >=20 > static __inline void > ofw_sprg_prepare(void) > { > if (ofw_real_mode) > return; >=20 > /* > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > __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])); > } >=20 > So, from my point of view the PowerMac7,3 seems to be back to > relative health with this change. I hope it works for all the > other G5s as well. >=20 > --jau I have updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 = with this information. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:28:05 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 63DC5BD9F42 for ; Tue, 13 Sep 2016 17:28:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 513DA355 for ; Tue, 13 Sep 2016 17:28:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u8DHS2m8004425 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2016 10:28:02 -0700 Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: freebsd-ppc@freebsd.org References: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> From: Nathan Whitehorn Message-ID: Date: Tue, 13 Sep 2016 10:28:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaOdG8754U2Ms+7u7LkE4zPwT2oEsZ9VTdDl5tzo4ygOwgWzDyAkc0HkZLRtXJz9P9otLzm63Tw41l0CxA5wCAwFboj3Oa0KWI= X-Sonic-ID: C;CiFNbNd55hGa/K/hcgQksw== M;WsySbNd55hGa/K/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 13 Sep 2016 17:28:05 -0000 Maybe firmware needs SPRG1-3 restored? Any chance you could try deleting the mtsprg1-3 one-by-one? -Nathan On 09/13/16 10:11, Jukka A. Ukkonen wrote: > On 09/13/16 09:31, bugzilla-noreply@freebsd.org wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458 >> >> --- Comment #5 from Mark Millard --- >> Nathan Whitehorn has put out a kernel patch that he is asking for help with >> testing on PowerMac/iMac G5 variations. See: >> >> https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html >> >> The patch is not just using __powerpc64__ instead of POWERMAC_G5_SPECIFIC_BUILD >> in my presentation of my hack. >> >> Nathan has already tested a PowerMac11,2. >> >> If anyone reading this has any other type(s) of Apple G5's and is willing/able >> it would be good to get in some testing before the change is made to the >> kernel. >> >> I expect that it does not mater much which version/variation of 10.x, 11.0, or >> 12 is used if the original boot problems can sometimes be observed before the >> change. Although I'm not sure of the patch automatically applies nicely to all >> possible vintages of those. >> >> >> As for me. . . >> >> It will be a few weeks before I'll again have access in order to test a >> PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll not have >> access to other Apple G5's. So my range of testing will be rather limited and >> will not be soon. >> > Following Mark's advice I tried an alternate change and > now at least my PowerMac7,3 boots just fine through the > autoconfigure phase. The first hiccup I see is with tmpfs > mount to /tmp, but that, I hope, it is a completely > unrelated issue. > > The patch I am now using on my PowerMac G5 is attached. > The modification is Mark's, I just tested it. I don't have > the foggiest idea where and how he figured out this change, > but at least in my test on one system only it seems to > work wonders. > > --jau > > > PS. > If someone knows why the tmpfs has started complaining > > mount: tmpfs: Operation not supported by device > > where it previously (last 11.0-BETA2) worked just fine, > let me know. > > > > _______________________________________________ > 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 Tue Sep 13 17:32:18 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 A6A66BD91AC for ; Tue, 13 Sep 2016 17:32:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 66813A1B for ; Tue, 13 Sep 2016 17:32:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32208 invoked from network); 13 Sep 2016 17:32:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2016 17:32:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Tue, 13 Sep 2016 13:32:21 -0400 (EDT) Received: (qmail 1495 invoked from network); 13 Sep 2016 17:32:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2016 17:32:21 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 98404EC9026; Tue, 13 Sep 2016 10:32:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) From: Mark Millard In-Reply-To: Date: Tue, 13 Sep 2016 10:32:14 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A406E69-0C88-47B9-97BB-9E07561A8139@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2016 17:32:18 -0000 A quick top post of a clarification: The "simple edit" was to the = official source for for whatever FreeBSD variant Jukka was using (not to = Nathan's patched source): none of Nathan's patch involved for the simple = edit result. The result does not have the #if __powerpc64__ sort of logic that would = be needed in official source but just serves as a test of the = alternative. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Sep-13, at 10:22 AM, Mark Millard = wrote: >=20 > On 2016-Sep-13, at 1:45 AM, Mark Millard = wrote: >=20 >> Jukka A. Ukkonen jau789 at gmail.com wrote on Tue Sep 13 08:03:38 = UTC 2016 : >>=20 >>> On 09/13/16 09:31, bugzilla-noreply at freebsd.org wrote: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 >>>>=20 >>>> --- Comment #5 from Mark Millard --- >>>> Nathan Whitehorn has put out a kernel patch that he is asking for = help with >>>> testing on PowerMac/iMac G5 variations. See: >>>>=20 >>>> = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-September/008413.html= >>>>=20 >>>> The patch is not just using __powerpc64__ instead of = POWERMAC_G5_SPECIFIC_BUILD >>>> in my presentation of my hack. >>>>=20 >>>> Nathan has already tested a PowerMac11,2. >>>>=20 >>>> If anyone reading this has any other type(s) of Apple G5's and is = willing/able >>>> it would be good to get in some testing before the change is made = to the >>>> kernel. >>>>=20 >>>> I expect that it does not mater much which version/variation of = 10.x, 11.0, or >>>> 12 is used if the original boot problems can sometimes be observed = before the >>>> change. Although I'm not sure of the patch automatically applies = nicely to all >>>> possible vintages of those. >>>>=20 >>>>=20 >>>> As for me. . . >>>>=20 >>>> It will be a few weeks before I'll again have access in order to = test a >>>> PowerMac7,2 (or to independently repeat PowerMac11,2 testing). I'll = not have >>>> access to other Apple G5's. So my range of testing will be rather = limited and >>>> will not be soon. >>>>=20 >>>=20 >>> I just tried the patch on a PowerMac G5 early 2005 >>> model ... >>>=20 >>> cpu0: IBM PowerPC 970 revision 2.2, 2000.19 MHz >>> cpu0: Features dc000000 >>> cpu0: HID0 511081 >>>=20 >>> which I think is a PowerMac7,3. It still panics right >>> after it has reported VT(ofwfb). >>>=20 >>> --jau >>=20 >> [Be warned that it has been since early June since I've done any = on-powerpc activity. My memory need not be correct or complete enough = and I do not have the context to cross-check myself at this time.] >>=20 >> I build world and kernel from source and build the kernel to have sc = and vt present (and PS3 disabled in order to allow that) but I only use = sc for the larger display that I sometimes use (2560x1440 as I = remember). >>=20 >> [Note: I've only used console mode for a long time. I've no clue if = X11 is even still possible via the ports. Although that also might get = into which video card is present. Someday I'll probably try that again.] >>=20 >> If I remember right this sc-only use is because things did not work = well for vt with that large of display (last that I tried). But I do not = remember just where/how it stopped/failed. (I could be confusing an = older memory with more modern behavior to some extent.) At one time = there was an unchecked memory buffer overrun for console use for such = large screens, at least in some 10.x variant for at least one of vt vs. = sc. >>=20 >> That background information means that "after it has reported = VT(ofwfb)" leads me to wonder if a vt/screen-size related issue might be = involved. >>=20 >>=20 >> Another testing option (other than screen size variations) would be = to try my hack instead of Nathan's code. (I expect the same result. But = if not then that result would be interesting.) That change from = original/offcial source would be the deletion of >>=20 >> "mtsprg0 %1\n\t" >> and >> "r"(ofmsr[1]), >>=20 >> from: >>=20 >>> __asm __volatile("mfsprg0 %0\n\t" >>> "mtsprg0 %1\n\t" >>> "mtsprg1 %2\n\t" >>> "mtsprg2 %3\n\t" >>> "mtsprg3 %4\n\t" >>> : "=3D&r"(ofw_sprg0_save) >>> : "r"(ofmsr[1]), >>> "r"(ofmsr[2]), >>> "r"(ofmsr[3]), >>> "r"(ofmsr[4])); >>=20 >> in sys/powerpc/ofw/ofw_machdep.c . >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I had forgotten to say to deal with the Making the notation use %0, = %1, %2, %3 instead of %0, %2, %3, %4. >=20 > So we had an E-mail exchange about him manually applying a simple edit = to get my patch and he reports in the end. . . >=20 >> I rebooted the box only a few minutes ago, and this >> time it booted just fine. >> Well, the tmpfs has started failing as follows... >>=20 >> # mount /tmp >> mount: tmpfs: Operation not supported by device >>=20 >> but supposedly this is an unrelated issue. At least I hope so. ;-) >>=20 >> Now the function reads as shown below, and I guess this is >> exactly what you had in mind. >>=20 >> static __inline void >> ofw_sprg_prepare(void) >> { >> if (ofw_real_mode) >> return; >>=20 >> /* >> * Assume that interrupt are disabled at this point, or >> * SPRG1-3 could be trashed >> */ >> __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])); >> } >>=20 >> So, from my point of view the PowerMac7,3 seems to be back to >> relative health with this change. I hope it works for all the >> other G5s as well. >>=20 >> --jau >=20 > I have updated = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 with this = information. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:36:20 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 15D5CBD928F for ; Tue, 13 Sep 2016 17:36:20 +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 04D5AB6D for ; Tue, 13 Sep 2016 17:36:20 +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 u8DHaJKd052328 for ; Tue, 13 Sep 2016 17:36:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 13 Sep 2016 17:36:19 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 13 Sep 2016 17:36:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #7 from Mark Millard --- (In reply to Mark Millard from comment #6) That test code does not have the #ifdef __powerpc64__ logic that an official update would need to also G4's and the like: it just serves as a test of the alternative's operation on Jukka's PowerMac7,3. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Sep 13 17:38: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 04803BD938C for ; Tue, 13 Sep 2016 17:38:58 +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 E7846D18 for ; Tue, 13 Sep 2016 17:38:57 +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 u8DHcv1V056751 for ; Tue, 13 Sep 2016 17:38:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 13 Sep 2016 17:38:58 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 13 Sep 2016 17:38:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #8 from Mark Millard --- (In reply to Mark Millard from comment #7) Also: The "simple edit" involved was to the official svn source that does n= ot have Nathan's proposed patch. My original wording did not make that explici= t. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Sep 13 19:20:05 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 A9008BD87A2 for ; Tue, 13 Sep 2016 19:20:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 922107F9 for ; Tue, 13 Sep 2016 19:20:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 91AB01611; Tue, 13 Sep 2016 19:20:05 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by freefall.freebsd.org (Postfix) with ESMTP id 9119E160C for ; Tue, 13 Sep 2016 19:20:05 +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 7DDC97F8 for ; Tue, 13 Sep 2016 19:20:05 +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 u8DJK5CU074908 for ; Tue, 13 Sep 2016 19:20:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 212667] [PATCH] machdep.c: check DDB_ENABLED before defining SPR/db_show_table Date: Tue, 13 Sep 2016 19:20:05 +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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-powerpc@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: Tue, 13 Sep 2016 19:20:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212667 Ngie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-powerpc@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Wed Sep 14 06:49: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 84C8CBDA781 for ; Wed, 14 Sep 2016 06:49:58 +0000 (UTC) (envelope-from andy.silva@snsreports.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 43BB3F01 for ; Wed, 14 Sep 2016 06:49:57 +0000 (UTC) (envelope-from andy.silva@snsreports.com) X-MSFBL: eyJiIjoiNzRfOTFfODVfMjM4IiwiciI6ImZyZWVic2QtcHBjQGZyZWVic2Qub3Jn IiwiZyI6IlNuc3RlbGVjb21fZGVkaWNhdGVkX3Bvb2wifQ== Received: from [192.168.80.12] ([192.168.80.12:36259] helo=rs-ord-mta01-2.smtp.com) by rs-ord-mta03-4.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTP id 3C/CD-18802-A03F8D75; Wed, 14 Sep 2016 06:49:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1473835786; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=JTnyclfjxl/HL4ZT9jTSvNuoZeUBJasr9HdRx+zBNdo=; b=in4GxMatHkNPyG3deJlroK+fbCUafnRM1jtqYLVD34Tyh/oQlw+p0tWGepEKOQ+6 BE7t48JkBl+Q0WMQ7HKZ98Vy/QxLQQhsfrc5r8jlDNILvDQmrf+cqguf6VgiyGO2 RC1QAqMCxbddlZAwqS6WmUQ3qLdhGFkXqI3msiAK2+E=; Received: from [70.79.69.78] ([70.79.69.78:41848] helo=S01061c1b689e28c7.vc.shawcable.net) by rs-ord-mta01-2.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 34/3B-15034-A03F8D75; Wed, 14 Sep 2016 06:49:46 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsreports.com To: freebsd-ppc@freebsd.org Subject: The Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Tue, 13 Sep 2016 23:49:38 -0700 Message-ID: <4984405849488606910899@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: 9c30d10b-fcad-4b76-a5c4-e1e5ef9bac3e 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, 14 Sep 2016 06:49:58 -0000 The Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges,= Strategies, Industry Verticals and Forecasts Hello=20 Let me offer you the latest SNS Research report to you and your team, " The= Wireless Network Infrastructure Ecosystem: 2016 - 2030 - Macrocell RAN, Sm= all Cells, C-RAN, RRH, DAS, Carrier Wi-Fi, Mobile Core, Backhaul & Fronthau= l " Below is the report highlight and if you like I can send you sample pag= es for your details inside. =20 Our reports are compiled with primary and secondary informations to produce= an overall industry outlook. Report Information: Release Date: May 2016 Number of Pages: 652 Number of Tables and Figures: 219 =20 =20 Report Overview: =20 While wearable technology has been utilized in vertical sectors such as the= military and healthcare for many years, ongoing advances have triggered a = major resurgence of the concept, particularly among the consumer community.= Key enabling technologies including low cost sensors, wireless connectivit= y, active materials and energy have converged to make wearable technology m= ainstream.=20 With the continued miniaturization of enabling technologies, wearable devic= es have hit the mass market in a diverse variety of form factors, ranging f= rom glasses to even jewelry. Driven by the ability to interconnect with key modern trends of healthcare,= fitness, messaging and socialization, the wearable technology ecosystem is= attracting significant levels of interest. Companies as varied as smartph= one OEMs, wireless carriers, health insurers and retailers are circling the= ecosystem alongside tiny startups, all vying for a stake. SNS Research estimates that by 2016, wearable device shipments will surpass= 140 Million and will account for nearly $30 Billion in revenue. The market= is further expected to grow at a CAGR of 30% over the next five years. The "Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges= , Strategies, Industry Verticals & Forecasts" report presents an in-depth a= ssessment of the wearable technology ecosystem including key market drivers= , challenges, investment potential, consumer & vertical market opportunitie= s, use cases, future roadmap, value chain, case studies, vendor market shar= e and strategies. The report also presents forecasts for wearabledevice shi= pments and revenue from 2015 through to 2030. The forecasts are further seg= mented for 7 device form factor submarkets, 7 vertical markets, 6 regions a= nd 73 countries. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report. Key Findings: =20 The report has the following key findings: SNS Research estimates that wearable device shipments will grow at a CAGR o= f 29% between 2016 and 2020. By 2020, wearable devices will represent a mar= ket worth $40 Billion with over 240 Million annual unit shipments. Leading smartphone OEMs, Apple and Samsung, are replicating their success i= n the OS powered smart watch arena with a combined market share of nearly 7= 5%. As wearable device OEMs seek to minimize dependence on hardware sales, new = business models are beginning to emerge, particularly in the enterprise spa= ce. For example, specialist vendors such as Catapult are offering subscript= ion based services to sports teams, which combine wearable sensors, cloud-b= ased software and analytics. SNS Research estimates that wearable devices will help mobile operators dri= ve over $13 Billion in service revenue by the end of 2020, following a CAGR= of nearly 32% between 2016 and 2020. The market is ripe for acquisitions of pure-play wearable technology startu= ps, as competition heats up between consumer and vertical centric OEMs. Topics Covered: =20 The report covers the following topics: Wearable technology ecosystem Market drivers and barriers Enabling technologies and operating systems for wearable devices Standardization and regulation landscape Wearable technology industry roadmap and value chain Assessment of vertical market opportunities and use cases for consumer, hea= lthcare, professional sports, retail & hospitality, military, public safety= and 8 other verticals Case studies of wearable technology deployments Company profiles and strategies of over 440 wearable technology ecosystem p= layers Wearable device vendor market share Prospects of smartphone OEMs and wireless chipset suppliers in the wearable= technology ecosystem Impact of 5G, NB-IoT and LTE Direct on wearable technology Strategic recommendations for enabling technology providers, wearable devic= e OEMs, vertical market players, application developers and mobile operators Market analysis and forecasts from 2016 till 2030 Forecast Segmentation: =20 Market forecasts are provided for each of the following submarkets and the= ir categories: Market forecasts are provided for each of the following submarkets and the= ir categories: Vertical Submarkets Consumer Healthcare Professional Sports Retail & Hospitality Military Public Safety Others Form Factor Submarkets Smart Bands Smart Watches Smart Glasses Smart Clothing Smart Jewelry Heads-up Displays Others Regional Markets Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Country Markets=20 73 Country level markets: Algeria, Argentina, Australia, Austria, Banglades= h, Belarus, Belgium, Bolivia, Bosnia & Herzegovina, Brazil, Bulgaria, Canad= a, Chile, China, Colombia, Croatia, Czech Republic, Denmark, Ecuador, Egypt= , Finland, France, Germany, Greece, Hong Kong, Hungary, India, Indonesia, I= reland, Israel, Italy, Japan, Kenya, Luxembourg, Malaysia, Mexico, Morocco,= Netherlands, New Zealand, Nigeria, Norway, Pakistan, Paraguay, Peru, Phili= ppines, Poland, Portugal, Qatar, Romania, Russia, Saudi Arabia, Serbia, Sin= gapore, Slovakia, South Africa, South Korea, Spain, Sudan, Sweden, Switzerl= and, Taiwan, Tanzania, Thailand, Tunisia, Turkey, UAE, UK, Ukraine, Uruguay= , USA, Uzbekistan, Venezuela and Vietnam Key Questions Answered: The report provides answers to the following key questions: How big is the wearable technology ecosystem=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F What trends, challenges and barriers are influencing its growth=3F Who are the key wearable device vendors and what are their strategies=3F How much are vertical enterprises investing in wearable devices=3F What opportunities exist for wireless chipset suppliers in the wearable tec= hnology ecosystem=3F How can mobile operators capitalize on the growing popularity of smart watc= hes, fitness bands, smart glasses and other wearable devices=3F Which countries, regions and verticals will see the highest percentage of w= earable device shipments=3F Which sports category will see the highest level of wearable technology int= egration=3F Report Pricing: Single User License: USD 2,500 Company Wide License: USD 3,500 Ordering Process: Please contact Andy Silva on andy.silva@snscommunication.com Provide the following information: 1. Report Title - 2. Report License - (Single User/Company Wide) 3. Name - 4. Email - 5. Job Title - 6. Company - 7. Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents mentioned below for your better inside. I look forward to hearing from you. Kind Regards Andy Silva Marketing Executive Signals and Systems Telecom =20 ___________________________________________________________________________= __________________________________________________________________________ =20 Table of Content =20 Chapter 1 1.1 Executive Summary 1.2 Topics Covered 1.3 Historical Revenue & Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 Chapter 2: An Overview of Wearable Technology 2.1 What is Wearable Technology=3F 2.2 Device Classification 2.2.1 Head-worn Devices 2.2.2 Wrist-worn Devices 2.2.3 Leg and Ankle-worn Devices 2.2.4 Arm, Chest and Neck-worn Devices 2.2.5 Smart Clothing & Jewelry 2.2.6 In-Body Wearables 2.3 Enabling Technologies 2.3.1 MEMS & Sensors 2.3.2 BT-LE (Bluetooth Low Energy) & WiFi 2.3.3 Voice Recognition 2.3.4 Lowed Powered Wireless SoCs 2.3.5 RFID & NFC 2.3.6 GPS & Navigation Technology 2.3.7 Energy Harvesting 2.3.8 Ergonomics & Materials Science 2.3.9 Augmented Reality 2.4 Market Growth Drivers 2.4.1 Proliferation of Smartphones 2.4.2 Advances in Enabling Technologies & Components 2.4.3 Interest from New Market Segments 2.4.4 Human Centric Assistance 2.4.5 Meaningful Analytics & Tracking 2.4.6 Venture Capital, Crowdfunding & Corporate Investments 2.4.7 Endorsement by Major Mobile OEMs 2.5 Market Barriers 2.5.1 High Costs 2.5.2 Power Consumption & Battery Life Issues 2.5.3 Usability & Unusual Styling 2.5.4 Potential Health Issues 2.5.5 Privacy & Security Concerns 2.5.6 Social Acceptance =20 Chapter 3: Vertical Opportunities & Use Cases 3.1 Consumer Markets 3.1.1 Infotainment & Lifestyle 3.1.2 Casual Sports & Fitness 3.1.3 Gaming 3.1.4 Pet Care 3.1.5 Child Care & Entertainment 3.1.6 Helping People with Disabilities 3.1.7 Car Insurance Claims 3.1.8 Accurate & Targeted Marketing 3.2 Healthcare 3.2.1 Remote Patient Monitoring 3.2.2 Assisted Patient Examination 3.2.3 Reducing Healthcare Costs 3.2.4 Optimizing Health Insurance Costs 3.2.5 Enhancing Medical R&D 3.3 Professional Sports 3.3.1 Sports Data Analytics 3.3.2 Enhancing Real-Time Decision Making 3.3.3 Injury Prevention 3.4 Retail & Hospitality 3.4.1 Improving Retail Productivity 3.4.2 Comparing & Contrasting Retail Items 3.4.3 Travel: Personalizing Customer Service 3.4.4 Replacing Hotel Keys and Credit Cards 3.4.5 Augmenting City & Museum Tours 3.5 Military 3.5.1 Enhancing Infantry Tactics: Shooting Without Being Shot 3.5.2 Monitoring Combat Stress & Injuries 3.5.3 Enhancing Situational Awareness in the Battlefield 3.5.4 Enabling Battlefield Mobility 3.5.5 Facilitating Communications with Military Dogs 3.6 Public Safety 3.6.1 Recording Criminal Evidence 3.6.2 Enhancing Situational Awareness & Assets Coordination 3.6.3 Identifying Suspects & Traffic Violators 3.6.4 Monitoring Biophysical Activity for First Responders 3.6.5 Enhancing Fire Fighting Capabilities 3.6.6 Improving Response to Medical Emergencies 3.7 Other Verticals 3.7.1 Construction Industry 3.7.2 Mining Industry 3.7.3 Manufacturing Operations 3.7.4 Logistics & Supply Chain 3.7.5 Financial Services 3.7.6 Security & Authentication 3.7.7 Repair, Inspection & Field Services 3.7.8 Education 3.8 Case Studies 3.8.1 Virgin Atlantic: Improving Airline Customer Services with Wearable Te= chnology 3.8.1.1 Solution & Vendors 3.8.1.2 Applications 3.8.1.3 Feedback from the Field 3.8.2 U.S. Department of Defense: Delivering Tactical Information with Wear= able Technology 3.8.2.1 Solution & Vendors 3.8.2.2 Applications 3.8.2.3 Feedback from the Field 3.8.3 Dubai Police: Catching Speeding Drivers with Google Glass 3.8.3.1 Solution & Vendors 3.8.3.2 Applications 3.8.3.3 Feedback from the Field 3.8.4 Disney: Theme Park Management with Wearable Technology 3.8.4.1 Solution & Vendors 3.8.4.2 Applications 3.8.4.3 Feedback from the Field 3.8.5 AT&T: Connected Healthcare Monitoring for the Elderly 3.8.5.1 Solution & Vendors 3.8.5.2 Applications 3.8.5.3 Feedback from the Field =20 Chapter 4: Industry Roadmap & Value Chain 4.1 Wearable Technology Industry Roadmap 4.1.1 2013 =96 2014: Initial Hype & the Revival of Smart Watches 4.1.2 2015 =96 2016: Convergence of Wrist Worn Wearables 4.1.3 2017 =96 2020 & Beyond: The Augmented Reality & Smart Glasses Era 4.2 The Wearable Technology Value Chain 4.2.1 Wearable Device OEM Ecosystem 4.2.1.1 Vertical Centric OEMs 4.2.1.2 Smartphone, Tablet & Consumer Electronics OEMs 4.2.1.3 Fashion & Watch OEMs 4.2.2 Consumers & Vertical Enterprises 4.2.3 Wireless Carriers & the Connectivity Ecosystem 4.2.4 Applications Ecosystem =20 Chapter 5: Market Analysis & Forecasts 5.1 Global Outlook of Wearable Technology 5.2 Form Factor Segmentation 5.3 Smart Bands 5.4 Smart Watches 5.5 Smart Glasses 5.6 Smart Clothing 5.7 Smart Jewelry 5.8 Heads-up Display Systems 5.9 Others 5.10 Vertical Market Segmentation 5.11 Consumer Wearable Devices 5.12 Healthcare Wearable Devices 5.13 Professional Sports Wearable Devices 5.14 Retail & Hospitality Wearable Devices 5.15 Military Wearable Devices 5.16 Public Safety Wearable Devices 5.17 Wearable Devices in Other Verticals 5.18 Regional Market Segmentation 5.19 Asia Pacific 5.20 North America 5.20.1 Canada 5.20.2 USA 5.21 Western Europe 5.22 Eastern Europe 5.23 Middle East & Africa 5.24 Latin & Central America =20 Chapter 6: Key Market Players 6.1 270 Vision 6.2 3L Labs 6.3 4DForce 6.4 4iii Innovations 6.5 9Solutions 6.6 Abbot Laboratories 6.7 Active Mind Technology 6.8 AcousticSheep 6.9 Adidas 6.10 AirType 6.11 Amazon 6.12 Ambit Networks 6.13 AMD (Advanced Micro Devices) 6.14 Amiigo 6.15 Amulyte 6.16 Apple 6.17 ARA (Applied Research Associates) 6.18 Archos 6.19 ARM Holdings 6.20 ASUS (ASUSTeK Computer) 6.21 Atellani 6.22 Atheer Labs 6.23 Atlas Wearables 6.24 Augmendix 6.25 Avegant 6.26 AVG 6.27 Baidu 6.28 BAE Systems 6.29 Basis Science 6.30 Beddit 6.31 Behavioral Technology Group 6.32 BIA Sport 6.33 Bionym 6.34 Biosensics 6.35 BIT (Blue Infusion Technologies) 6.36 Bitbanger Labs 6.37 BI (GEO Group) 6.38 Blocks Wearables 6.39 bOMDIC 6.40 Bondara (Nagook) 6.41 Boston Scientific Corporation 6.42 BRAGI 6.43 Brilliantservice 6.44 Broadcom 6.45 Breitling 6.46 Brother Industries 6.47 BSX Atheletics 6.48 BTS Bioengineering 6.49 Buhel 6.50 Cambridge Temperature Concepts 6.51 Carre Technologies 6.52 Casio 6.53 Catapult Sports 6.54 Citizen 6.55 Cityzen Sciences 6.56 Codoon 6.57 CommandWear 6.58 CompeGPS 6.59 ConnecteDevice 6.60 Connect America 6.61 Control VR 6.62 Cool Shirt Systems 6.63 Creoir 6.64 CSR 6.65 Cuff 6.66 Cyberdyne 6.67 DAQRI 6.68 Dell 6.69 DK Tek Innovations 6.70 DorsaVi (ASX) 6.71 Dreamtrap Commercials 6.72 EB Sport Group 6.73 EdanSafe 6.74 Ekso Bionics 6.75 Electric Foxy 6.76 Emotiv Systems 6.77 Enjoy S.R.L 6.78 Epson (Seiko Epson Corporation) 6.79 Everfind 6.80 EuroTech 6.81 Evena Medical 6.82 Exelis 6.83 EyeTap 6.84 FashionTEQ 6.85 Fat Shark 6.86 Fatigue Science 6.87 Filip Technologies 6.88 Finis 6.89 FitBark 6.90 Fitbit 6.91 Fitbug 6.92 FitLinxx 6.93 Flyfit 6.94 Flextronics 6.95 Force Impact Technologies 6.96 Fossil 6.97 Foxtel 6.98 Freescale Semiconductor 6.99 Free Wavz 6.100 Fujitsu 6.101 Garmin 6.102 GEAK (Shanda Group) 6.103 Gemalto 6.104 General Dynamics Mission Systems 6.105 GestureLogic 6.106 Geopalz 6.107 Ginger.io 6.108 GlassUp 6.109 Glofaster 6.110 GN Store Nord 6.111 GoPro 6.112 Google 6.113 GOQii 6.114 Gucci 6.115 Guess 6.116 HealBe 6.117 HereO 6.118 Hollywog 6.119 Honeywell International 6.120 Hovding 6.121 House of Horology 6.122 HP 6.123 HTC 6.124 Huawei 6.125 i4C Innovations 6.126 i.am+ 6.127 ICEdot 6.128 ICON Health and Fitness 6.129 iHealth Lab 6.130 iLOC Technologies 6.131 i=92m SpA 6.132 Imagination Technologies 6.133 Imec 6.134 Immerz 6.135 Ineda Systems 6.136 Innovega 6.137 InfinitEye 6.138 Intel Corporation 6.139 InteraXon 6.140 InvenSense 6.141 Iotera 6.142 iRhythm 6.143 Instabeat 6.144 Iron Will Innovations 6.145 Jawbone 6.146 Jaybird 6.147 Johnson & Johnson 6.148 Kairos Watches 6.149 Kapture 6.150 Ki Performance 6.151 Kiwi Wearable Technologies 6.152 KMS Solutions 6.153 KoruLab 6.154 Kreyos 6.155 Kronoz 6.156 L-3 Communications 6.157 Lark Technologies 6.158 Laster Technologies 6.159 LeapFrog Enterprises 6.160 Lechal 6.161 LG Electronics 6.162 LifeBEAM 6.163 LifeLogger Technologies Corporation 6.164 Limmex 6.165 Liquid Image 6.166 Lockheed Martin 6.167 LogBar 6.168 LOSTnFOUND 6.169 Lumafit 6.170 Lumo BodyTech 6.171 Lumus 6.172 Luxottica 6.173 Mad Apparel 6.174 Magellan (MiTAC Digital Corporation) 6.175 Martian Watches 6.176 Matilde 6.177 MC10 6.178 McLear 6.179 MediaTek 6.180 Medtronic 6.181 Melon 6.182 META 6.183 Meta Watch 6.184 Microsoft 6.185 MindStream 6.186 Mio Global 6.187 Misfit Wearables 6.188 Moff 6.189 MonDevices 6.190 Moov 6.191 Moticon 6.192 Motion Fitness 6.193 Motorola Mobility/Lenovo 6.194 Motorola Solutions 6.195 Movable 6.196 Mozilla Corporation 6.197 Mutalink 6.198 Mutewatch 6.199 Myontec 6.200 Narrative 6.201 Neptune 6.202 Netatmo 6.203 NeuroPro 6.204 NeuroSky 6.205 New Balance 6.206 Nike 6.207 Nintendo 6.208 Nissan 6.209 Nixie Labs 6.210 Nixon 6.211 Nod 6.212 Notch Interfaces 6.213 NTT DoCoMo 6.214 Nuance 6.215 Nuubo 6.216 NVIDIA 6.217 NZN Labs 6.218 O-Synce 6.219 Oculus VR (Facebook) 6.220 ODG (Osterhout Design Group) 6.221 Olive Labs 6.222 Omate 6.223 OMG Life 6.224 Omron 6.225 OMsignal 6.226 Opening Ceremony 6.227 Optalert 6.228 Optinvent 6.229 OrCam Technologies 6.230 OriginGPS 6.231 Orion Labs (OnBeep) 6.232 Orpyx Medical Technologies 6.233 Owlet Baby Care 6.234 Panasonic 6.235 Pebble 6.236 Perceptive Devices 6.237 Performance Sports Group 6.238 Perpetua Power Source Technologies 6.239 PFO Tech 6.240 PHTL (PH Technical Labs) 6.241 Pivothead 6.242 Pixie Scientific 6.243 Phyode 6.244 Plantronics 6.245 Playtabase 6.246 PNI Sensor Corporation 6.247 Polar Electro 6.248 Pragmasystems 6.249 Preventice 6.250 Proteus Digital Health 6.251 PUSH Design Solutions 6.252 Qardio 6.253 Qualcomm 6.254 Ralph Lauren Corporation 6.255 Raytheon 6.256 Razer 6.257 Recon Instruments 6.258 Reebok International 6.259 Rest Devices 6.260 Revolutionary Tracker 6.261 RHLvision Technologies 6.262 Ringblingz 6.263 Ringly 6.264 RSL Steeper Group 6.265 Rufus Labs 6.266 S3 ID 6.267 Salesforce.com 6.268 Salutron 6.269 Samsung Electronics 6.270 Sarvint Technologies 6.271 Secret Labs 6.272 Seiko 6.273 SenseCore 6.274 Sensegiz Technologies 6.275 Sensible Baby 6.276 Sensoplex 6.277 Sensoria 6.278 Senso Solutions 6.279 Sentimoto 6.280 Seraphim Sense 6.281 Shimmer 6.282 ShotTracker 6.283 Si14 6.284 Sigmo 6.285 Skully Systems 6.286 Smart Device (SmartQ) 6.287 Smarty Destination Technology 6.288 Smarty Ring 6.289 SMI (SensoMotoric Instruments) 6.290 SMS Audio 6.291 Snaptracs 6.292 Somaxis 6.293 Sonitus Medical 6.294 Sonostar 6.295 Sony Mobile Communications 6.296 Sotera Wireless 6.297 Soundbrenner 6.298 SparkPeople 6.299 Spire 6.300 Sports Beat 6.301 SpotNSave 6.302 Spree Wearables 6.303 Sproutling 6.304 Sqord 6.305 Stalker Radar (Applied Concepts) 6.306 STATSports 6.307 Striiv 6.308 STMicroelectronics 6.309 SunFriend Corporation 6.310 Suunto 6.311 sWaP 6.312 Swatch Group 6.313 T.Ware 6.314 Tag Heuer 6.315 Tarsier 6.316 TASER International 6.317 TCL Communication 6.318 Technical Illusions 6.319 Thalmic Labs 6.320 Theatro 6.321 TI (Texas Instruments) 6.322 Timex Group 6.323 TLink Golf 6.324 TN Games 6.325 Tobii Technology 6.326 TomTom 6.327 Tomoon Technology 6.328 Touch Bionics 6.329 TrackingPoint 6.330 Two Tin Cans 6.331 U-blox 6.332 Under Armour 6.333 Uno 6.334 Valencell 6.335 Validic (Motivation Science) 6.336 Vancive Medical Technologies (Avery Dennison) 6.337 Vergence Labs 6.338 Victoria=92s Secret 6.339 Vigo 6.340 VSN Mobil 6.341 Vuzix 6.342 Wahoo Fitness 6.343 Wather Enterprises 6.344 We:eX (Wearable Experiments) 6.345 Wearable Intelligence 6.346 Weartrons Labs 6.347 Wellograph 6.348 Whistle 6.349 Withings 6.350 WTS (Wonder Technology Solutions) 6.351 X-Doria (Doria International) 6.352 Xensr 6.353 Xiaomi 6.354 XO Eye Technologies 6.355 XOWi 6.356 Xybermind 6.357 Yingqu Technology 6.358 Zackees 6.359 Zeiss (Carl Zeiss AG) 6.360 Zephyr Technology (Covidien) 6.361 Zepp Labs 6.362 Zinc Software 6.363 Zoll Medical Corporation 6.364 ZTE =20 Chapter 7: Conclusion & Strategic Recommendations 7.1 Wearable Technology Operating Systems: Is there a Dominant Market Leade= r=3F 7.2 LTE Direct & its Impact on Wearable Technology 7.3 How is Wearable Technology Affecting the Wireless Chipsets Ecosystem=3F 7.4 How Big is the Wearable Applications Ecosystem=3F 7.5 Prospects of Standardization & Regulation 7.6 Prospects of Smartphone OEMs in the Wearable Technology Ecosystem 7.7 Wireless Carriers: The Wearable Service Revenue Opportunity 7.8 Vendor Share: Who Leads the Market=3F 7.9 The Rise of Wearable Startups 7.10 Combining Fashion with Technology 7.11 Prospects of Fitness & Sports Centric Wearables 7.12 Recommendations 7.12.1 Enabling Technology Providers 7.12.2 Wearable Device OEMs & Vertical Players 7.12.3 Wearable Application Developers 7.12.4 Wireless Carriers =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@snscommunication.com =20 =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com From owner-freebsd-ppc@freebsd.org Wed Sep 14 07:57:59 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 0AEF9BDA65B for ; Wed, 14 Sep 2016 07:57:59 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 6EBD1202; Wed, 14 Sep 2016 07:57:58 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id u14so4161403lfd.1; Wed, 14 Sep 2016 00:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=p9mLFkkVrOR0mgIh+PHweeTGrGDTMKQOl5iabKmt8nY=; b=HS6DwMc1cs5fqeOhj6RFp0QywYjW2EA3dWH5om+ZExTqftL5Z4SqmkzOy+9Z5/XY3N HwcXV2/yairAhC896aS4wPrXill7hUkFCAEm6zjlSuqcAeTct5jSHiMkQtkTVgsxsTqA AJM5w7TbfX9jljHAwbcHINBhHn26kQYjb1xz3AsbnLWJJpkGXlbOjxlw33ypcZMfplNN BlvgG/j6PvCW0ZoO/iW3m46TFTil+pUXOCDalmC3/Uq0t6XWYD0s5IaSazMfs0aOfcMt jBGnTyshMSCurBrxiArr9ud9h7O510ZD31xwhXZAjTpKHH39MS5lwE29PHD3fQfywDbi F9iQ== 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:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=p9mLFkkVrOR0mgIh+PHweeTGrGDTMKQOl5iabKmt8nY=; b=OEKbFqJ5VRJPQfQioIi6+ZA4MQ+fu35+qsFMlLELH7CNOS4fJiPzAafpLCCmuDNHKP sfBXWQApkoCgJVhG0Bi50fXOOXTy7UYjmHenntfnjJfQAxWlbrzg/03k6BUi8wvu9OtN m5SKt6KhlpWgATCdUW5wt9sjg8cjYyNZtncdUfwPg+HfUD82FZto0GM/s5emGhbKSTfn 2w4w5sT+VgvZKeItXgiZuBHYPvjTfEL5y2MuBxvGDt/DG0BKn2pp2kiICUHVpaty3n8Q 0Y10JCQ/feXwzszAdoAvwumsQn9/NtsySkj3ww+OO4KHc62zrg1Cuqgudq2o33cthAri I9pg== X-Gm-Message-State: AE9vXwNnx5c95u61MP1VX7RT3mRp9K3dl+etIVIIM9odnhPOD6iE6T204MVEND4+NKUAfA== X-Received: by 10.25.74.207 with SMTP id x198mr514707lfa.12.1473839876128; Wed, 14 Sep 2016 00:57:56 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id h41sm535175lji.28.2016.09.14.00.57.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Sep 2016 00:57:55 -0700 (PDT) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: freebsd-ppc@freebsd.org References: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> From: "Jukka A. Ukkonen" Message-ID: <521c75a2-9223-88c9-93cd-e091890003e1@gmail.com> Date: Wed, 14 Sep 2016 10:57:54 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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, 14 Sep 2016 07:57:59 -0000 On 09/13/16 20:28, Nathan Whitehorn wrote: > Maybe firmware needs SPRG1-3 restored? Any chance you could try deleting > the mtsprg1-3 one-by-one? > -Nathan But of course. It will take some time, though. Is there any particular order I should try them? 1, 2, and 3? I mean you and Mark obviously have a lot better understanding about ppc and what to expect when one touches sprg#. I will be flying pretty much blindfolded. --jau From owner-freebsd-ppc@freebsd.org Wed Sep 14 14:27:37 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 1F1C6BDA8ED for ; Wed, 14 Sep 2016 14:27:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0ABF11CAA for ; Wed, 14 Sep 2016 14:27:36 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u8EEHP9U014043 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Sep 2016 07:17:26 -0700 Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: "Jukka A. Ukkonen" , freebsd-ppc@freebsd.org References: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> <521c75a2-9223-88c9-93cd-e091890003e1@gmail.com> From: Nathan Whitehorn Message-ID: <8a4035e9-19e4-89c4-364f-8914a703eea2@freebsd.org> Date: Wed, 14 Sep 2016 07:17:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <521c75a2-9223-88c9-93cd-e091890003e1@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZlkgKLyJzVHYVUiBhehnche2igbVqbXQw6/lGsNTFVzydxwPXhTxHsInvAZk71LEmsPG6RMLKRl8IGpi6HLIAFtJfVJCoOQMA= X-Sonic-ID: C;pCob9oV65hGcuqDx2xNB0g== M;/pxx9oV65hGcuqDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 14 Sep 2016 14:27:37 -0000 On 09/14/16 00:57, Jukka A. Ukkonen wrote: > On 09/13/16 20:28, Nathan Whitehorn wrote: >> Maybe firmware needs SPRG1-3 restored? Any chance you could try deleting >> the mtsprg1-3 one-by-one? >> -Nathan > But of course. It will take some time, though. > Is there any particular order I should try them? > 1, 2, and 3? > I mean you and Mark obviously have a lot better > understanding about ppc and what to expect when > one touches sprg#. I will be flying pretty much > blindfolded. > > --jau > I'm flying blind here too. It's one of SPRG1 or SPRG3 that I expect firmware needs restored on your system. SPRG2 is obliterated by the SLB fault handler, so if firmware needs it, we can't provide it anyway. And we know it doesn't need SPRG0 since Mark's patch works for you. -Nathan From owner-freebsd-ppc@freebsd.org Wed Sep 14 21:06:23 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 F38D3BDBD2A for ; Wed, 14 Sep 2016 21:06:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DC8B019CA for ; Wed, 14 Sep 2016 21:06:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id DC0CA133E; Wed, 14 Sep 2016 21:06:23 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by freefall.freebsd.org (Postfix) with ESMTP id DB830133D for ; Wed, 14 Sep 2016 21:06:23 +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 C862719C9 for ; Wed, 14 Sep 2016 21:06:23 +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 u8EL6NV4063362 for ; Wed, 14 Sep 2016 21:06:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 212667] [PATCH] machdep.c: check DDB_ENABLED before defining SPR/db_show_table Date: Wed, 14 Sep 2016 21:06:23 +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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhibbits@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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: Wed, 14 Sep 2016 21:06:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212667 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Assignee|freebsd-powerpc@FreeBSD.org |jhibbits@FreeBSD.org --- Comment #1 from Justin Hibbits --- Take. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Sep 16 15:36:05 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 58C0CBDD795 for ; Fri, 16 Sep 2016 15:36:05 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 CA5E3E94; Fri, 16 Sep 2016 15:36:04 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id s64so5172031lfs.2; Fri, 16 Sep 2016 08:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=DPKkjvdnLq1lxLjcPTNMcxJrZ2s0LYgk8YpJbZ6xXjY=; b=R9jxeTkZdD7B5QWExkjBNXL+IS2G6xsRsTWj4DOIU/it+dMLqbdd6F3OfvIc/arV65 1jgjclink4rG/SEd7iiUdVqijMaCrvGqaTmsnRxy0NT2AagqYjclE5WfYI7ohg4aKQhT +nz/AlentVOo9M5UMZfF3MmKy3+vo2/utDYrrBGfXLoEVrIvEt/K3vOCCyEV5zXJlt7q /MHAIqPvYN06JhsD5GcbGuP2rRxQ5Tih5cycspmK8pDxW07da3VjvEBiqdxN5yfOojwB YrO5vxXc7QpD175l394/0MW+6ejHwhHzO6OUG2D2fz2V4YgwWMt3f6CWKY0uKKUqt60a Bxrg== 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DPKkjvdnLq1lxLjcPTNMcxJrZ2s0LYgk8YpJbZ6xXjY=; b=aQFFw2jdwB8/kjXC+uWKOTU3KdXQJmtqQ23OZUQs9V7rBwDdQtXJJetsCcKpaZH8XO 3hn5RW1kyZR4ZUU5FMB3YHfZr3pFT4rVc3FP3QlomvdLCHaakXmwE7JDzWfsdU/Q29r2 viKQpq0t9PT6WyWOgPsNHLEdOOckLrV/DBXPZ3/EhTDvJNs3/pyYuyHrEnsW0BowXz5q TvsKdAEeefHQRuof6Ooft2IrEBaycujRlvrGTB9zGZ7EXY9vIUE2cEbhCF4XuTxrF9hM oV0sLkbTnTSRA+xECIc8HLxVrcPzPLqwWd7ludp5JIeltTKQ+xadvxsFzWqgGNp6EvZl c7Pg== X-Gm-Message-State: AE9vXwNaZQ0nHLKziqWtmTZQ0yOk6a1+iiFjy7CNPI+LZtHWIHLVMmN3aonVq432eSy8pg== X-Received: by 10.25.210.205 with SMTP id j196mr6562126lfg.139.1474040162627; Fri, 16 Sep 2016 08:36:02 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id 137sm2394868ljj.47.2016.09.16.08.36.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 08:36:01 -0700 (PDT) Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) To: Nathan Whitehorn , freebsd-ppc@freebsd.org References: <3c513eea-cd94-7065-87b8-5200490b97c3@gmail.com> <521c75a2-9223-88c9-93cd-e091890003e1@gmail.com> <8a4035e9-19e4-89c4-364f-8914a703eea2@freebsd.org> From: "Jukka A. Ukkonen" Message-ID: Date: Fri, 16 Sep 2016 18:36:00 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <8a4035e9-19e4-89c4-364f-8914a703eea2@freebsd.org> Content-Type: multipart/mixed; boundary="------------D0B50E7E8E81236165F464C6" 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, 16 Sep 2016 15:36:05 -0000 This is a multi-part message in MIME format. --------------D0B50E7E8E81236165F464C6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 09/14/16 17:17, Nathan Whitehorn wrote: > > On 09/14/16 00:57, Jukka A. Ukkonen wrote: >> On 09/13/16 20:28, Nathan Whitehorn wrote: >>> Maybe firmware needs SPRG1-3 restored? Any chance you could try deleting >>> the mtsprg1-3 one-by-one? >>> -Nathan >> But of course. It will take some time, though. >> Is there any particular order I should try them? >> 1, 2, and 3? >> I mean you and Mark obviously have a lot better >> understanding about ppc and what to expect when >> one touches sprg#. I will be flying pretty much >> blindfolded. >> >> --jau >> > > I'm flying blind here too. It's one of SPRG1 or SPRG3 that I expect > firmware needs restored on your system. SPRG2 is obliterated by the SLB > fault handler, so if firmware needs it, we can't provide it anyway. And > we know it doesn't need SPRG0 since Mark's patch works for you. > -Nathan Right, it seems my PowerMac G5 is perfectly happy with this... __asm __volatile("mfsprg0 %0\n\t" : "=&r"(ofw_sprg0_save) : ); This does not seem all unexpected when I read the hardware specification for these registers. See the attachment. In case OFW does some extra magic with these registers, I might be running a fault prone setup at the moment, but for now there have been no symptoms of anything going seriously wrong. --jau --------------D0B50E7E8E81236165F464C6 Content-Type: text/plain; charset=UTF-8; name="ppc32-ppc64-sprg-registers.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ppc32-ppc64-sprg-registers.txt" SPRG0 - SPRG3 are 64-bit or 32-bit registers, depending on the type of PowerPC processor. They are provided for general operating system use, such as performing a fast state save or for supporting multiprocessor implementations Table 2-19. Conventional Uses of SPRG0 - SPRG3 Register Description SPRG0 Software may load a unique physical address in this register to identify an area of memory reserved for use by the first-level exception handler. This area must be unique for each processor in the system. SPRG1 This register may be used as a scratch register by the first-level exception handler to save the content of a GPR. That GPR then can be loaded from SPRG0 and used as a base register to save other GPRs to memory. SPRG2 This register may be used by the operating system as needed. SPRG3 This register may be used by the operating system as needed. --------------D0B50E7E8E81236165F464C6-- From owner-freebsd-ppc@freebsd.org Sat Sep 17 01:41:17 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 2CB2ABDD92D for ; Sat, 17 Sep 2016 01:41:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (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 D6AC7EB3 for ; Sat, 17 Sep 2016 01:41:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3350 invoked from network); 16 Sep 2016 21:42:01 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Sep 2016 21:42:01 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Fri, 16 Sep 2016 17:41:19 -0400 (EDT) Received: (qmail 29933 invoked from network); 16 Sep 2016 21:41:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Sep 2016 21:41:19 -0000 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id CD308EC7B69; Fri, 16 Sep 2016 14:41:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Message-Id: <0F078304-8E8F-4EB1-B721-B6C4B885F118@dsl-only.net> Date: Fri, 16 Sep 2016 14:41:13 -0700 To: FreeBSD PowerPC ML , jau789@gmail.com Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: Sat, 17 Sep 2016 01:41:17 -0000 Jukka A. Ukkonen jau789 at gmail.com wrote on Fri Sep 16 15:36:05 UTC = 2016 : > it seems my PowerMac G5 is perfectly happy with this... >=20 > __asm __volatile("mfsprg0 %0\n\t" > : "=3D&r"(ofw_sprg0_save) > : > ); for the content in ofw_sprg_prepare(void). Interestingly ofw_sprg0_save's use to save and restore requires that the = same processor be in use in the restore side, ofw_sprg_restore(void): = SPRG0 content is processor specific. If the sprg0 save-restore is even required is not obvious to me: being = required would imply that that something else is adjusting it between = the save and restore code executions. The following is just in the form of another simplest-local-changes = experiment/analysis pass, not a "how it should be coded for general = FreeBSD use" form for __powerpc64__ or at least for for = PowerMac/iMac/Xserve G5's specifically. . . Given what is reported above by Jukka it would appear that the above = __asm lines possibly could be removed/disabled if ofw_sprg_restore(void) = also had its __asm line removed/disabled: i.e., __asm __volatile("mtsprg0 %0" :: "r"(ofw_sprg0_save)); would no log be in use to access ofw_sprg0_save. Effectively overall for the intended __powerpc64__ = PowerMac(/iMac?/Xserver?) experimental context ofw_sprg_prepare and = ofw_sprg_restore are then no-ops. In effect ofw_sprg0_save and ofmsr[1] to ofmsr[4] would not be in = significant use. But. . . OF_initial_setup(void *fdt_ptr, void *junk, int (*openfirm)(void *)) still would have __asm references to ofmsr[1] through ofmsr[4] where = they are initialized. You might want to try deleting/disabling the __asm statements in = ofw_sprg_prepare(void) and in ofw_sprg_restore(void) at the same time to = see if it makes any difference. If it does make a difference that would = be interesting and important. Otherwise it helps identify some more = (PowerMac/. . . context specific) unnecessary code. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Sep 17 14:22:44 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 0BB55BDE86F for ; Sat, 17 Sep 2016 14:22:44 +0000 (UTC) (envelope-from rleigh@codelibre.net) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [81.187.30.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1AEBA0E for ; Sat, 17 Sep 2016 14:22:43 +0000 (UTC) (envelope-from rleigh@codelibre.net) Received: from 7.5.2.1.f.5.e.f.f.f.c.4.4.a.2.6.d.b.d.d.0.6.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:860:ddbd:62a4:4cff:fe5f:1257]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1blGGa-0003dA-JG for freebsd-ppc@freebsd.org; Sat, 17 Sep 2016 15:06:52 +0100 To: FreeBSD PowerPC ML From: Roger Leigh Subject: Booting 11-stable problem on a G4 mac mini Message-ID: <252659f3-6000-d019-283a-5538bff8a3da@codelibre.net> Date: Sat, 17 Sep 2016 15:06:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 17 Sep 2016 14:22:44 -0000 Hi folks, I had a working 10.3 build from back in April. I yesterday tried building and booting 11.0-stable. It built and installed fine, but has problems booting. http://filebin.ca/2vOPzgQr4mEZ/IMG_4058.JPG Basically it gets to gem0: 10kB RX addr...... gem0: Ethernet address ....... cryptosoft0: on nexus0 and then just stops and doesn't make any further visible progress. I left it a few hours in case it was generating keys or something but to no effect. I think it's spinning its wheels doing *something* because the fan is on and it's putting some heat out, but I can't do much at this point since the keyboard isn't even operable. If anyone has any ideas, I'd be very grateful. Thanks, Roger From owner-freebsd-ppc@freebsd.org Sat Sep 17 23:39: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 502EABDFFDD for ; Sat, 17 Sep 2016 23:39:47 +0000 (UTC) (envelope-from rleigh@codelibre.net) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [81.187.30.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 181821E69 for ; Sat, 17 Sep 2016 23:39:46 +0000 (UTC) (envelope-from rleigh@codelibre.net) Received: from b.2.4.6.1.1.d.9.9.e.2.c.8.7.5.5.d.b.d.d.0.6.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:860:ddbd:5578:c2e9:9d11:642b]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1blPCw-0001ao-Pp for freebsd-ppc@freebsd.org; Sun, 18 Sep 2016 00:39:42 +0100 To: FreeBSD PowerPC ML From: Roger Leigh Subject: Installer problems with 11.0-RC3 Message-ID: <725c6225-c7bf-f88f-d8e2-b5f9a02bcfe8@codelibre.net> Date: Sat, 17 Sep 2016 23:39:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 17 Sep 2016 23:39:47 -0000 Up until now, my G4 Mac Mini has been running 10.3-RELEASE. Today, I tried the 11.0-RC3 installer. Two issues noted: 1) The colours in the installer are different than the PC installer. The background is a mid brown with yellow text. An issue with the console framebuffer? 2) It won't boot after the installer finished. It errors out while loading the loader: ofw_close devh=0x0 >> FreeBSD/powerpc Open Firmware boot block Bootpath: /pcie@f4000000/ata-6@d/disk@0: Boot loader: /boot/loader Invalid memory access at %SRR0: 018011f0 %SRR1: 00003030 and then drops to an interactive OF prompt. Has anyone seen this before? Regards, Roger From owner-freebsd-ppc@freebsd.org Sat Sep 17 23:47:44 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 4B622BDE145 for ; Sat, 17 Sep 2016 23:47:44 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 0962F181 for ; Sat, 17 Sep 2016 23:47:44 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id o3so41730061ita.1 for ; Sat, 17 Sep 2016 16:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FBmAiXxN7JeynXxWUF+yn77StsVurGgl2FzJHMZE5Yw=; b=JgXHyJF4XfPLlID+lGsz11/KaWMj56EHtED1s3NAwdG9xrOviYzpnonlU4I0B/qa80 +GVZ0XKeYDQYyp+g3focnKCuqrOF7neMp8tGa/q1owLfw51l8WE0d4oXBKjbD0mS4IAz aj8v/9VTAccUbYQBgwpKQf+JDN7Kkj4z98Lk56tct4goQpe/SA9fRfgEqgw2gnnwq5wK sPYGLam6oefcTY9DKnwQTpDn5/bQhqMb9vuNlhtNxWEIYwi5Ys/D4ccap2vWsMJ3QBPa C7S0Q8RQkWV39QTXyTnwQ6B0/iuW0lynmx1TLmqnU0mIcZlcQbJmXWFHmq4djIBLEacF OdoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FBmAiXxN7JeynXxWUF+yn77StsVurGgl2FzJHMZE5Yw=; b=IwafqwWxCIP/Hp1cU6VxpcJKLBtwndnaZ+njBnAjcHxJkX4T+UYNXxxr6RW3HCaoVO k/z3tjtDhl7rzoRm95AA+VqOf9RDaaSxI1m4pDmS9AhH6bkOIxqByLn9pwBrkmNk6IfT e9whZiRaRpQMRyR6o8uH2gCtgLNJVuFRvLMlF+JoNUsO+MTof20mpL8VB77UUwTY47pB ElbzuGzuoeK0Bsbze18VnTPkYFzM6LX6FzMZQEJ2bduMDfB3au9JwZ56f1DgQUyVUe20 ciL4AQaiY29OvGLNXtEeX8debCkwyfwSwKvYOoipl6zQN6BxlujwoxZ/Z0zFLPu2YURw P5+Q== X-Gm-Message-State: AE9vXwPgX9mkK0jC5BaTaw+YJDHLnqPePSHZxqD0hk7N/xwEmeJJ4qs4DTl8rMnNTI2jiQ== X-Received: by 10.36.39.195 with SMTP id g186mr3889479ita.53.1474156063512; Sat, 17 Sep 2016 16:47:43 -0700 (PDT) Received: from zhabar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id c30sm6279744iod.42.2016.09.17.16.47.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 17 Sep 2016 16:47:42 -0700 (PDT) Date: Sat, 17 Sep 2016 18:46:49 -0500 From: Justin Hibbits To: Roger Leigh Cc: FreeBSD PowerPC ML Subject: Re: Installer problems with 11.0-RC3 Message-ID: <20160917184649.35d9a9ab@zhabar.knownspace> In-Reply-To: <725c6225-c7bf-f88f-d8e2-b5f9a02bcfe8@codelibre.net> References: <725c6225-c7bf-f88f-d8e2-b5f9a02bcfe8@codelibre.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Sat, 17 Sep 2016 23:47:44 -0000 On Sat, 17 Sep 2016 23:39:41 +0000 Roger Leigh wrote: > Up until now, my G4 Mac Mini has been running 10.3-RELEASE. Today, I > tried the 11.0-RC3 installer. Two issues noted: > > 1) The colours in the installer are different than the PC installer. > The background is a mid brown with yellow text. An issue with the > console framebuffer? > > 2) It won't boot after the installer finished. It errors out while > loading the loader: > > ofw_close devh=0x0 > > >> FreeBSD/powerpc Open Firmware boot block > Bootpath: /pcie@f4000000/ata-6@d/disk@0: > Boot loader: /boot/loader > > Invalid memory access at %SRR0: 018011f0 %SRR1: 00003030 > > and then drops to an interactive OF prompt. Has anyone seen this > before? > > > Regards, > Roger Hi Roger, I just fixed the second issue, which should be going into the next ISO (RC4? Final? Not sure at this point), but the initial commit was to head at r305894, and finally merged to 11.0 (by way of stable/11) in r305904 if you're curious. Regarding the framebuffer colors, I believe that's a known issue. I know I've run into it. It may be video card specific (ATI vs NVidia), but I'm not sure. - Justin