[Bug 237590] powerpc64 PowerMac11,2 and 7,2 context, -r330614 and later (including -r345758): "ofwdump -ap" crashes the system, unable to sleep cpus; probable -r330610 "cause"

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Apr 26 20:53:39 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237590

            Bug ID: 237590
           Summary: powerpc64 PowerMac11,2 and 7,2 context, -r330614 and
                    later (including -r345758): "ofwdump -ap" crashes the
                    system, unable to sleep cpus; probable -r330610
                    "cause"
           Product: Base System
           Version: CURRENT
          Hardware: powerpc
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: marklmi26-fbsd at yahoo.com

The biggest issue may be the inability to sufficiently sleep CPUs
on powerpc64 in general, with ofwdump on old PowerMac G5's just
being a good way to test that.

This was originally observed on head -r345758.

But "bisecting" based on:

https://artifact.ci.freebsd.org/snapshot/head/r*

I found that for the likes of "ofwdump -ap > /dev/null" :

-r330572: does not crash the system (or program).
-r330614: crashes the system: timeout trying to sleep cpus.

There are no other https://artifact.ci.freebsd.org/snapshot/head/r*
between -r330572 and -r330614 with powerpc64 present. So I stopped
at this range.

Turns out that between those two versions is:

Revision 330610 . . .
Modified Wed Mar 7 17:08:07 2018 UTC . . . by nwhitehorn 
. . .
Move the powerpc64 direct map base address from zero to high memory. This
accomplishes a few things:
- Makes NULL an invalid address in the kernel, which is useful for catching
 bugs.
. . .

(It may be that -r330610 exposed another problem that was
accidentally avoided before that.)


So far it appears likely that every bootable/usable build from
-r330610 on crashes for the likes of "ofwdump -ap" when openfirmware
is used live and, so, the cpus need to avoid multi-threading the
openfirmware use. (So, for PowerMacs, when booted without usefdt mode
for  sufficiently recent builds).

I've not seen the problem with 32-bit powerpc FreeBSD on old PowerMacs,
including when used to boot the same machines. Only powerpc64 FreeBSD.

The only powerpc64 test contexts that I have access to sometimes are
old G5 PowerMacs: 2-socket/2-core-each PowerMac11,2 and
2-socket/1-core-each PowerMac7,2. So I've no direct evidence for
any other powerpc64 context.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list