Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1560274 > unrolled thread

Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Olof Johansson <olof@lixom.net> - 2017-01-17 07:10 +0100
    Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Neil Armstrong <narmstrong@baylibre.com> - 2017-01-17 09:30 +0100
      Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Andreas Färber <afaerber@suse.de> - 2017-01-18 01:10 +0100
        Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Andreas Färber <afaerber@suse.de> - 2017-01-18 01:50 +0100
          Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Neil Armstrong <narmstrong@baylibre.com> - 2017-01-18 12:10 +0100
        Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and  usable memory range Neil Armstrong <narmstrong@baylibre.com> - 2017-01-18 12:10 +0100
        Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range Kevin Hilman <khilman@baylibre.com> - 2017-01-18 21:00 +0100

#1560274 — Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range

On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> Like I replied of my RFT patch :
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
>
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
>
> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.

Is there a way to detect what firmware is running and marking off
memory from early kernel init instead? That'll take care of the
concerns about memory size variance as well.

> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
>
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &
> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
>
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>
> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...

Technically we're not in regression territory here, since the platform
is obviously still in bringup and these aren't bugs that have been
introduced in this release. So I think we can take a little while to
sort out if there's a solution that, even if not ideal, at least is on
the path towards the proper fix and not away from it -- which this
seems to be.


-Olof

[toc] | [next] | [standalone]

#1560345

