From: Mike Rapoport <rppt(a)linux.ibm.com>
Hi,
Commit 73a6e474cb37 ("mm: memmap_init: iterate over
memblock regions rather that check each PFN") exposed several issues with
the memory map initialization and these patches fix those issues.
Initially there were crashes during compaction that Qian Cai reported back
in April [1]. It seemed back then that the problem was fixed, but a few
weeks ago Andrea Arcangeli hit the same bug [2] and there was an additional
discussion at [3].
I didn't appreciate variety of ways BIOSes can report memory in the first
megabyte, so v3 of this set caused boot failures on several x86 systems.
Hopefully this time I covered all the bases.
The first patch here complements commit bde9cfa3afe4 ("x86/setup: don't
remove E820_TYPE_RAM for pfn 0") for the cases when BIOS reports the first
page as absent or reserved.
The second patch is a more robust version of d3921cb8be29 ("mm: fix
initialization of struct page for holes in memory layout") that can now
handle the above cases as well.
v4:
* make sure pages in the range 0 - start_pfn_of_lowest_zone are initialized
even if an architecture hides them from the generic mm
* finally make pfn 0 on x86 to be a part of memory visible to the generic
mm as reserved memory.
v3: https://lore.kernel.org/lkml/20210111194017.22696-1-rppt@kernel.org
* use architectural zone constraints to set zone links for struct pages
corresponding to the holes
* drop implicit update of memblock.memory
* add a patch that sets pfn 0 to E820_TYPE_RAM on x86
v2: https://lore.kernel.org/lkml/20201209214304.6812-1-rppt@kernel.org/):
* added patch that adds all regions in memblock.reserved that do not
overlap with memblock.memory to memblock.memory in the beginning of
free_area_init()
[1] https://lore.kernel.org/lkml/8C537EB7-85EE-4DCF-943E-3CC0ED0DF56D@lca.pw
[2] https://lore.kernel.org/lkml/20201121194506.13464-1-aarcange@redhat.com
[3] https://lore.kernel.org/mm-commits/20201206005401.qKuAVgOXr%akpm@linux-foun…
Mike Rapoport (2):
x86/setup: always add the beginning of RAM as memblock.memory
mm: fix initialization of struct page for holes in memory layout
arch/x86/kernel/setup.c | 8 ++++
mm/page_alloc.c | 85 ++++++++++++++++++++++++-----------------
2 files changed, 59 insertions(+), 34 deletions(-)
--
2.28.0
Quoting Sasha Levin (2021-02-01 08:52:31)
> This is a note to let you know that I've just added the patch titled
>
> ASoC: qcom: Fix number of HDMI RDMA channels on sc7180
>
> to the 5.10-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> asoc-qcom-fix-number-of-hdmi-rdma-channels-on-sc7180.patch
> and it can be found in the queue-5.10 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
Please drop this from stable queue. It will be reverted shortly and
replaced with a proper patch. See [2] for more info.
Quote:
> In my opinion, It 's better not to apply this patch.
>
> I will post patch with changing size in sc7180.dtsi file.
After further discussion with Srinivasa it turns out the dtsi file is
correct, but the regmap size is wrong in a different way and the valid
registers functions are also wrong. We'll be sending a proper fix this
week.
Thanks,
Stephen
[2] https://lore.kernel.org/alsa-devel/89cc3dfb-35da-3498-b126-b440c91f9a45@cod…
>
>
> commit f3d3274aa72af6366a4cfef1a5a51154aca8cd69
> Author: Stephen Boyd <swboyd(a)chromium.org>
> Date: Fri Jan 15 12:33:29 2021 -0800
>
> ASoC: qcom: Fix number of HDMI RDMA channels on sc7180
>
> [ Upstream commit 7dfe20ee92f681ab1342015254ddb77a18f40cdb ]
>
> Suspending/resuming with an HDMI dongle attached leads to crashes from
> an audio regmap.
>
> Unable to handle kernel paging request at virtual address ffffffc018068000
> Mem abort info:
> ESR = 0x96000047
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000047
> CM = 0, WnR = 1
> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081b12000
> [ffffffc018068000] pgd=0000000275d14003, pud=0000000275d14003, pmd=000000026365d003, pte=0000000000000000
> Internal error: Oops: 96000047 [#1] PREEMPT SMP
> Call trace:
> regmap_mmio_write32le+0x2c/0x40
> regmap_mmio_write+0x48/0x6c
> _regmap_bus_reg_write+0x34/0x44
> _regmap_write+0x100/0x150
> regcache_default_sync+0xc0/0x138
> regcache_sync+0x188/0x26c
> lpass_platform_pcmops_resume+0x48/0x54 [snd_soc_lpass_platform]
> snd_soc_component_resume+0x28/0x40
> soc_resume_deferred+0x6c/0x178
> process_one_work+0x208/0x3c8
> worker_thread+0x23c/0x3e8
> kthread+0x144/0x178
> ret_from_fork+0x10/0x18
> Code: d503201f d50332bf f94002a8 8b344108 (b9000113)
>
> I can reliably reproduce this problem by running 'tail' on the registers
> file in debugfs for the hdmi regmap.
>
> # tail /sys/kernel/debug/regmap/62d87000.lpass-lpass_hdmi/registers
> [ 84.658733] Unable to handle kernel paging request at virtual address ffffffd0128e800c
>
> This crash happens because we're trying to read registers from the
> regmap beyond the length of the mapping created by ioremap().
>
> The number of hdmi_rdma_channels determines the size of the regmap via
> this code in sound/soc/qcom/lpass-cpu.c:
>
> lpass_hdmi_regmap_config.max_register = LPAIF_HDMI_RDMAPER_REG(variant, variant->hdmi_rdma_channels);
>
> According to debugfs the size of the regmap is 0x68010 but according to
> the DTS file posted in [1] the size is only 0x68000 (see the first reg
> property of the lpass_cpu node). Let's change the number of channels to
> be 3 instead of 4 so the math works out to have a max register of
> 0x67010, nicely fitting inside of the region size of 0x68000.
>
> Note: I tried to bump up the size of the register region to the next
> page to include the 0x68010 register but then the tail command caused
> SErrors with an async abort, implying that the register region doesn't
> exist or it isn't clocked because the bus is telling us that the
> register read failed. I reduce the number of channels and played audio
> through the HDMI channel and it kept working so I think this is correct.
>
> Fixes: 2ad63dc8df6b ("ASoC: qcom: sc7180: Add support for audio over DP")
> Link: https://lore.kernel.org/r/1601448168-18396-2-git-send-email-srivasam@codeau… [1]
> Cc: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org>
> Cc: Srinivasa Rao <srivasam(a)codeaurora.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
> Cc: Cheng-Yi Chiang <cychiang(a)chromium.org>
> Signed-off-by: Stephen Boyd <swboyd(a)chromium.org>
> Link: https://lore.kernel.org/r/20210115203329.846824-1-swboyd@chromium.org
> Signed-off-by: Mark Brown <broonie(a)kernel.org>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
> index c647e627897a2..c33da7faaf913 100644
> --- a/sound/soc/qcom/lpass-sc7180.c
> +++ b/sound/soc/qcom/lpass-sc7180.c
> @@ -170,7 +170,7 @@ static struct lpass_variant sc7180_data = {
> .rdma_channels = 5,
> .hdmi_rdma_reg_base = 0x64000,
> .hdmi_rdma_reg_stride = 0x1000,
> - .hdmi_rdma_channels = 4,
> + .hdmi_rdma_channels = 3,
> .dmactl_audif_start = 1,
> .wrdma_reg_base = 0x18000,
> .wrdma_reg_stride = 0x1000,