Installer problems with 11.0-RC3
Mark Millard
markmi at dsl-only.net
Fri Nov 4 20:08:50 UTC 2016
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:
>>>
>>> On 17/09/2016 23:46, Justin Hibbits wrote:
>>>>
>>>> On Sat, 17 Sep 2016 23:39:41 +0000
>>>> Roger Leigh <rleigh at codelibre.net> 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.
>>>>> Invalid memory access at %SRR0: 018011f0 %SRR1: 00003030
>>>>
>>>>
>>>> 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.
>>>
>>>
>>> Super, thanks. I'll retry this with the next ISO release.
>>
>>
>> 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:
>>
>> gem0: 10kB RX addr......
>> gem0: Ethernet address .......
>> cryptosoft0: <software crypto> on nexus0
>>
>> 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.
>>
>>
>> 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
> ===================================================================
> --- /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>
>
> +/* 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");
>
> static dbbe_init_f db_init;
> @@ -230,6 +233,9 @@
> watchpt = IS_WATCHPOINT_TRAP(type, code);
>
> 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
> ===================================================================
> --- /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];
>
> + /* 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 = 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) == 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);
> }
>
> /*-
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
context.)
> # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
> include GENERIC
> ident GENERICvtsc-NODBG
>
> nooptions PS3 #Sony Playstation 3 HACK!!! to allow sc
>
> options DDB # HACK!!! to dump early crash info (but 11.0-CURRENT already has it)
> options GDB # HACK!!! ...
>
> # Extra stuff:
> #options VERBOSE_SYSINIT
> #options BOOTVERBOSE=1
> #options BOOTHOWTO=RB_VERBOSE
> #options KTR
> #options KTR_MASK=KTR_TRAP
> #options KTR_CPUMASK=0xF
> #options KTR_VERBOSE
>
> # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt historically mishandled during booting
> device sc
> #device kbdmux # HACK: already listed by vt
> options SC_OFWFB # OFW frame buffer
> options SC_DFLT_FONT # compile font in
> makeoptions SC_DFLT_FONT=cp437
>
>
> # 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,
>
> 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=hd: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.
>
> - 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).
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ppc
mailing list