On 01/17/2017 07:07 AM, Olof Johansson wrote:
> On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>
>>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>>
>>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>>> to handle variants memory sizes.
>>>>>
>>>>> This patch also fixes the memory sizes for the following platforms :
>>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>
>>>> Queued for v4.10-rc.
>>>
>>> What is the motivation for this change? I have a local U-Boot patch to
>>> detect the amount of memory available as done downstream, but U-Boot
>>> only updates the reg property that you seem to be abandoning here...
>>>
>>> So for devices that come in multiple RAM configurations - like R-Box Pro
>>> - this would require separate .dts files now! This looks very wrong to
>>> me, especially since I am not aware of other platforms doing the same.
>>> Instead, there's memory reservations for top and bottom done in U-Boot
>>> for reg, plus reserved-memory nodes for anything in the middle.
>>>
>>> Another thing to consider is that uEFI boot (bootefi) handles memory
>>> reservation differently yet again, on the bootloader level. I have had
>>> that working fine on Odroid-C2 and Vega S95.
>>>
>>> So if there's no bug this is fixing (none mentioned in commit message) I
>>> strongly object to this patch.
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Hi Andreas,
>>
>> Like I replied of my RFT patch :
>> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
>> a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
>>
>> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
>> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
>>
>> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
>> their advices.
> 
> Is there a way to detect what firmware is running and marking off
> memory from early kernel init instead? That'll take care of the
> concerns about memory size variance as well.
> 
>> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
>> running stock u-boot version on various shipped products and Amlogic's own development boards.
>>
>> The bug is easily triggered by running :
>> # stress --vm 4 --vm-bytes 128M --timeout 10s &
>> [   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>> ...
>> [   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>> ...
>>
>> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
>> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>>
>> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
>> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
> 
> Technically we're not in regression territory here, since the platform
> is obviously still in bringup and these aren't bugs that have been
> introduced in this release. So I think we can take a little while to
> sort out if there's a solution that, even if not ideal, at least is on
> the path towards the proper fix and not away from it -- which this
> seems to be.
> 
> 
> -Olof
> 

Hi Olof, Andreas,

As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
overrides the reg property that is changed by the bootloader to provide the "real" memory size.

As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.

The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
recently merged DRM driver.
You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
But it should be confirmed.

Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.

I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
fixup for a future DTS cleanup.

Andreas, is this ok for you ?

This issue exists since forever on mainline linux, and even 4.9 has it.
Olof, How could a similar fix go in 4.9 stable ?

Thanks,
Neil

[toc] | [prev] | [next] | [standalone]

#1561146

Hi Neil,

Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
> overrides the reg property that is changed by the bootloader to provide the "real" memory size.

Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
intended, but at the same time it ignored any lowered or heightened
upper limit coming from the bootloader side.

As a rule of thumb, any nodes that have device_type set can be expected
to be modified during boot.

> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
> 
> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
> zones,

Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)

> but I also got the issue while running a fully fledged Desktop Environment thanks to the
> recently merged DRM driver.

I'll happily test once HDMI is ready. :)

> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
> But it should be confirmed.

Confirming no issues on three runs on meson-gxm-rbox-pro:

boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
[1] 2528
boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
stress-ng: info:  [2528] cache allocate: default cache size: 256K
stress-ng: info:  [2528] successful run completed in 10.07s

[1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info:  [2537] dispatching hogs: 4 vm
stress-ng: info:  [2537] cache allocate: default cache size: 256K
stress-ng: info:  [2537] successful run completed in 10.07s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info:  [2546] dispatching hogs: 4 vm
stress-ng: info:  [2546] cache allocate: default cache size: 256K
stress-ng: info:  [2546] successful run completed in 10.07s
boxer:~ #

> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
> 
> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
> fixup for a future DTS cleanup.
> 
> Andreas, is this ok for you ?

Yes, sounds fine to me, thanks. I'll note a few more nits to consider.

Kevin, I noticed that this supposedly applied patch did not show up in
linux-next for testing - could you merge your fixes branch into for-next
please for those of us working on new stuff?

> This issue exists since forever on mainline linux, and even 4.9 has it.
> Olof, How could a similar fix go in 4.9 stable ?

I guess it would then be best to consider splitting this patch up per
board/SoC so that you can set appropriate Fixes: headers indicating how
far back each one needs to be fixed.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[toc] | [prev] | [next] | [standalone]

#1561187

Am 18.01.2017 um 01:00 schrieb Andreas Färber:
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
> 
> Confirming no issues on three runs on meson-gxm-rbox-pro:
> 
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
> 
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #

Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
with both mainline EFI and vendor U-Boot.

I notice that I don't have CONFIG_DRM enabled - maybe related?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[toc] | [prev] | [next] | [standalone]

#1561567

On 01/18/2017 01:27 AM, Andreas Färber wrote:
> Am 18.01.2017 um 01:00 schrieb Andreas Färber:
>> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>>> recently merged DRM driver.
>>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>>> But it should be confirmed.
>>
>> Confirming no issues on three runs on meson-gxm-rbox-pro:
>>
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
>> [1] 2528
>> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
>> stress-ng: info:  [2528] cache allocate: default cache size: 256K
>> stress-ng: info:  [2528] successful run completed in 10.07s
>>
>> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info:  [2537] dispatching hogs: 4 vm
>> stress-ng: info:  [2537] cache allocate: default cache size: 256K
>> stress-ng: info:  [2537] successful run completed in 10.07s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info:  [2546] dispatching hogs: 4 vm
>> stress-ng: info:  [2546] cache allocate: default cache size: 256K
>> stress-ng: info:  [2546] successful run completed in 10.07s
>> boxer:~ #
> 
> Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
> with both mainline EFI and vendor U-Boot.
> 
> I notice that I don't have CONFIG_DRM enabled - maybe related?

Yes, It may add more pressure on the memory allocation.

Neil

> 
> Regards,
> Andreas
> 

[toc] | [prev] | [next] | [standalone]

#1561566

On 01/18/2017 01:00 AM, Andreas Färber wrote:
> Hi Neil,
> 
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
> 
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
> 
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
> 
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>>
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
> 
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
> 
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
> 
> I'll happily test once HDMI is ready. :)
> 
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
> 
> Confirming no issues on three runs on meson-gxm-rbox-pro:
> 
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
> 
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #

For 2 GiB boards, you may need to increase the vm threads :
# stress-ng --vm 16 --vm-bytes 128M --timeout 10s
stress-ng: info:  [1292] dispatching hogs: 16 vm
stress-ng: info:  [1292] cache allocate: default cache size: 512K
stress: info: [1275] dispatching hogs: 0 cpu, 0 io, 16 vm, 0 hdd
[  948.832694] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
[  948.832812] Bad mode in Error handler detected on CPU3, code 0xbf000000 -- SError
[  948.832832] CPU: 3 PID: 1279 Comm: stress Not tainted 4.10.0-rc4-00004-gba7e7b8 #14
...

On a Wetek Play2 board with 2GiB.

> 
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>>
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>>
>> Andreas, is this ok for you ?
> 
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
> 
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?
> 
>> This issue exists since forever on mainline linux, and even 4.9 has it.
>> Olof, How could a similar fix go in 4.9 stable ?
> 
> I guess it would then be best to consider splitting this patch up per
> board/SoC so that you can set appropriate Fixes: headers indicating how
> far back each one needs to be fixed.
> 
> Regards,
> Andreas
> 

[toc] | [prev] | [next] | [standalone]

#1562123 — Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range

Andreas Färber <afaerber@suse.de> writes:

> Hi Neil,
>
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
>
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
>
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
>
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>> 
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
>
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
>
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>
> I'll happily test once HDMI is ready. :)
>
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
>
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #
>
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>> 
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>> 
>> Andreas, is this ok for you ?
>
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
>
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?

Any fixes I have queued are always in my for-mext branch (which is
included i linux-next.)

This fix was there as well, but was removed due to objections shortly
after I added it, so it never quite made it to linux-next (or may have
for one day, I'm not sure.)

Kevin

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web