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) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
