| Message ID | 20210303073319.2215839-1-jingxiangfeng@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Default to 32-bit wide ZONE_DMA | expand |
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? thanks, greg k-h
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. That said, I have no clue whether this falls or not into the stable kernel rules. Regards, Nicolas
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"? thanks, greg k-h
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 Regards, Nicolas
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. greg k-h
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 > > greg k-h > . >
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. greg k-h
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 > . >
On Tue, May 11, 2021 at 08:35:47PM +0800, 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 Ok, now queued up. greg k-h
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 >> . >>
On Wed, Jun 23, 2021 at 02:59:59PM +0800, Kefeng Wang wrote: > Hi Greg, > > There are two more patches about the ZONE_DMA[32] changes, What ZONE_DMA changes? > especially the > second one, both them need be backported, thanks. Backported to where? > 791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys() > calculation > 2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is > required Have you tried these patches? Where do they need to be applied to? confused, greg k-h
On 2021/6/23 15:12, Greg KH wrote: > On Wed, Jun 23, 2021 at 02:59:59PM +0800, Kefeng Wang wrote: >> Hi Greg, >> >> There are two more patches about the ZONE_DMA[32] changes, > > What ZONE_DMA changes? See the subject, [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA, We asked the ARM64 ZONE_DMA change backport before, link[1] > >> especially the >> second one, both them need be backported, thanks. > > Backported to where? stable 5.10 > >> 791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys() >> calculation >> 2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is >> required > > Have you tried these patches? Where do they need to be applied to? Yes, we tested it, without them, especially the second one, we will meet crash when using kexec boot, also there is discussion in [2] and [3] from Catalin. > > confused, > Sorry about this, should add more information, thanks. [1] https://lore.kernel.org/linux-riscv/20210303073319.2215839-1-jingxiangfeng@huawei.com/ [2] https://lore.kernel.org/linux-devicetree/e60d643e-4879-3fc3-737d-2c145332a6d7@arm.com/ [3] https://lore.kernel.org/linux-arm-kernel/20201119175556.18681-1-catalin.marinas@arm.com/ > greg k-h > . >
On Wed, Jun 23, 2021 at 03:25:10PM +0800, Kefeng Wang wrote: > > > On 2021/6/23 15:12, Greg KH wrote: > > On Wed, Jun 23, 2021 at 02:59:59PM +0800, Kefeng Wang wrote: > > > Hi Greg, > > > > > > There are two more patches about the ZONE_DMA[32] changes, > > > > What ZONE_DMA changes? > > See the subject, [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide > ZONE_DMA, We asked the ARM64 ZONE_DMA change backport before, link[1] The subject doesn't help much, sorry, what commit does this refer to? What happened to it? Was it accepted or rejected? > > > especially the > > > second one, both them need be backported, thanks. > > > > Backported to where? > > stable 5.10 Why? > > > 791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys() > > > calculation > > > 2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is > > > required > > > > Have you tried these patches? Where do they need to be applied to? > > Yes, we tested it, without them, especially the second one, we will > meet crash when using kexec boot, also there is discussion in [2] > and [3] from Catalin. These [] do not seem to be links :( thanks, greg k-h
On 2021/6/23 15:34, Greg KH wrote: > On Wed, Jun 23, 2021 at 03:25:10PM +0800, Kefeng Wang wrote: >> >> >> On 2021/6/23 15:12, Greg KH wrote: >>> On Wed, Jun 23, 2021 at 02:59:59PM +0800, Kefeng Wang wrote: >>>> Hi Greg, >>>> >>>> There are two more patches about the ZONE_DMA[32] changes, >>> >>> What ZONE_DMA changes? >> >> See the subject, [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide >> ZONE_DMA, We asked the ARM64 ZONE_DMA change backport before, link[1] Let's inline the link: https://lore.kernel.org/lkml/20210303073319.2215839-1-jingxiangfeng@huawei.com/ The following 7 patches(we asked from link) has merged into lts5.10(tag: v5.10.22) 4d7ed9a49b0c mm: Remove examples from enum zone_type comment 8eaef922e938 arm64: mm: Set ZONE_DMA size based on early IORT scan 35ec3d09ff6a arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges a9861e7fa4f8 of: unittest: Add test for of_dma_get_max_cpu_address() 18bf6e998d08 of/address: Introduce of_dma_get_max_cpu_address() 3fbe62ffbb54 arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() 407b173adfac arm64: mm: Move reserve_crashkernel() into mem_init() but the patch "arm64: mm: Move reserve_crashkernel() into mem_init()" has some issue, see the following discussion from Catalin, https://lore.kernel.org/linux-devicetree/e60d643e-4879-3fc3-737d-2c145332a6d7@arm.com/ https://lore.kernel.org/linux-arm-kernel/20201119175556.18681-1-catalin.marinas@arm.com/ and yes, we met crash in lts5.10 when kexec boot due to "arm64: mm: Move reserve_crashkernel() into mem_init()" too, which could be fixed by commit 2687275a5843 "arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required", and the commit 791ab8b2e3db "arm64: Ignore any DMA offsets in the max_zone_phys() calculation" also about DMA set, So I only asked the two patches(both in v5.11) related ARM64 ZONE_DMA changes backported into lts5.10. > > The subject doesn't help much, sorry, what commit does this refer to? > What happened to it? Was it accepted or rejected? > >>>> especially the >>>> second one, both them need be backported, thanks. >>> >>> Backported to where? >> >> stable 5.10 > > Why? > >>>> 791ab8b2e3db - arm64: Ignore any DMA offsets in the max_zone_phys() >>>> calculation >>>> 2687275a5843 - arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is >>>> required >>> >>> Have you tried these patches? Where do they need to be applied to? >> >> Yes, we tested it, without them, especially the second one, we will >> meet crash when using kexec boot, also there is discussion in [2] >> and [3] from Catalin. > > These [] do not seem to be links :( I could see the links is in the end, see https://lore.kernel.org/lkml/e47df0fd-0ddd-408b-2972-1b6d0a786f00@huawei.com/ > > thanks, > > greg k-h > . >
On Wed, Jun 23, 2021 at 04:01:10PM +0800, Kefeng Wang wrote: > > > On 2021/6/23 15:34, Greg KH wrote: > > On Wed, Jun 23, 2021 at 03:25:10PM +0800, Kefeng Wang wrote: > > > > > > > > > On 2021/6/23 15:12, Greg KH wrote: > > > > On Wed, Jun 23, 2021 at 02:59:59PM +0800, Kefeng Wang wrote: > > > > > Hi Greg, > > > > > > > > > > There are two more patches about the ZONE_DMA[32] changes, > > > > > > > > What ZONE_DMA changes? > > > > > > See the subject, [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide > > > ZONE_DMA, We asked the ARM64 ZONE_DMA change backport before, link[1] > > Let's inline the link: > https://lore.kernel.org/lkml/20210303073319.2215839-1-jingxiangfeng@huawei.com/ > > The following 7 patches(we asked from link) has merged into lts5.10(tag: > v5.10.22) > > 4d7ed9a49b0c mm: Remove examples from enum zone_type comment > 8eaef922e938 arm64: mm: Set ZONE_DMA size based on early IORT scan > 35ec3d09ff6a arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges > a9861e7fa4f8 of: unittest: Add test for of_dma_get_max_cpu_address() > 18bf6e998d08 of/address: Introduce of_dma_get_max_cpu_address() > 3fbe62ffbb54 arm64: mm: Move zone_dma_bits initialization into > zone_sizes_init() > 407b173adfac arm64: mm: Move reserve_crashkernel() into mem_init() > > but the patch "arm64: mm: Move reserve_crashkernel() into mem_init()" > has some issue, see the following discussion from Catalin, > > https://lore.kernel.org/linux-devicetree/e60d643e-4879-3fc3-737d-2c145332a6d7@arm.com/ > https://lore.kernel.org/linux-arm-kernel/20201119175556.18681-1-catalin.marinas@arm.com/ > > and yes, we met crash in lts5.10 when kexec boot due to "arm64: mm: Move > reserve_crashkernel() into mem_init()" too, which could be fixed by > commit 2687275a5843 "arm64: Force NO_BLOCK_MAPPINGS if crashkernel > reservation is required", and the commit 791ab8b2e3db "arm64: Ignore any DMA > offsets in the max_zone_phys() calculation" also about DMA set, > So I only asked the two patches(both in v5.11) related ARM64 ZONE_DMA > changes backported into lts5.10. Thanks, all now queued up. greg k-h
On 2021/6/25 18:19, Greg KH wrote: > On Wed, Jun 23, 2021 at 04:01:10PM +0800, Kefeng Wang wrote: >> >> Let's inline the link: >> https://lore.kernel.org/lkml/20210303073319.2215839-1-jingxiangfeng@huawei.com/ >> >> The following 7 patches(we asked from link) has merged into lts5.10(tag: >> v5.10.22) >> >> 4d7ed9a49b0c mm: Remove examples from enum zone_type comment >> 8eaef922e938 arm64: mm: Set ZONE_DMA size based on early IORT scan >> 35ec3d09ff6a arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges >> a9861e7fa4f8 of: unittest: Add test for of_dma_get_max_cpu_address() >> 18bf6e998d08 of/address: Introduce of_dma_get_max_cpu_address() >> 3fbe62ffbb54 arm64: mm: Move zone_dma_bits initialization into >> zone_sizes_init() >> 407b173adfac arm64: mm: Move reserve_crashkernel() into mem_init() >> >> but the patch "arm64: mm: Move reserve_crashkernel() into mem_init()" >> has some issue, see the following discussion from Catalin, >> >> https://lore.kernel.org/linux-devicetree/e60d643e-4879-3fc3-737d-2c145332a6d7@arm.com/ >> https://lore.kernel.org/linux-arm-kernel/20201119175556.18681-1-catalin.marinas@arm.com/ >> >> and yes, we met crash in lts5.10 when kexec boot due to "arm64: mm: Move >> reserve_crashkernel() into mem_init()" too, which could be fixed by >> commit 2687275a5843 "arm64: Force NO_BLOCK_MAPPINGS if crashkernel >> reservation is required", and the commit 791ab8b2e3db "arm64: Ignore any DMA >> offsets in the max_zone_phys() calculation" also about DMA set, >> So I only asked the two patches(both in v5.11) related ARM64 ZONE_DMA >> changes backported into lts5.10. > Thanks, all now queued up. Thank you again ;) > greg k-h > . >