Date: Tue, 15 Nov 2016 14:04:47 +0200 From: Jukka Ukkonen <jau789@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: Nathan Whitehorn <nwhitehorn@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Peter Grehan <grehan@freebsd.org> Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] Message-ID: <5C253E59-265B-4F5F-A4C5-E4FB7EEBF084@gmail.com> In-Reply-To: <B28E3336-2F85-4395-8DDF-CF09CA9D41E1@dsl-only.net> References: <C48933C3-DB22-4D94-B22D-B51822197E4E@dsl-only.net> <917EFF5A-D054-4424-9D7D-4E4BEF6072EF@gmail.com> <4bb1046a-225d-66b2-7b00-067f0d6f6c60@gmail.com> <465041D5-C1A2-48F4-9CA7-DD03B094FAE4@dsl-only.net> <01cfa4e9-954f-3e86-c8d7-36ec8523dde0@freebsd.org> <B28E3336-2F85-4395-8DDF-CF09CA9D41E1@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
The bad news is that with this modification my G5 is still prone to panic during the very early phases of booting depending on which kernel modules are preloaded by loader. Some preloaded modules do not cause a panic, but they do not work either until they are unloaded and the loaded again when the kernel is already in control of everything. Preloaded modules end up in relatively low addresses. The modules loaded under the control of the kernel itself end up in very high addresses. I assume there is some sort of memory corruption which tends to make a mess in the lower addresses and some modules are very sensitive to such corruption causing panics while others are less sensitive and simply refuse to operate normally. I guess this might be related to the initialization of sprg0. IBM's documentation says sprg0 must point to a separate buffer area for each CPU, but I have failed to convince myself that sprg0 actually refers a separate CPU specific buffer space for each CPU at all times when ofw is called. The old values of the sprg# registers and something else get apparently stored in the buffer pointed by sprg0. --jau > On 15 Nov 2016, at 7.53, Mark Millard <markmi@dsl-only.net> wrote: > > On 2016-Sep-21, at 3:01 PM, Peter Grehan <grehan at freebsd.org> wrote: > >>> I've never had my hands on an eMac. I'm not sure if it has the same >>> SPRGx requirements as other G4's or not. >> >> That's the machine that caused the sprg save/restore. >> https://svnweb.freebsd.org/base?view=revision&revision=151891 >> >> later, >> >> Peter. > > My patch/hack as I have always had it for booting PowerMac G5's does not > change the content for G4's (such as eMac G4's). I made a separate case > for __powerpc64__ --and only for AIM-capable as well. My code has been: > > # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =================================================================== > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 308247) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -111,6 +111,24 @@ > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > +#if defined(AIM) && defined(__powerpc64__) > +/* HACK: PowerMac G5 specific code to avoid demonstrated hangs in > + * the early boot time frame: avoid mtsprg0 use. > + * This would need a live test for PowerMac vs. not in order > + * to remove HACK status --but without calling into > + * OpenFirmware or the problem would be recreated. > + */ > + if (1) > + __asm __volatile("mfsprg0 %0\n\t" > + "mtsprg1 %1\n\t" > + "mtsprg2 %2\n\t" > + "mtsprg3 %3\n\t" > + : "=&r"(ofw_sprg0_save) > + : "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > + else > +#endif > __asm __volatile("mfsprg0 %0\n\t" > "mtsprg0 %1\n\t" > "mtsprg1 %2\n\t" > > (The comment does not reflect the modern discussion of why the > change works: the code has been around a long time.) > > I do not know if there are any AIM-capable __powerpc64__ > contexts for which the change is inappropriate. It would be > nice if it was always appropriate to that kind of context > and could be added to head and stable/11 and stable/10 . > (I've no experience before stable/10: so untested prior to > that.) > > Jukka did experiments with eliminating more --and not just for > AIM-capable __powerpc64__ but some other PowerMac contexts as > well. > > But I kept to the minimal generated-code change which appeared > to fix the problematical behavior. > > === > Mark Millard > markmi at dsl-only.net >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C253E59-265B-4F5F-A4C5-E4FB7EEBF084>