- User Since
- Nov 19 2016, 6:23 AM (200 w, 16 h)
Thu, Sep 10
Given what I've seen about the 5.8 mainline Linux kernel status for the RPi4 and that Fedora just branched 33 from Rawhide (for a late Oct. release), I decided to try installing a Fedora 33 branch server and UEFI/ACPI v1.20 and doing a "yum update" on the booted result. (USB3 SSD based, no microsd card involved.) That ended up with a 5.8.7-300.fc33.aarch64 kernel and it sees all 8GiB of RAM. I've tried the huge file copy and diff type of test and it has not failed yet. (The files are each bigger than the RAM.) (I've not noticed other issues but that likely does not imply much.) For reference, the boot reported the following "Zone ranges":
[ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x1fefec8c0-0x1ff002fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] DMA32 [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Device empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000001fffff] [ 0.000000] node 0: [mem 0x0000000000200000-0x00000000337d7fff] [ 0.000000] node 0: [mem 0x00000000337d8000-0x000000003387ffff] [ 0.000000] node 0: [mem 0x0000000033880000-0x000000003390ffff] [ 0.000000] node 0: [mem 0x0000000033910000-0x000000003398ffff] [ 0.000000] node 0: [mem 0x0000000033990000-0x00000000339affff] [ 0.000000] node 0: [mem 0x00000000339b0000-0x0000000033a2ffff] [ 0.000000] node 0: [mem 0x0000000033a30000-0x0000000036efffff] [ 0.000000] node 0: [mem 0x0000000036f00000-0x00000000372dffff] [ 0.000000] node 0: [mem 0x00000000372e0000-0x000000003b2fffff] [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000fbffffff] [ 0.000000] node 0: [mem 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Zeroed struct page in unavailable ranges: 552 pages [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
What OpenBSD did for the size of the DMA area for XHCI looks to be unusual (relative to NetBSD and Linux). But the next-to-last "node 0:" line above does show not using the whole DMA32 range. (I do not now why they had it do that.)
Wed, Sep 9
FYI: Something that I do not see represented in the NetBSD debug information is that DMA channel 11 (of DMA4 engine type) is the only one explicitly noted in rpi_DATA_2711_1p0.pdf as "additionally able to access the PCIe interface".
Mon, Sep 7
My understanding is that different devices have different DMA limits. XHCI has 3 GiB but others have 1 GiB. There is not one DMA controller enforcing one limit common to all contexts but multiple separate limits. Using the smallest limit for all devices may well be an alternative but that is not what the ACPI tables describe (from what I read on the lists).
Jul 11 2020
This code leads to an OverDrive 1000 getting the following error.
Jun 20 2020
Feb 28 2020
I have removed my prior comments: they traced to a different issue that, when worked around, got rid of the behavior that I had reported. Sorry for the noise.
Feb 23 2020
Feb 22 2020
Feb 17 2020
Feb 2 2020
Feb 1 2020
Jan 30 2020
Jan 29 2020
If there are non-PowerMac powerpc platforms that get the threads-stuck-sleeping
problem, then this type of solution may be insufficient for it to generalize for the specific
problem. For example, it is not obvious how accurate such would end up for a context
where NUMA can be relevant. I do not have a context for investigating anything that
Jan 26 2020
Note: I was not (and am not) style(9) literate when I did the investigation that eventually stabilized on this code. My information-handling capacity was limited. I fully expect this will need to be dealt with at some point. But I'd prefer to first have the technique(s) used be thought to be stable before focusing on the other type of knowledge.
Jul 10 2019
FYI: The addition to CFLAGS.powerpc did not add -msecure-plt to the cc for linking libc.so.7.full :
Using -msecure-plt did no good with system-clang. Despite the -msecure-plt as shown below:
Jul 9 2019
FYI: I was using devel/powerpc64-binutils with system clang (8.0.0 or now 8.0.1), not gcc.
Changes to gcc will not change the behavior for what I was doing.
Justin wrote "Secure-PLT is fully compatible with BSS-PLT, so there's no issue with compatibility".
Apr 25 2019
In order to keep the thread order stable for process-birth-time,
I ended up also using:
Mar 24 2019
I frequently cross-build amd64->aarch64 and amd64->armv7 and also do
installworld's of the aarch64 and armv7 worlds into directories trees on the
amd64 machine ( same file system as the amd64 world is on, but in something
like, for example, /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud ).
(Later such are used via qemu-user-static and poudriere-devel , for example.)
Mar 3 2019
FYI: In attempting a devel/powerpc64-xtoolchain-gcc based build of head -r334018
on a powerpc64 I just had to make these two changes in order to avoid the problem
reported here: otherwise unable to build llvm-tblgen .
Jan 25 2019
Jan 13 2019
What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* . There are architectures for which modern gdb from ports fails ( by running into bugs in C++ thrown-exception support in the system libgc_s ): powerpc families. (I experiment with using more modern compilers. clang has issues of its own but devel/powerpc64-gcc for powerpc64 targeting is useful for buildworld buildkernel and more. I have a patched libgcc_s that I reported on the lists but most folks do not have.)
Jul 4 2017
This change addresses the direct, observed consequences for switching from
the first anonymous struct to the second one: it avoids interpreting old
"first struct" material as upcall information.
Jul 1 2017
Again for future reference for folks that might look at this:
In essence some notes from bugzilla 220404 for
future reference to folks that might look here.
Jun 28 2017
If this page or a variant is to be used for 11.1 then
pc98 should be covered rather than only being listed
for the initial/final releases. (I'm less sure for history
like alpha or ia64.)
Apr 28 2017
I should note that when devel/*-binutils went to
2.28 which failed I reverted to devel/*binutils
-r436731 (2.27) in order for things to work. I still
have that configuration and it was used in the
test builds that I did.
FYI: prior to this change a self-hosted/native build of
devel/aarch64-gcc or devel/powerpc64-gcc would
fail for not finding 6 files listed in pkg-plist .
devel/arm64-gcc did not list the 6 files there and so
did not install them but the self-hosted/native build
I built examples based on patching:
Mar 6 2017
-r314624 prevented a PowerMac G5 so-called "Quad Core" from competing
its boot (of -r314687): CAM status: Command timeout's. Reverting the two
files fixed it. See, e.g.,
Feb 17 2017
Note: The "truncated" sp/fp line for "panic() at . . ."
is from the serial console tending to drop text.
I got a panic that involved fork_trampoline in the back trace.
I've no clue if it is related.
Feb 15 2017
That last buildworld buildkernel completed just
fine (really only building the kernel since world
had completed before).
The core files did not suggest a stack corruption
to me, nor was fork active. My test code
recorded its before and after fork stack address
examples and they were equal as they should be.
Feb 14 2017
Drat: buildworld got a different failure in sh (see below).
Test status update at ~3 hours 40 minutes in:
One minor point: