From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754129AbdARLAn (ORCPT ); Wed, 18 Jan 2017 06:00:43 -0500 Received: from mail-lf0-f53.google.com ([209.85.215.53]:36625 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753929AbdARK7G (ORCPT ); Wed, 18 Jan 2017 05:59:06 -0500 Subject: Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range To: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Kevin Hilman References: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com> <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com> <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Cc: Olof Johansson , "devicetree@vger.kernel.org" , xypron.glpk@gmx.de, "linux-kernel@vger.kernel.org" , Carlo Caione , linux-amlogic@lists.infradead.org, "linux-arm-kernel@lists.infradead.org" From: Neil Armstrong Organization: Baylibre Message-ID: Date: Wed, 18 Jan 2017 11:57:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Armstrong Subject: Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range Date: Wed, 18 Jan 2017 11:57:22 +0100 Message-ID: References: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com> <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com> <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Kevin Hilman Cc: "devicetree@vger.kernel.org" , xypron.glpk@gmx.de, "linux-kernel@vger.kernel.org" , Carlo Caione , Olof Johansson , linux-amlogic@lists.infradead.org, "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org T24gMDEvMTgvMjAxNyAwMTowMCBBTSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+IEhpIE5laWws Cj4gCj4gQW0gMTcuMDEuMjAxNyB1bSAwOToyMSBzY2hyaWViIE5laWwgQXJtc3Ryb25nOgo+PiBB cyBJIGZpbmFsbHkgdW5kZXJzdGFuZCwgdGhlIHJlYWwgaXNzdWUgaGVyZSBpcyB0aGUgdXNhZ2Ug b2YgdGhlICJsaW51eCx1c2VhYmxlLW1lbW9yeSIgcHJvcGVydHkgdGhhdAo+PiBvdmVycmlkZXMg dGhlIHJlZyBwcm9wZXJ0eSB0aGF0IGlzIGNoYW5nZWQgYnkgdGhlIGJvb3Rsb2FkZXIgdG8gcHJv dmlkZSB0aGUgInJlYWwiIG1lbW9yeSBzaXplLgo+IAo+IFllcywgZXhhY3RseS4gSXQgYXNzdXJl ZCB0aGF0IDAuLjB4MDEwMDAwMDAgd2FzIGFsd2F5cyB1bmF2YWlsYWJsZSwgYXMKPiBpbnRlbmRl ZCwgYnV0IGF0IHRoZSBzYW1lIHRpbWUgaXQgaWdub3JlZCBhbnkgbG93ZXJlZCBvciBoZWlnaHRl bmVkCj4gdXBwZXIgbGltaXQgY29taW5nIGZyb20gdGhlIGJvb3Rsb2FkZXIgc2lkZS4KPiAKPiBB cyBhIHJ1bGUgb2YgdGh1bWIsIGFueSBub2RlcyB0aGF0IGhhdmUgZGV2aWNlX3R5cGUgc2V0IGNh biBiZSBleHBlY3RlZAo+IHRvIGJlIG1vZGlmaWVkIGR1cmluZyBib290Lgo+IAo+PiBBcyBJIHVu ZGVyc3RhbmQgdGhlIG1haW5saW5lIFUtQm9vdCBkb2VzIGl0IHJpZ2h0LCBhbmQgaXQncyBhIGdv b2QgbmV3cywgYW5kIGl0IHNlZW1zIHVFRkkgbmVlZCB0byBwcm92aWRlCj4+IHNvbWUgc3BlY2lh bGl6ZWQgbWVtb3J5IHJhbmdlIGFzd2VsbCwgYnV0IHRoZSB2ZW5kb3IgVS1Cb290IHZlcnNpb25z IG9ubHkgcHJvdmlkZSB0aGUgZnVsbCBtZW1vcnkgcmFuZ2UgaGVyZS4KPj4gSXQgc2VlbXMgb2J2 aW91cyB0aGF0IHdoYXRldmVyIHJhbmdlIGlzIHByb3ZpZGVkIGJ5IHUtYm9vdCwgdGhlIGZpcnN0 IDE2TWlCIHNob3VsZCBiZSByZXNlcnZlZC4KPj4KPj4gVGhlIHN0cmVzcy1uZyBwYWNrYWdlIHBy b3ZpZGVzIHRoaXMgInN0cmVzcyIgY29tbWFuZCBhbmQgaXMgdXNlZCB0byBmb3JjZSB0aGUga2Vy bmVsIHRvIG1hcCBtb3JlIG1lbW9yeQo+PiB6b25lcywKPiAKPiBUaGFua3MsIGl0cyBiaW5hcnkg aXMgY2FsbGVkIHN0cmVzcy1uZyBpbiBvcGVuU1VTRSBUdW1ibGV3ZWVkLiA7KQo+IAo+PiBidXQg SSBhbHNvIGdvdCB0aGUgaXNzdWUgd2hpbGUgcnVubmluZyBhIGZ1bGx5IGZsZWRnZWQgRGVza3Rv cCBFbnZpcm9ubWVudCB0aGFua3MgdG8gdGhlCj4+IHJlY2VudGx5IG1lcmdlZCBEUk0gZHJpdmVy Lgo+IAo+IEknbGwgaGFwcGlseSB0ZXN0IG9uY2UgSERNSSBpcyByZWFkeS4gOikKPiAKPj4gWW91 IG1heSBub3QgYmUgYWJsZSB0byB0cmlnZ2VyIHRoZSBpc3N1ZSBzaW5jZSBpdCBzZWVtcyBBbWxv Z2ljIHJlZHVjZXMgdGhpcyByZXNlcnZlZCBzaXplIG9uIEdYTC9HWE0gOgo+PiBodHRwczovL2dp dGh1Yi5jb20va2hhZGFzL2xpbnV4L2NvbW1pdC82OThkZjJjNmNmYmIwZDFhOTM1OTc0MzIwOGU4 MzUxN2IzMWRhNmNlCj4+IEJ1dCBpdCBzaG91bGQgYmUgY29uZmlybWVkLgo+IAo+IENvbmZpcm1p bmcgbm8gaXNzdWVzIG9uIHRocmVlIHJ1bnMgb24gbWVzb24tZ3htLXJib3gtcHJvOgo+IAo+IGJv eGVyOn4gIyBzdHJlc3MtbmcgLS12bSA0IC0tdm0tYnl0ZXMgMTI4TSAtLXRpbWVvdXQgMTBzICYK PiBbMV0gMjUyOAo+IGJveGVyOn4gIyBzdHJlc3Mtbmc6IGluZm86ICBbMjUyOF0gZGlzcGF0Y2hp bmcgaG9nczogNCB2bQo+IHN0cmVzcy1uZzogaW5mbzogIFsyNTI4XSBjYWNoZSBhbGxvY2F0ZTog ZGVmYXVsdCBjYWNoZSBzaXplOiAyNTZLCj4gc3RyZXNzLW5nOiBpbmZvOiAgWzI1MjhdIHN1Y2Nl c3NmdWwgcnVuIGNvbXBsZXRlZCBpbiAxMC4wN3MKPiAKPiBbMV0rICBEb25lICAgICAgICAgICAg ICAgICAgICBzdHJlc3MtbmcgLS12bSA0IC0tdm0tYnl0ZXMgMTI4TSAtLXRpbWVvdXQgMTBzCj4g Ym94ZXI6fiAjIHN0cmVzcy1uZyAtLXZtIDQgLS12bS1ieXRlcyAxMjhNIC0tdGltZW91dCAxMHMK PiBzdHJlc3Mtbmc6IGluZm86ICBbMjUzN10gZGlzcGF0Y2hpbmcgaG9nczogNCB2bQo+IHN0cmVz cy1uZzogaW5mbzogIFsyNTM3XSBjYWNoZSBhbGxvY2F0ZTogZGVmYXVsdCBjYWNoZSBzaXplOiAy NTZLCj4gc3RyZXNzLW5nOiBpbmZvOiAgWzI1MzddIHN1Y2Nlc3NmdWwgcnVuIGNvbXBsZXRlZCBp biAxMC4wN3MKPiBib3hlcjp+ICMgc3RyZXNzLW5nIC0tdm0gNCAtLXZtLWJ5dGVzIDEyOE0gLS10 aW1lb3V0IDEwcwo+IHN0cmVzcy1uZzogaW5mbzogIFsyNTQ2XSBkaXNwYXRjaGluZyBob2dzOiA0 IHZtCj4gc3RyZXNzLW5nOiBpbmZvOiAgWzI1NDZdIGNhY2hlIGFsbG9jYXRlOiBkZWZhdWx0IGNh Y2hlIHNpemU6IDI1NksKPiBzdHJlc3Mtbmc6IGluZm86ICBbMjU0Nl0gc3VjY2Vzc2Z1bCBydW4g Y29tcGxldGVkIGluIDEwLjA3cwo+IGJveGVyOn4gIwoKRm9yIDIgR2lCIGJvYXJkcywgeW91IG1h eSBuZWVkIHRvIGluY3JlYXNlIHRoZSB2bSB0aHJlYWRzIDoKIyBzdHJlc3MtbmcgLS12bSAxNiAt LXZtLWJ5dGVzIDEyOE0gLS10aW1lb3V0IDEwcwpzdHJlc3Mtbmc6IGluZm86ICBbMTI5Ml0gZGlz cGF0Y2hpbmcgaG9nczogMTYgdm0Kc3RyZXNzLW5nOiBpbmZvOiAgWzEyOTJdIGNhY2hlIGFsbG9j YXRlOiBkZWZhdWx0IGNhY2hlIHNpemU6IDUxMksKc3RyZXNzOiBpbmZvOiBbMTI3NV0gZGlzcGF0 Y2hpbmcgaG9nczogMCBjcHUsIDAgaW8sIDE2IHZtLCAwIGhkZApbICA5NDguODMyNjk0XSBCYWQg bW9kZSBpbiBFcnJvciBoYW5kbGVyIGRldGVjdGVkIG9uIENQVTEsIGNvZGUgMHhiZjAwMDAwMCAt LSBTRXJyb3IKWyAgOTQ4LjgzMjgxMl0gQmFkIG1vZGUgaW4gRXJyb3IgaGFuZGxlciBkZXRlY3Rl ZCBvbiBDUFUzLCBjb2RlIDB4YmYwMDAwMDAgLS0gU0Vycm9yClsgIDk0OC44MzI4MzJdIENQVTog MyBQSUQ6IDEyNzkgQ29tbTogc3RyZXNzIE5vdCB0YWludGVkIDQuMTAuMC1yYzQtMDAwMDQtZ2Jh N2U3YjggIzE0Ci4uLgoKT24gYSBXZXRlayBQbGF5MiBib2FyZCB3aXRoIDJHaUIuCgo+IAo+PiBL ZXZpbiBhc2tlZCBtZSBpbml0aWFsbHkgdG8gaGFuZGxlIHRoaXMgInN0YXJ0IG9mIGRkciIgcmVz ZXJ2ZWQgem9uZSB2aWEgYSByZXNlcnZlZC1tZW1vcnkgZW50cnksIGJ1dAo+PiBhdCB0aGF0IHRp bWUgaXQgc2VlbWVkIGEgYmV0dGVyIGlkZWEgdG8gdXNlICJsaW51eCx1c2VhYmxlLW1lbW9yeSIs IGJ1dCBJIHJlY29uIGl0IG1heSBiZSBhbiBlcnJvci4KPj4KPj4gSSB3aWxsIHB1c2ggYSB2NSB3 aXRoIGEgc3VwcGxlbWVudGFyeSByZXNlcnZlZC1tZW1vcnkgZW50cnkgYW5kIHdpbGwgcG9zdHBv bmUgdGhlIGJvYXJkcyBtZW1vcnkgc2l6ZQo+PiBmaXh1cCBmb3IgYSBmdXR1cmUgRFRTIGNsZWFu dXAuCj4+Cj4+IEFuZHJlYXMsIGlzIHRoaXMgb2sgZm9yIHlvdSA/Cj4gCj4gWWVzLCBzb3VuZHMg ZmluZSB0byBtZSwgdGhhbmtzLiBJJ2xsIG5vdGUgYSBmZXcgbW9yZSBuaXRzIHRvIGNvbnNpZGVy Lgo+IAo+IEtldmluLCBJIG5vdGljZWQgdGhhdCB0aGlzIHN1cHBvc2VkbHkgYXBwbGllZCBwYXRj aCBkaWQgbm90IHNob3cgdXAgaW4KPiBsaW51eC1uZXh0IGZvciB0ZXN0aW5nIC0gY291bGQgeW91 IG1lcmdlIHlvdXIgZml4ZXMgYnJhbmNoIGludG8gZm9yLW5leHQKPiBwbGVhc2UgZm9yIHRob3Nl IG9mIHVzIHdvcmtpbmcgb24gbmV3IHN0dWZmPwo+IAo+PiBUaGlzIGlzc3VlIGV4aXN0cyBzaW5j ZSBmb3JldmVyIG9uIG1haW5saW5lIGxpbnV4LCBhbmQgZXZlbiA0LjkgaGFzIGl0Lgo+PiBPbG9m LCBIb3cgY291bGQgYSBzaW1pbGFyIGZpeCBnbyBpbiA0Ljkgc3RhYmxlID8KPiAKPiBJIGd1ZXNz IGl0IHdvdWxkIHRoZW4gYmUgYmVzdCB0byBjb25zaWRlciBzcGxpdHRpbmcgdGhpcyBwYXRjaCB1 cCBwZXIKPiBib2FyZC9Tb0Mgc28gdGhhdCB5b3UgY2FuIHNldCBhcHByb3ByaWF0ZSBGaXhlczog aGVhZGVycyBpbmRpY2F0aW5nIGhvdwo+IGZhciBiYWNrIGVhY2ggb25lIG5lZWRzIHRvIGJlIGZp eGVkLgo+IAo+IFJlZ2FyZHMsCj4gQW5kcmVhcwo+IAoKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: narmstrong@baylibre.com (Neil Armstrong) Date: Wed, 18 Jan 2017 11:57:22 +0100 Subject: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> References: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com> <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com> <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: narmstrong@baylibre.com (Neil Armstrong) Date: Wed, 18 Jan 2017 11:57:22 +0100 Subject: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> References: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com> <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com> <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Message-ID: To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org 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 >