Date: Fri, 4 Nov 2016 13:08:47 -0700 From: Mark Millard <markmi@dsl-only.net> To: Roger Leigh <rleigh@codelibre.net> Cc: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Installer problems with 11.0-RC3 Message-ID: <2BBD1FF2-BBB2-497D-B133-C6A38AAF42D8@dsl-only.net> In-Reply-To: <CAHSQbTAsy81JjXvJP3FvV7rDebUFEJ1nhWhhL1BF%2BJ_skLth6Q@mail.gmail.com> References: <725c6225-c7bf-f88f-d8e2-b5f9a02bcfe8@codelibre.net> <20160917184649.35d9a9ab@zhabar.knownspace> <88b054f6-ae0b-dc32-8d54-016964a2cea8@codelibre.net> <747f3eaa-251c-5740-0755-09bba55a5b04@codelibre.net> <CAHSQbTAsy81JjXvJP3FvV7rDebUFEJ1nhWhhL1BF%2BJ_skLth6Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Nov-4, at 7:04 AM, Justin Hibbits <chmeeedalf at gmail.com> =
wrote:
> On Wed, Oct 26, 2016 at 2:00 PM, Roger Leigh <rleigh at codelibre.net> =
wrote:
>> On 18/09/2016 09:04, Roger Leigh wrote:
>>>=20
>>> On 17/09/2016 23:46, Justin Hibbits wrote:
>>>>=20
>>>> On Sat, 17 Sep 2016 23:39:41 +0000
>>>> Roger Leigh <rleigh at codelibre.net> wrote:
>>>>=20
>>>>> Up until now, my G4 Mac Mini has been running 10.3-RELEASE. =
Today, I
>>>>> tried the 11.0-RC3 installer. Two issues noted:
>>>>>=20
>>>>> 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?
>>>>>=20
>>>>> 2) It won't boot after the installer finished.
>>>>> Invalid memory access at %SRR0: 018011f0 %SRR1: 00003030
>>>>=20
>>>>=20
>>>> 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.
>>>=20
>>>=20
>>> Super, thanks. I'll retry this with the next ISO release.
>>=20
>>=20
>> I got the time to retry with the 11.0-RELEASE ISO, and the above =
problem is
>> fixed, but unfortunately then hit a problem I'd previously seen and =
posted
>> on the list when testing 11.0-STABLE in mid-September. The kernel =
loads and
>> boots correctly, but it hangs at this point:
>>=20
>> gem0: 10kB RX addr......
>> gem0: Ethernet address .......
>> cryptosoft0: <software crypto> on nexus0
>>=20
>> At this point it just sits there with the CPU fan going full tilt. =
I'm not
>> sure what exactly the problem is here because I have no means to =
debug it
>> that I'm aware of at that point during the boot. Happy to =
investigate
>> further if anyone could provide any hints about what I could do to =
assist.
>>=20
>>=20
>> Regards,
>> Roger
When I was trying to figure how to avoid the PowerMac G5 boot problems =
for
64 bit use I used the technique of ddb automatically executing a script =
when
it started to make it dump out information at early stages were keyboard
input was not available. The dump had to have the useful information fit =
on
the screen --so I used the biggest screen that I could (by pixel count) =
and
also adjusted the script and tried more boots to get more information.
As I remember for the pixel count issue I had to be picky about vt vs. =
sc.
(I build with both available --and PS3 disabled in order to allow both
to be enabled.) This vt vs. sc issue was driven by using the G5's.
(I also did some experiments with 32 bit booting and with G4s and a iMac =
G3.)
A simple "bt" script example from back in those days follows.
> Index: /usr/src/sys/ddb/db_main.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/src/sys/ddb/db_main.c (revision 291745)
> +++ /usr/src/sys/ddb/db_main.c (working copy)
> @@ -46,6 +46,9 @@
> #include <ddb/db_command.h>
> #include <ddb/db_sym.h>
> =20
> +/* HACK: part of dealing with lack of input for early boot time */
> +#include <ddb/db_output.h>
> +
> SYSCTL_NODE(_debug, OID_AUTO, ddb, CTLFLAG_RW, 0, "DDB settings");
> =20
> static dbbe_init_f db_init;
> @@ -230,6 +233,9 @@
> watchpt =3D IS_WATCHPOINT_TRAP(type, code);
> =20
> if (db_stop_at_pc(&bkpt)) {
> + /* HACK: part of early boot handling: no input =
possible */
> + db_disable_pager();
> +
> if (db_inst_count) {
> db_printf("After %d instructions (%d loads, %d =
stores),\n",
> db_inst_count, db_load_count, =
db_store_count);
> Index: /usr/src/sys/ddb/db_script.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/src/sys/ddb/db_script.c (revision 291745)
> +++ /usr/src/sys/ddb/db_script.c (working copy)
> @@ -319,10 +319,26 @@
> {
> char scriptname[DB_MAXSCRIPTNAME];
> =20
> + /* HACK!!! : Additional lines to force a basic default script =
to exist.
> + * Will dump information even if ddb input is not available =
for early crash.
> + * Used to get more information about PowerMac G5 "before =
Copyright" hangs.
> + */
> + struct ddb_script *dsp =3D =
db_script_lookup(DB_SCRIPT_KDBENTER_DEFAULT);
> + if (!dsp) db_script_set(DB_SCRIPT_KDBENTER_DEFAULT,
> + "bt");
> +
> snprintf(scriptname, sizeof(scriptname), "%s.%s",
> DB_SCRIPT_KDBENTER_PREFIX, eventname);
> if (db_script_exec(scriptname, 0) =3D=3D ENOENT)
> (void)db_script_exec(DB_SCRIPT_KDBENTER_DEFAULT, 0);
> +
> + /* HACK!!! : Additional lines to always use the default =
script,
> + * even if scriptname existed and was executed.
> + * Will dump information even if ddb input is not available =
for early crash.
> + * Used to get more information about PowerMac G5 "before =
Copyright" hangs.
> + */
> + else
> + (void)db_script_exec(DB_SCRIPT_KDBENTER_DEFAULT, 0);
> }
> =20
> /*-
I enable DDB in my kernel builds. (I originally enabled GDB as well and
never bothered to turn it off. Probably not needed/not useful for my=20
context.)
> # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
> include GENERIC
> ident GENERICvtsc-NODBG
>=20
> nooptions PS3 #Sony Playstation 3 =
HACK!!! to allow sc
>=20
> options DDB # HACK!!! to dump early crash =
info (but 11.0-CURRENT already has it)
> options GDB # HACK!!! ...
>=20
> # Extra stuff:
> #options VERBOSE_SYSINIT
> #options BOOTVERBOSE=3D1
> #options BOOTHOWTO=3DRB_VERBOSE
> #options KTR
> #options KTR_MASK=3DKTR_TRAP
> #options KTR_CPUMASK=3D0xF
> #options KTR_VERBOSE
>=20
> # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt =
historically mishandled during booting
> device sc
> #device kbdmux # HACK: already listed by vt
> options SC_OFWFB # OFW frame buffer
> options SC_DFLT_FONT # compile font in
> makeoptions SC_DFLT_FONT=3Dcp437
>=20
>=20
> # Disable extra checking typically used for FreeBSD 11.0-CURRENT:
> nooptions DEADLKRES #Enable the deadlock resolver
> nooptions INVARIANTS #Enable calls of extra sanity =
checking
> nooptions INVARIANT_SUPPORT #Extra sanity checks of =
internal structures, required by INVARIANTS
> nooptions WITNESS #Enable checks to detect =
deadlocks and cycles
> nooptions WITNESS_SKIPSPIN #Don't run witness on =
spinlocks for speed
> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
That confirms the pickiness about vt vs. sc at the time for large pixel
count displays: I used sc. And what drove the sc issue was PowerMac G5
specific but I just copied over the material for my G4 experiments: the
same boot media allowed 32 bit PowerMac G5 boot experiments.
Enabling some of the VERBOSE options that I have commented out above
might show output closer to when the hang happens and so give more
context for the problem.
Various other details of the above could be different, it just shows my
choices at the time.
I hand wrote notes or took screen pictures. I used multiple commands in =
the
internal script at times (separated by ";" as I remember).
Unfortunately for CD booting problems this involves building one's own =
ISO's
that has one's own builds and burning them to CDs if that kind of boot =
is
at issue. I was not doing this generally. I did once try a =
/usr/src/release/
based build. As I remember it went okay back then. I do not remember the
details other than the default partition in the file system that it =
built on
ended up nearly full. If it allows such I probably should have =
controlled
where it did the build in order to manage space usage.
> Hi Roger,
>=20
> Unfortunately, I've run into this on my PowerBook G4 since February,
> with no clear idea of what's going on. Since nobody else had reported
> a problem I thought it was just me, so didn't put much effort into it.
> That said, it *should* boot the installed kernel if you start the
> loader from the CD (just 'unload; set currdev=3Dhd:3; boot'), and it
> boots to the hard drive fine then (that's what I've been doing since
> BSDCan). I intend to take a closer look at it at MeetBSD with some
> other folks who might have some insight into at least how to debug it.
>=20
> - Justin
I do not know when I will explore the issues, although I have
access to the old PowerMac's again (at least for a bit).
=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?2BBD1FF2-BBB2-497D-B133-C6A38AAF42D8>