Hi Greg,
There are two more patches about the ZONE_DMA[32] changes, especially
the second one, both them need be backported, thanks.
791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys()
calculation
2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation
is required
On 2021/5/11 20:35, Kefeng Wang wrote:
On 2021/3/8 17:58, Greg KH wrote:
On Mon, Mar 08, 2021 at 11:20:03AM +0800, Jing Xiangfeng wrote:
On 2021/3/7 23:24, Greg KH wrote:
On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne
wrote:
Hi Greg.
On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
Using two distinct DMA zones turned out to be problematic.
Here's an
attempt go back to a saner default.
What problem does this solve? How does this fit into the stable
kernel
rules?
We changed the way we setup memory zones in arm64 in order to
cater for
Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower
1GB of memory
and ZONE_DMA32 the rest of the 32bit address space. Since you
can't allocate
memory that crosses zone boundaries, this broke crashkernel
allocations on big
machines. This series fixes all this by parsing the HW
description and checking
for DMA constrained buses. When not found, the unnecessary zone
creation is
skipped.
What kernel/commit caused this "breakage"?
1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
Thanks for the info, all now queued up.
There is a fix in 5.11. Please consider applying the following commit to
5.10.y:
aed5041ef9a3 of: unittest: Fix build on architectures without
CONFIG_OF_ADDRES
Thanks, now queued up.
Hi Grep, another commit d78050ee3544 "arm64: Remove
arm64_dma32_phys_limit and its uses" should be involved, thanks.
"Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA
allocation from the whole RAM as arm64_dma32_phys_limit becomes
PHYS_MASK+1." from Catalin, see more from the link
https://www.spinics.net/lists/arm-kernel/msg867356.html
greg k-h
.
