Date: Sat, 10 Sep 2016 17:12:52 -0700 From: Mark Millard <markmi@dsl-only.net> To: Krzysztof Parzyszek <kristof@swissmail.org> Cc: Jukka Ukkonen <jau789@gmail.com>, freebsd-ppc@freebsd.org Subject: Re: PowerMac G5 hangs/crashes on boot: 10.2, 11.0-RCx Message-ID: <6B075CE8-2AF5-479C-8363-6F5F33A0B62F@dsl-only.net> In-Reply-To: <b39a5ae1-7aa5-a71f-3aff-221fc9c2e4da@swissmail.org> References: <6ad00a2d-4213-18b8-7974-534aa3758837@swissmail.org> <E90BB066-47C9-4626-BE6C-5D15ECA0E4EE@gmail.com> <db0aa91b-aa79-689a-e901-437e18b49b81@swissmail.org> <0A9EB3C7-F430-4F82-9B09-632754BB82C8@dsl-only.net> <b39a5ae1-7aa5-a71f-3aff-221fc9c2e4da@swissmail.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Sep-10, at 1:41 PM, Krzysztof Parzyszek <kristof at = swissmail.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B075CE8-2AF5-479C-8363-6F5F33A0B62F>