[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

So far, the stress-ng tool for instance quickly resulted in a silent
freeze of the system with no prior notice on a serial console when
running its filesystem or memory stressor classes.

Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
kernel.panic=10) configured, the system would neither reboot nor
would the OOM killer get any chance to otherwise do its job.

The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
several hours, the OOM killer was able to kill processes again and if
configured would successfully trigger a reboot of the system.

Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
(5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
+ USB DTS patches)
---
 arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da..d75a5b5 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -83,6 +83,18 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		/* 2 MiB reserved for Hardware ROM Firmware? */
+		hwrom@0 {
+			reg = <0x0 0x200000>;
+			no-map;
+		};
+	};
+
 	scu@c4300000 {
 		compatible = "arm,cortex-a5-scu";
 		reg = <0xc4300000 0x100>;
-- 
2.1.4

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

So far, the stress-ng tool for instance quickly resulted in a silent
freeze of the system with no prior notice on a serial console when
running its filesystem or memory stressor classes.

Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
kernel.panic=10) configured, the system would neither reboot nor
would the OOM killer get any chance to otherwise do its job.

The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
several hours, the OOM killer was able to kill processes again and if
configured would successfully trigger a reboot of the system.

Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus Lüssing <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>

---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
(5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
+ USB DTS patches)
---
 arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da..d75a5b5 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -83,6 +83,18 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		/* 2 MiB reserved for Hardware ROM Firmware? */
+		hwrom@0 {
+			reg = <0x0 0x200000>;
+			no-map;
+		};
+	};
+
 	scu@c4300000 {
 		compatible = "arm,cortex-a5-scu";
 		reg = <0xc4300000 0x100>;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

So far, the stress-ng tool for instance quickly resulted in a silent
freeze of the system with no prior notice on a serial console when
running its filesystem or memory stressor classes.

Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
kernel.panic=10) configured, the system would neither reboot nor
would the OOM killer get any chance to otherwise do its job.

The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
several hours, the OOM killer was able to kill processes again and if
configured would successfully trigger a reboot of the system.

Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>

---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
(5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
+ USB DTS patches)
---
 arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da..d75a5b5 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -83,6 +83,18 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		/* 2 MiB reserved for Hardware ROM Firmware? */
+		hwrom at 0 {
+			reg = <0x0 0x200000>;
+			no-map;
+		};
+	};
+
 	scu at c4300000 {
 		compatible = "arm,cortex-a5-scu";
 		reg = <0xc4300000 0x100>;
-- 
2.1.4

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

So far, the stress-ng tool for instance quickly resulted in a silent
freeze of the system with no prior notice on a serial console when
running its filesystem or memory stressor classes.

Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
kernel.panic=10) configured, the system would neither reboot nor
would the OOM killer get any chance to otherwise do its job.

The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
several hours, the OOM killer was able to kill processes again and if
configured would successfully trigger a reboot of the system.

Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>

---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
(5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
+ USB DTS patches)
---
 arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da..d75a5b5 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -83,6 +83,18 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		/* 2 MiB reserved for Hardware ROM Firmware? */
+		hwrom at 0 {
+			reg = <0x0 0x200000>;
+			no-map;
+		};
+	};
+
 	scu at c4300000 {
 		compatible = "arm,cortex-a5-scu";
 		reg = <0xc4300000 0x100>;
-- 
2.1.4

Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Martin Blumenstingl]

On Mon, Oct 2, 2017 at 5:59 PM, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

>
> ---
> The following stress-ng command worked fine now:
> $ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
> (5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
> + USB DTS patches)
> ---
>  arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da..d75a5b5 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -83,6 +83,18 @@
>                 };
>         };
>
> +       reserved-memory {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               /* 2 MiB reserved for Hardware ROM Firmware? */
> +               hwrom@0 {
> +                       reg = <0x0 0x200000>;
> +                       no-map;
> +               };
> +       };
> +
>         scu@c4300000 {
>                 compatible = "arm,cortex-a5-scu";
>                 reg = <0xc4300000 0x100>;
> --
> 2.1.4
>

Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Martin Blumenstingl]

On Mon, Oct 2, 2017 at 5:59 PM, Linus Lüssing <linus.luessing-djzkFPsfvsg@public.gmane.orge> wrote:
> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus Lüssing <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>
Acked-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

>
> ---
> The following stress-ng command worked fine now:
> $ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
> (5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
> + USB DTS patches)
> ---
>  arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da..d75a5b5 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -83,6 +83,18 @@
>                 };
>         };
>
> +       reserved-memory {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               /* 2 MiB reserved for Hardware ROM Firmware? */
> +               hwrom@0 {
> +                       reg = <0x0 0x200000>;
> +                       no-map;
> +               };
> +       };
> +
>         scu@c4300000 {
>                 compatible = "arm,cortex-a5-scu";
>                 reg = <0xc4300000 0x100>;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Martin Blumenstingl]

On Mon, Oct 2, 2017 at 5:59 PM, Linus L?ssing <linus.luessing@c0d3.blue> wrote:
> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

>
> ---
> The following stress-ng command worked fine now:
> $ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
> (5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
> + USB DTS patches)
> ---
>  arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da..d75a5b5 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -83,6 +83,18 @@
>                 };
>         };
>
> +       reserved-memory {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               /* 2 MiB reserved for Hardware ROM Firmware? */
> +               hwrom at 0 {
> +                       reg = <0x0 0x200000>;
> +                       no-map;
> +               };
> +       };
> +
>         scu at c4300000 {
>                 compatible = "arm,cortex-a5-scu";
>                 reg = <0xc4300000 0x100>;
> --
> 2.1.4
>

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Martin Blumenstingl]

On Mon, Oct 2, 2017 at 5:59 PM, Linus L?ssing <linus.luessing@c0d3.blue> wrote:
> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

>
> ---
> The following stress-ng command worked fine now:
> $ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
> (5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
> + USB DTS patches)
> ---
>  arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da..d75a5b5 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -83,6 +83,18 @@
>                 };
>         };
>
> +       reserved-memory {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               /* 2 MiB reserved for Hardware ROM Firmware? */
> +               hwrom at 0 {
> +                       reg = <0x0 0x200000>;
> +                       no-map;
> +               };
> +       };
> +
>         scu at c4300000 {
>                 compatible = "arm,cortex-a5-scu";
>                 reg = <0xc4300000 0x100>;
> --
> 2.1.4
>

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Emiliano Ingrassia]

Hi Martin, Hi Linus,

I executed the test listed by Linus in [0] on my Odroid-C1+, using a
clean 4.14-rc3 kernel with USB patch only (without the proposed patch).
All tests completed succesfully and I didn't experiment any hang.
Regarding the fault mentioned in [1], I think that it could be related
to a bad rootfs. I experimented something similar and reported it to
Martin the past summer [2].

On Mon, Oct 02, 2017 at 08:39:30PM +0200, Martin Blumenstingl wrote:
> On Mon, Oct 2, 2017 at 5:59 PM, Linus L?ssing <linus.luessing@c0d3.blue> wrote:
> > So far, the stress-ng tool for instance quickly resulted in a silent
> > freeze of the system with no prior notice on a serial console when
> > running its filesystem or memory stressor classes.
> >
> > Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> > kernel.panic=10) configured, the system would neither reboot nor
> > would the OOM killer get any chance to otherwise do its job.
> >
> > The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB

Reading the code in [3], it seems to me that the 2MB offset indicates
where the DDR first address is mapped in the CPUs addressing space.
In particular, it seems that DDR address 0 is mapped on CPU physical
address 0x200000 and that memory spans for 1GB (0x40000000).
As you argued, probably the first 2MB serve to address the ROM firmware
in the SoC.

However, the stress-ng tests succesfully completed also using this
patch.

Thank you for your work!

Best regards,

Emiliano

[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-September/004775.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-September/004803.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2017-July/004468.html
[3] https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/of/fdt.c#L847-L854

> > reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> > several hours, the OOM killer was able to kill processes again and if
> > configured would successfully trigger a reboot of the system.
> >
> > Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> > Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>
> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> 
> >
> > ---
> > The following stress-ng command worked fine now:
> > $ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --metrics
> > (5 hours runtime, tested on an Odroid C1+ with an 4.14-rc1 kernel + SMP
> > + USB DTS patches)
> > ---
> >  arch/arm/boot/dts/meson8b.dtsi | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> > index bc278da..d75a5b5 100644
> > --- a/arch/arm/boot/dts/meson8b.dtsi
> > +++ b/arch/arm/boot/dts/meson8b.dtsi
> > @@ -83,6 +83,18 @@
> >                 };
> >         };
> >
> > +       reserved-memory {
> > +               #address-cells = <1>;
> > +               #size-cells = <1>;
> > +               ranges;
> > +
> > +               /* 2 MiB reserved for Hardware ROM Firmware? */
> > +               hwrom at 0 {
> > +                       reg = <0x0 0x200000>;
> > +                       no-map;
> > +               };
> > +       };
> > +
> >         scu at c4300000 {
> >                 compatible = "arm,cortex-a5-scu";
> >                 reg = <0xc4300000 0x100>;
> > --
> > 2.1.4
> >
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

Hi Emiliano,

On Tue, Oct 03, 2017 at 01:47:55AM +0200, Emiliano Ingrassia wrote:
> I executed the test listed by Linus in [0] on my Odroid-C1+, using a
> clean 4.14-rc3 kernel with USB patch only (without the proposed patch).
> All tests completed succesfully and I didn't experiment any hang.

Thanks for testing! Could you also try some memory related tests
with stress-ng? For instance:

* stress-ng -v -t 120s --vm 4
* stress-ng -v -t 120s --malloc 4
* stress-ng -v -t 120s --bigheap 4

Does the OOM killer work for you there?

Cheers, Linus

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Emiliano Ingrassia]

Hi Linus,

On Tue, Oct 03, 2017 at 09:27:03AM +0200, Linus L?ssing wrote:
> Hi Emiliano,
> 
> On Tue, Oct 03, 2017 at 01:47:55AM +0200, Emiliano Ingrassia wrote:
> > I executed the test listed by Linus in [0] on my Odroid-C1+, using a
> > clean 4.14-rc3 kernel with USB patch only (without the proposed patch).
> > All tests completed succesfully and I didn't experiment any hang.
> 
> Thanks for testing! Could you also try some memory related tests
> with stress-ng? For instance:
> 
> * stress-ng -v -t 120s --vm 4
> * stress-ng -v -t 120s --malloc 4
> * stress-ng -v -t 120s --bigheap 4
>

I just completed those tests succesfully. See [0].

> Does the OOM killer work for you there?
> 

It seems that OOM killer worked correctly [1].

> Cheers, Linus

Regards,

Emiliano

[0]:
~# stress-ng -v -t 120s --vm 4
stress-ng: debug: [429] 1 processor online, 4 processors configured
stress-ng: info:  [429] dispatching hogs: 4 vm
stress-ng: debug: [429] /sys/devices/system/cpu/cpu0/cache does not exist
stress-ng: info:  [429] cache allocate: using built-in defaults as unable to determine cache details
stress-ng: debug: [429] cache allocate: default cache size: 2048K
stress-ng: debug: [429] starting stressors
stress-ng: debug: [429] 4 stressors spawned
stress-ng: debug: [433] stress-ng-vm: started [433] (instance 3)
stress-ng: debug: [432] stress-ng-vm: started [432] (instance 2)
stress-ng: debug: [431] stress-ng-vm: started [431] (instance 1)
stress-ng: debug: [432] stress-ng-vm using method 'all'
stress-ng: debug: [430] stress-ng-vm: started [430] (instance 0)
stress-ng: debug: [433] stress-ng-vm using method 'all'
stress-ng: debug: [431] stress-ng-vm using method 'all'
stress-ng: debug: [430] stress-ng-vm using method 'all'
stress-ng: debug: [432] stress-ng-vm: exited [432] (instance 2)
stress-ng: debug: [431] stress-ng-vm: exited [431] (instance 1)
stress-ng: debug: [433] stress-ng-vm: exited [433] (instance 3)
stress-ng: debug: [430] stress-ng-vm: exited [430] (instance 0)
stress-ng: debug: [429] process [430] terminated
stress-ng: debug: [429] process [431] terminated
stress-ng: debug: [429] process [432] terminated
stress-ng: debug: [429] process [433] terminated
stress-ng: info:  [429] successful run completed in 120.07s (2 mins, 0.07 secs)
~# stress-ng -v -t 120s --malloc 4
stress-ng: debug: [438] 1 processor online, 4 processors configured
stress-ng: info:  [438] dispatching hogs: 4 malloc
stress-ng: debug: [438] /sys/devices/system/cpu/cpu0/cache does not exist
stress-ng: info:  [438] cache allocate: using built-in defaults as unable to determine cache details
stress-ng: debug: [438] cache allocate: default cache size: 2048K
stress-ng: debug: [438] starting stressors
stress-ng: debug: [438] 4 stressors spawned
stress-ng: debug: [442] stress-ng-malloc: started [442] (instance 3)
stress-ng: debug: [441] stress-ng-malloc: started [441] (instance 2)
stress-ng: debug: [440] stress-ng-malloc: started [440] (instance 1)
stress-ng: debug: [439] stress-ng-malloc: started [439] (instance 0)
stress-ng: debug: [442] stress-ng-malloc: exited [442] (instance 3)
stress-ng: debug: [441] stress-ng-malloc: exited [441] (instance 2)
stress-ng: debug: [440] stress-ng-malloc: exited [440] (instance 1)
stress-ng: debug: [439] stress-ng-malloc: exited [439] (instance 0)
stress-ng: debug: [438] process [439] terminated
stress-ng: debug: [438] process [440] terminated
stress-ng: debug: [438] process [441] terminated
stress-ng: debug: [438] process [442] terminated
stress-ng: info:  [438] successful run completed in 120.17s (2 mins, 0.17 secs)
~# stress-ng -v -t 120s --bigheap 4
stress-ng: debug: [447] 1 processor online, 4 processors configured
stress-ng: info:  [447] dispatching hogs: 4 bigheap
stress-ng: debug: [447] /sys/devices/system/cpu/cpu0/cache does not exist
stress-ng: info:  [447] cache allocate: using built-in defaults as unable to determine cache details
stress-ng: debug: [447] cache allocate: default cache size: 2048K
stress-ng: debug: [447] starting stressors
stress-ng: debug: [447] 4 stressors spawned
stress-ng: debug: [451] stress-ng-bigheap: started [451] (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: started [450] (instance 2)
stress-ng: debug: [449] stress-ng-bigheap: started [449] (instance 1)
stress-ng: debug: [448] stress-ng-bigheap: started [448] (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: child died: signal 9 (Killed) (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 0)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 143616 MB (instance 0)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 1285632 MB (instance 2)
stress-ng: debug: [453] stress-ng-bigheap: out of memory at 1283072 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 1104384 MB (instance 0)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 922880 MB (instance 2)
stress-ng: debug: [453] stress-ng-bigheap: out of memory at 890880 MB (instance 3)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1087488 MB (instance 1)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 983552 MB (instance 0)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 1015552 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 983552 MB (instance 1)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 1089024 MB (instance 3)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 979200 MB (instance 0)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 967424 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 970496 MB (instance 1)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 993280 MB (instance 1)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 987136 MB (instance 3)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 1010688 MB (instance 2)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 1011712 MB (instance 0)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 991488 MB (instance 3)
stress-ng: debug: [452] stress-ng-bigheap: out of memory at 1001728 MB (instance 2)
stress-ng: debug: [456] stress-ng-bigheap: out of memory at 989440 MB (instance 0)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1021696 MB (instance 1)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 987392 MB (instance 1)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 996608 MB (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 628992 MB (instance 1)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 646912 MB (instance 3)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 786688 MB (instance 2)
stress-ng: debug: [448] stress-ng-bigheap: child died: signal 9 (Killed) (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 0)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 983552 MB (instance 2)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 997888 MB (instance 3)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 991744 MB (instance 1)
stress-ng: debug: [448] stress-ng-bigheap: child died: signal 9 (Killed) (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 0)
stress-ng: debug: [458] stress-ng-bigheap: out of memory at 965888 MB (instance 3)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 973568 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 963328 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1102080 MB (instance 0)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 983552 MB (instance 0)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1008384 MB (instance 1)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 992512 MB (instance 2)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 945920 MB (instance 1)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 961792 MB (instance 2)
stress-ng: debug: [462] stress-ng-bigheap: out of memory at 1118464 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 978432 MB (instance 0)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 994816 MB (instance 1)
stress-ng: debug: [462] stress-ng-bigheap: out of memory at 988416 MB (instance 3)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 1010688 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1010944 MB (instance 0)
stress-ng: debug: [462] stress-ng-bigheap: out of memory at 1001472 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1001984 MB (instance 0)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1012992 MB (instance 1)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 989184 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 992512 MB (instance 1)
stress-ng: debug: [462] stress-ng-bigheap: out of memory at 990720 MB (instance 3)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 1009152 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1011200 MB (instance 0)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 987904 MB (instance 0)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 1001728 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1004032 MB (instance 1)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 975616 MB (instance 2)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 976384 MB (instance 1)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 1090304 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 963840 MB (instance 0)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 983296 MB (instance 3)
stress-ng: debug: [457] stress-ng-bigheap: out of memory at 1002496 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1007360 MB (instance 0)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 1009152 MB (instance 2)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 987136 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 994560 MB (instance 0)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 1011200 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [459] stress-ng-bigheap: out of memory at 966400 MB (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 962560 MB (instance 3)
stress-ng: debug: [464] stress-ng-bigheap: out of memory at 1113344 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 964096 MB (instance 0)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 999680 MB (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [466] stress-ng-bigheap: out of memory at 493056 MB (instance 2)
stress-ng: debug: [464] stress-ng-bigheap: out of memory at 1588992 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1631232 MB (instance 0)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 293376 MB (instance 3)
stress-ng: debug: [464] stress-ng-bigheap: out of memory at 910336 MB (instance 1)
stress-ng: debug: [466] stress-ng-bigheap: out of memory at 1089792 MB (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 1120000 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 884992 MB (instance 0)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 983552 MB (instance 0)
stress-ng: debug: [466] stress-ng-bigheap: out of memory at 988416 MB (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 989952 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 1121792 MB (instance 1)
stress-ng: debug: [466] stress-ng-bigheap: out of memory at 959744 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 959488 MB (instance 0)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 964608 MB (instance 3)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 991488 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1011200 MB (instance 0)
stress-ng: debug: [466] stress-ng-bigheap: out of memory at 993280 MB (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 1008128 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 987136 MB (instance 0)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 1012992 MB (instance 1)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 991744 MB (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 957696 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 958976 MB (instance 0)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 1106176 MB (instance 2)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 983296 MB (instance 3)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 994048 MB (instance 2)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 1007104 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 999168 MB (instance 0)
stress-ng: debug: [463] stress-ng-bigheap: out of memory at 1003776 MB (instance 3)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 998656 MB (instance 1)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 1008128 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 986368 MB (instance 0)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 968448 MB (instance 0)
stress-ng: debug: [467] stress-ng-bigheap: out of memory at 966656 MB (instance 1)
stress-ng: debug: [469] stress-ng-bigheap: out of memory at 1117952 MB (instance 3)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 953088 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1008896 MB (instance 0)
stress-ng: debug: [469] stress-ng-bigheap: out of memory at 991744 MB (instance 3)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 983296 MB (instance 2)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 960000 MB (instance 0)
stress-ng: debug: [469] stress-ng-bigheap: out of memory at 962048 MB (instance 3)
stress-ng: debug: [470] stress-ng-bigheap: out of memory at 1115648 MB (instance 1)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 967936 MB (instance 2)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 1014784 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 992512 MB (instance 0)
stress-ng: debug: [470] stress-ng-bigheap: out of memory at 983808 MB (instance 1)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 1101056 MB (instance 3)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 963840 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 968448 MB (instance 0)
stress-ng: debug: [470] stress-ng-bigheap: out of memory at 972544 MB (instance 1)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 987136 MB (instance 3)
stress-ng: debug: [470] stress-ng-bigheap: out of memory at 997376 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1009408 MB (instance 0)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 1011200 MB (instance 2)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 957184 MB (instance 2)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [468] stress-ng-bigheap: out of memory at 325632 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1556736 MB (instance 0)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 1662976 MB (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 461056 MB (instance 1)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1112064 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 902144 MB (instance 0)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 876032 MB (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 980736 MB (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 939264 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 983296 MB (instance 0)
stress-ng: debug: [473] stress-ng-bigheap: out of memory at 1102080 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 993280 MB (instance 0)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1009152 MB (instance 1)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 1019392 MB (instance 3)
stress-ng: debug: [473] stress-ng-bigheap: out of memory at 983296 MB (instance 2)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 986880 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1008640 MB (instance 0)
stress-ng: debug: [473] stress-ng-bigheap: out of memory at 995584 MB (instance 2)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1012480 MB (instance 1)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 1004800 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 986368 MB (instance 0)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1004544 MB (instance 1)
stress-ng: debug: [473] stress-ng-bigheap: out of memory at 1010688 MB (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [474] stress-ng-bigheap: out of memory at 151040 MB (instance 2)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 1293312 MB (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1291008 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1270016 MB (instance 0)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 948224 MB (instance 0)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 951552 MB (instance 1)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 958720 MB (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 976384 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 971776 MB (instance 0)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 1091840 MB (instance 2)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 966144 MB (instance 3)
stress-ng: debug: [471] stress-ng-bigheap: out of memory at 990976 MB (instance 3)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 988416 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1010944 MB (instance 0)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1012224 MB (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 1007616 MB (instance 2)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 997888 MB (instance 1)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1942784 MB (instance 0)
stress-ng: debug: [476] stress-ng-bigheap: out of memory at 786688 MB (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 638720 MB (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 637696 MB (instance 2)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1042176 MB (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 1039616 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 865280 MB (instance 0)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 958464 MB (instance 1)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 1108736 MB (instance 3)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 983296 MB (instance 0)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 954880 MB (instance 2)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 1011456 MB (instance 0)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 994816 MB (instance 2)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 983552 MB (instance 3)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1013760 MB (instance 1)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 1011712 MB (instance 3)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 987392 MB (instance 2)
stress-ng: debug: [472] stress-ng-bigheap: out of memory at 1012480 MB (instance 1)
stress-ng: debug: [461] stress-ng-bigheap: out of memory at 994560 MB (instance 0)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 1008384 MB (instance 2)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 1002752 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 628224 MB (instance 3)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 623872 MB (instance 2)
stress-ng: debug: [478] stress-ng-bigheap: out of memory at 786944 MB (instance 1)
stress-ng: debug: [448] stress-ng-bigheap: child died: signal 9 (Killed) (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 0)
stress-ng: debug: [478] stress-ng-bigheap: out of memory at 983296 MB (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 985600 MB (instance 2)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 983296 MB (instance 3)
stress-ng: debug: [448] stress-ng-bigheap: child died: signal 9 (Killed) (instance 0)
stress-ng: debug: [448] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 0)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 972288 MB (instance 3)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 962560 MB (instance 2)
stress-ng: debug: [478] stress-ng-bigheap: out of memory at 979200 MB (instance 1)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1091328 MB (instance 0)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 1003264 MB (instance 2)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1001984 MB (instance 0)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 994816 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [481] stress-ng-bigheap: out of memory at 1093376 MB (instance 1)
stress-ng: debug: [475] stress-ng-bigheap: out of memory at 963840 MB (instance 2)
stress-ng: debug: [477] stress-ng-bigheap: out of memory at 974080 MB (instance 3)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 974592 MB (instance 0)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [482] stress-ng-bigheap: out of memory at 170752 MB (instance 3)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1280768 MB (instance 0)
stress-ng: debug: [481] stress-ng-bigheap: out of memory at 1272576 MB (instance 1)
stress-ng: debug: [450] stress-ng-bigheap: child died: signal 9 (Killed) (instance 2)
stress-ng: debug: [450] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 2)
stress-ng: debug: [481] stress-ng-bigheap: out of memory at 898304 MB (instance 1)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [484] stress-ng-bigheap: out of memory at 514304 MB (instance 3)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1506048 MB (instance 0)
stress-ng: debug: [481] stress-ng-bigheap: out of memory at 374272 MB (instance 1)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 1610496 MB (instance 2)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 901632 MB (instance 2)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 924160 MB (instance 0)
stress-ng: debug: [484] stress-ng-bigheap: out of memory at 1081344 MB (instance 3)
stress-ng: debug: [449] stress-ng-bigheap: child died: signal 9 (Killed) (instance 1)
stress-ng: debug: [449] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 1)
stress-ng: debug: [485] stress-ng-bigheap: out of memory at 1114880 MB (instance 1)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 981760 MB (instance 0)
stress-ng: debug: [484] stress-ng-bigheap: out of memory at 928000 MB (instance 3)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 980992 MB (instance 2)
stress-ng: debug: [485] stress-ng-bigheap: out of memory at 983296 MB (instance 1)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 1007616 MB (instance 2)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 989440 MB (instance 0)
stress-ng: debug: [484] stress-ng-bigheap: out of memory at 1024000 MB (instance 3)
stress-ng: debug: [484] stress-ng-bigheap: out of memory at 986112 MB (instance 3)
stress-ng: debug: [485] stress-ng-bigheap: out of memory at 996864 MB (instance 1)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 1011456 MB (instance 2)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1011456 MB (instance 0)
stress-ng: debug: [451] stress-ng-bigheap: child died: signal 9 (Killed) (instance 3)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 975104 MB (instance 2)
stress-ng: debug: [451] stress-ng-bigheap: assuming killed by OOM killer, restarting again (instance 3)
stress-ng: debug: [485] stress-ng-bigheap: out of memory at 1608704 MB (instance 1)
stress-ng: debug: [486] stress-ng-bigheap: out of memory at 478720 MB (instance 3)
stress-ng: debug: [480] stress-ng-bigheap: out of memory at 1605888 MB (instance 0)
stress-ng: debug: [483] stress-ng-bigheap: out of memory at 312832 MB (instance 2)
stress-ng: debug: [451] stress-ng-bigheap: OOM restarts: 10, SEGV restarts: 0, out of memory restarts: 0.
stress-ng: debug: [450] stress-ng-bigheap: OOM restarts: 7, SEGV restarts: 0, out of memory restarts: 0.
stress-ng: debug: [451] stress-ng-bigheap: exited [451] (instance 3)
stress-ng: debug: [450] stress-ng-bigheap: exited [450] (instance 2)
stress-ng: debug: [448] stress-ng-bigheap: OOM restarts: 5, SEGV restarts: 0, out of memory restarts: 0.
stress-ng: debug: [448] stress-ng-bigheap: exited [448] (instance 0)
stress-ng: debug: [447] process [448] terminated
stress-ng: debug: [449] stress-ng-bigheap: OOM restarts: 8, SEGV restarts: 0, out of memory restarts: 0.
stress-ng: debug: [449] stress-ng-bigheap: exited [449] (instance 1)
stress-ng: debug: [447] process [449] terminated
stress-ng: debug: [447] process [450] terminated
stress-ng: debug: [447] process [451] terminated
stress-ng: info:  [447] successful run completed in 120.13s (2 mins, 0.13 secs)
~#

[1]:
[  477.065321] stress-ng-bighe invoked oom-killer: gfp_mask=0x14201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=(null),  order=0, oom_score_adj=1000
[  477.065350] CPU: 0 PID: 484 Comm: stress-ng-bighe Not tainted 4.14.0-rc3+ #1
[  477.065353] Hardware name: Amlogic Meson platform
[  477.065386] [<c010f18c>] (unwind_backtrace) from [<c010c4e8>] (show_stack+0x10/0x14)
[  477.065406] [<c010c4e8>] (show_stack) from [<c0597224>] (dump_stack+0x94/0xa8)
[  477.065424] [<c0597224>] (dump_stack) from [<c01b3804>] (dump_header+0x90/0x1c8)
[  477.065435] [<c01b3804>] (dump_header) from [<c01b2ff8>] (oom_kill_process+0x3f8/0x484)
[  477.065444] [<c01b2ff8>] (oom_kill_process) from [<c01b33c4>] (out_of_memory+0xfc/0x42c)
[  477.065456] [<c01b33c4>] (out_of_memory) from [<c01b7b5c>] (__alloc_pages_nodemask+0xcac/0xdd4)
[  477.065466] [<c01b7b5c>] (__alloc_pages_nodemask) from [<c01afbac>] (filemap_fault+0x4d8/0x600)
[  477.065478] [<c01afbac>] (filemap_fault) from [<c0286134>] (ext4_filemap_fault+0x28/0x3c)
[  477.065495] [<c0286134>] (ext4_filemap_fault) from [<c01d54b4>] (__do_fault+0x18/0x64)
[  477.065508] [<c01d54b4>] (__do_fault) from [<c01d82cc>] (handle_mm_fault+0x540/0xe5c)
[  477.065525] [<c01d82cc>] (handle_mm_fault) from [<c0113698>] (do_page_fault+0x244/0x310)
[  477.065538] [<c0113698>] (do_page_fault) from [<c01013b0>] (do_PrefetchAbort+0x44/0xbc)
[  477.065547] [<c01013b0>] (do_PrefetchAbort) from [<c010d748>] (ret_from_exception+0x0/0x18)
[  477.065551] Exception stack(0xee5fffb0 to 0xee5ffff8)
[  477.065559] ffa0:                                     10400028 00020000 fffff000 00021000
[  477.065568] ffc0: 001a9bd0 10400008 ae200010 ae200468 ae200000 10401000 001aa0b8 00020b98
[  477.065575] ffe0: 00000000 bed4bf38 000d52a8 000d3858 200f0010 ffffffff
[  477.065585] Mem-Info:
[  477.065602] active_anon:251474 inactive_anon:700 isolated_anon:0
                active_file:24 inactive_file:35 isolated_file:0
                unevictable:4 dirty:0 writeback:0 unstable:0
                slab_reclaimable:440 slab_unreclaimable:908
                mapped:540 shmem:707 pagetables:634 bounce:0
                free:2679 free_pcp:115 free_cma:37
[  477.065614] Node 0 active_anon:1005896kB inactive_anon:2800kB active_file:96kB inactive_file:140kB unevictable:16kB isolated(anon):0kB isolated(file):0kB mapped:2160kB dirty:0kB writeback:0kB shmem:2828kB writeback_tmp:0kB unstable:0ko
[  477.065631] Normal free:10568kB min:3504kB low:4380kB high:5256kB active_anon:747400kB inactive_anon:0kB active_file:100kB inactive_file:212kB unevictable:0kB writepending:0kB present:786432kB managed:769308kB mlocked:0kB kernel_stackB
[  477.065633] lowmem_reserve[]: 0 1856 1856
[  477.065654] HighMem free:148kB min:232kB low:500kB high:768kB active_anon:258496kB inactive_anon:2800kB active_file:4kB inactive_file:0kB unevictable:16kB writepending:0kB present:262144kB managed:262144kB mlocked:16kB kernel_stack:0kB
[  477.065656] lowmem_reserve[]: 0 0 0
[  477.065665] Normal: 70*4kB (UME) 60*8kB (UME) 39*16kB (UE) 15*32kB (ME) 12*64kB (E) 8*128kB (UE) 3*256kB (UE) 4*512kB (UE) 2*1024kB (UM) 1*2048kB (E) 0*4096kB = 10568kB
[  477.065717] HighMem: 1*4kB (C) 0*8kB 1*16kB (C) 0*32kB 0*64kB 1*128kB (C) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 148kB
[  477.065753] 777 total pagecache pages
[  477.065756] 262144 pages RAM
[  477.065758] 65536 pages HighMem/MovableOnly
[  477.065761] 4281 pages reserved
[  477.065763] 6144 pages cma reserved
[  477.065767] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[  477.065781] [  120]     0   120     2945      246       7       0        0         -1000 udevd
[  477.065788] [  232]     0   232      507       24       5       0        0             0 syslogd
[  477.065795] [  236]     0   236      472       16       5       0        0             0 klogd
[  477.065807] [  388]     0   388      593       26       5       0        0             0 crond
[  477.065814] [  396]     0   396      678       25       6       0        0             0 agetty
[  477.065821] [  397]     0   397      678       25       5       0        0             0 agetty
[  477.065828] [  398]     0   398      678       25       6       0        0             0 agetty
[  477.065835] [  399]     0   399      678       25       6       0        0             0 agetty
[  477.065842] [  400]     0   400      678       25       5       0        0             0 agetty
[  477.065848] [  401]     0   401      678       25       7       0        0             0 agetty
[  477.065855] [  402]     0   402     1336      136       7       0        0             0 bash
[  477.065863] [  447]     0   447     2598      552       9       0        0         -1000 stress-ng
[  477.065870] [  448]     0   448     2598       30       8       0        0         -1000 stress-ng-bighe
[  477.065878] [  449]     0   449     2598       30       8       0        0         -1000 stress-ng-bighe
[  477.065885] [  450]     0   450     2598       30       8       0        0         -1000 stress-ng-bighe
[  477.065893] [  451]     0   451     2598       30       8       0        0         -1000 stress-ng-bighe
[  477.065900] [  480]     0   480    64295    61500     129       0        0          1000 stress-ng-bighe
[  477.065907] [  483]     0   483    63783    60988     128       0        0          1000 stress-ng-bighe
[  477.065915] [  484]     0   484    69399    66573     138       0        0          1000 stress-ng-bighe
[  477.065922] [  485]     0   485    64295    61500     129       0        0          1000 stress-ng-bighe
[  477.065932] Out of memory: Kill process 484 (stress-ng-bighe) score 1247 or sacrifice child
[  477.065949] Killed process 484 (stress-ng-bighe) total-vm:277596kB, anon-rss:266284kB, file-rss:0kB, shmem-rss:8kB
[  477.185388] oom_reaper: reaped process 484 (stress-ng-bighe), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

On Tue, Oct 03, 2017 at 10:23:10AM +0200, Emiliano Ingrassia wrote:
> I just completed those tests succesfully. See [0].
> 
> > Does the OOM killer work for you there?
> > 
> 
> It seems that OOM killer worked correctly [1].

That looks good, indeed, weird. Would it be possible for you to
share the compiled, binary uImage/uInitrd/DTB-file and u-boot you
are using, which worked for you? I'd like to retry those on my
Odroid C1+.

Regards, Linus

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Emiliano Ingrassia]

Hi Linus,

On Tue, Oct 03, 2017 at 12:54:27PM +0200, Linus L?ssing wrote:
> On Tue, Oct 03, 2017 at 10:23:10AM +0200, Emiliano Ingrassia wrote:
> > I just completed those tests succesfully. See [0].
> > 
> > > Does the OOM killer work for you there?
> > > 
> > 
> > It seems that OOM killer worked correctly [1].
> 
> That looks good, indeed, weird. Would it be possible for you to
> share the compiled, binary uImage/uInitrd/DTB-file and u-boot you
> are using, which worked for you? I'd like to retry those on my
> Odroid C1+.

My configuration is:

- U-Boot odroidc-v2011.03 [0];
- kernel linux-stable 4.14-rc3 [1];
- Meson8b-odroidc1 USB patch [2], [3].

All compiled with gcc-4.9.4 cross compiler generated with
crosstool-ng 1.22.

Consider that I need to remove the line about address filtering
range in L2 cache node in meson8b.dtsi (arm,filter-ranges)
to boot linux. I think that something is already missing without
the full Martin's SMP patch. We discussed this point the past summer [4].
In this regard, are you experimenting the same issue ?

> Regards, Linus
> 

Regards,

Emiliano

[0] https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
[2] http://lists.infradead.org/pipermail/linux-amlogic/2017-September/004767.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2017-September/004749.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2017-July/004402.html

> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Kevin Hilman]

Linus Lüssing <linus.luessing@c0d3.blue> writes:

> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

Applied to v4.15/dt with Martin's Tested-by,

Thanks,

Kevin

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Kevin Hilman]

Linus L?ssing <linus.luessing@c0d3.blue> writes:

> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>

Applied to v4.15/dt with Martin's Tested-by,

Thanks,

Kevin

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Kevin Hilman]

Linus L?ssing <linus.luessing@c0d3.blue> writes:

> So far, the stress-ng tool for instance quickly resulted in a silent
> freeze of the system with no prior notice on a serial console when
> running its filesystem or memory stressor classes.
>
> Even with a panic-on-OOM and reboot-on-panic (vm.panic_on_oom=1,
> kernel.panic=10) configured, the system would neither reboot nor
> would the OOM killer get any chance to otherwise do its job.
>
> The Amlogic reference source code uses a 2MB PHYS_OFFSET. With these 2MB
> reserved via DT, stress-ng was able to run on an Odroid C1+ just fine for
> several hours, the OOM killer was able to kill processes again and if
> configured would successfully trigger a reboot of the system.
>
> Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
> Signed-off-by: Linus L?ssing <linus.luessing@c0d3.blue>

Applied to v4.15/dt with Martin's Tested-by,

Thanks,

Kevin

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

Hi Kevin,

Just wanted to let you know that Emiliano and I are currently
debugging further off-list.

So far I can reproduce that:

a) For the binary kernel image Emiliano sent me I can reproduce
his hang ups during boot on my Odroid C1+.
b) The 2MB reserved memory region this patch adds does not help
for this image.
c) Removing the "arm,filter-range" as proposed by Emiliano back
then instead of adding this reserved memory zone fixes my freezes
during boot in Emiliano's image and during stress-ng for my kernel
image, too.

I'm currently continuing to bisect which difference in Emiliano's
and my kernel image makes mine boot successfully but not
Emiliano's. (And I'm continuing reading and testing with the
filter-range option to better understand what it's presence - or
absence - does exactly)


If these observations ring a bell for anyone here, I'd be curious
to hear what they think.

Regards, Linus

Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)

I found the difference between Emiliano's and my kernel image and
could narrow it down to this particular difference via bisecting:

Using the multi_v7_defconfig target, but with the following
two options unselected:

* System Type
  -> Qualcomm Support
     - Enable support for MSM8X60 (disabled)
     - Enable support for MSM8960 (disabled)

Results in the following diff, according to ./scripts/diffconfig:

-CLKSRC_QCOM y
-MSM_IOMMU n
 ARCH_MSM8960 y -> n
 ARCH_MSM8X60 y -> n

Once this is unselected, the kernel hangs for me on boot, too.
Both with or without this 2MB reserved memory region patch.

Removing the "arm,filter-ranges" as tried by Emiliano makes it
boot again.

Finally, what also helps booting again is this diff from the
pending SMP support patch series from Carlo/Martin [0]:

~~~~~
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..82faa958ab88 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@  textofs-$(CONFIG_SA1111) := 0x00208000
 endif
 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
~~~~~

Note the $(CONFIG_ARCH_MSM8X60) and $(CONFIG_ARCH_MSM8960) just
above. Sounds familiar :-)?

With this textofs diff alone, stress-ng still hangs though. Only
with the 2MB memory zone reserved via DT or the "arm,filter-ranges"
removed, stress-ng succeeds, too.

Regards, Linus

[0]: "[v7,4/6] ARM: meson: Add SMP bringup code for Meson8 and Meson8b"
     -> https://patchwork.kernel.org/patch/9954935/


On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> Subject: Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes
> To: Kevin Hilman <khilman@baylibre.com>
> Cc: Carlo Caione <carlo@caione.org>, Kevin Hilman <khilman@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Emiliano Ingrassia <ingrassia@epigenesys.com>, linux-amlogic@lists.infradead.org
> 
> Hi Kevin,
> 
> Just wanted to let you know that Emiliano and I are currently
> debugging further off-list.
> 
> So far I can reproduce that:
> 
> a) For the binary kernel image Emiliano sent me I can reproduce
> his hang ups during boot on my Odroid C1+.
> b) The 2MB reserved memory region this patch adds does not help
> for this image.
> c) Removing the "arm,filter-range" as proposed by Emiliano back
> then instead of adding this reserved memory zone fixes my freezes
> during boot in Emiliano's image and during stress-ng for my kernel
> image, too.
> 
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)
> 
> 
> If these observations ring a bell for anyone here, I'd be curious
> to hear what they think.
> 
> Regards, Linus
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)

I found the difference between Emiliano's and my kernel image and
could narrow it down to this particular difference via bisecting:

Using the multi_v7_defconfig target, but with the following
two options unselected:

* System Type
  -> Qualcomm Support
     - Enable support for MSM8X60 (disabled)
     - Enable support for MSM8960 (disabled)

Results in the following diff, according to ./scripts/diffconfig:

-CLKSRC_QCOM y
-MSM_IOMMU n
 ARCH_MSM8960 y -> n
 ARCH_MSM8X60 y -> n

Once this is unselected, the kernel hangs for me on boot, too.
Both with or without this 2MB reserved memory region patch.

Removing the "arm,filter-ranges" as tried by Emiliano makes it
boot again.

Finally, what also helps booting again is this diff from the
pending SMP support patch series from Carlo/Martin [0]:

~~~~~
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..82faa958ab88 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@  textofs-$(CONFIG_SA1111) := 0x00208000
 endif
 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
~~~~~

Note the $(CONFIG_ARCH_MSM8X60) and $(CONFIG_ARCH_MSM8960) just
above. Sounds familiar :-)?

With this textofs diff alone, stress-ng still hangs though. Only
with the 2MB memory zone reserved via DT or the "arm,filter-ranges"
removed, stress-ng succeeds, too.

Regards, Linus

[0]: "[v7,4/6] ARM: meson: Add SMP bringup code for Meson8 and Meson8b"
     -> https://patchwork.kernel.org/patch/9954935/


On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> Subject: Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes
> To: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Cc: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>, Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>, Emiliano Ingrassia <ingrassia-rBIjXPeIPFWU+1/U8MakDg@public.gmane.org>, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> 
> Hi Kevin,
> 
> Just wanted to let you know that Emiliano and I are currently
> debugging further off-list.
> 
> So far I can reproduce that:
> 
> a) For the binary kernel image Emiliano sent me I can reproduce
> his hang ups during boot on my Odroid C1+.
> b) The 2MB reserved memory region this patch adds does not help
> for this image.
> c) Removing the "arm,filter-range" as proposed by Emiliano back
> then instead of adding this reserved memory zone fixes my freezes
> during boot in Emiliano's image and during stress-ng for my kernel
> image, too.
> 
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)
> 
> 
> If these observations ring a bell for anyone here, I'd be curious
> to hear what they think.
> 
> Regards, Linus
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus L?ssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)

I found the difference between Emiliano's and my kernel image and
could narrow it down to this particular difference via bisecting:

Using the multi_v7_defconfig target, but with the following
two options unselected:

* System Type
  -> Qualcomm Support
     - Enable support for MSM8X60 (disabled)
     - Enable support for MSM8960 (disabled)

Results in the following diff, according to ./scripts/diffconfig:

-CLKSRC_QCOM y
-MSM_IOMMU n
 ARCH_MSM8960 y -> n
 ARCH_MSM8X60 y -> n

Once this is unselected, the kernel hangs for me on boot, too.
Both with or without this 2MB reserved memory region patch.

Removing the "arm,filter-ranges" as tried by Emiliano makes it
boot again.

Finally, what also helps booting again is this diff from the
pending SMP support patch series from Carlo/Martin [0]:

~~~~~
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..82faa958ab88 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@  textofs-$(CONFIG_SA1111) := 0x00208000
 endif
 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
~~~~~

Note the $(CONFIG_ARCH_MSM8X60) and $(CONFIG_ARCH_MSM8960) just
above. Sounds familiar :-)?

With this textofs diff alone, stress-ng still hangs though. Only
with the 2MB memory zone reserved via DT or the "arm,filter-ranges"
removed, stress-ng succeeds, too.

Regards, Linus

[0]: "[v7,4/6] ARM: meson: Add SMP bringup code for Meson8 and Meson8b"
     -> https://patchwork.kernel.org/patch/9954935/


On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus L?ssing wrote:
> Subject: Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes
> To: Kevin Hilman <khilman@baylibre.com>
> Cc: Carlo Caione <carlo@caione.org>, Kevin Hilman <khilman@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Emiliano Ingrassia <ingrassia@epigenesys.com>, linux-amlogic at lists.infradead.org
> 
> Hi Kevin,
> 
> Just wanted to let you know that Emiliano and I are currently
> debugging further off-list.
> 
> So far I can reproduce that:
> 
> a) For the binary kernel image Emiliano sent me I can reproduce
> his hang ups during boot on my Odroid C1+.
> b) The 2MB reserved memory region this patch adds does not help
> for this image.
> c) Removing the "arm,filter-range" as proposed by Emiliano back
> then instead of adding this reserved memory zone fixes my freezes
> during boot in Emiliano's image and during stress-ng for my kernel
> image, too.
> 
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)
> 
> 
> If these observations ring a bell for anyone here, I'd be curious
> to hear what they think.
> 
> Regards, Linus
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes

[Linus Lüssing]

On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus L?ssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)

I found the difference between Emiliano's and my kernel image and
could narrow it down to this particular difference via bisecting:

Using the multi_v7_defconfig target, but with the following
two options unselected:

* System Type
  -> Qualcomm Support
     - Enable support for MSM8X60 (disabled)
     - Enable support for MSM8960 (disabled)

Results in the following diff, according to ./scripts/diffconfig:

-CLKSRC_QCOM y
-MSM_IOMMU n
 ARCH_MSM8960 y -> n
 ARCH_MSM8X60 y -> n

Once this is unselected, the kernel hangs for me on boot, too.
Both with or without this 2MB reserved memory region patch.

Removing the "arm,filter-ranges" as tried by Emiliano makes it
boot again.

Finally, what also helps booting again is this diff from the
pending SMP support patch series from Carlo/Martin [0]:

~~~~~
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..82faa958ab88 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@  textofs-$(CONFIG_SA1111) := 0x00208000
 endif
 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
~~~~~

Note the $(CONFIG_ARCH_MSM8X60) and $(CONFIG_ARCH_MSM8960) just
above. Sounds familiar :-)?

With this textofs diff alone, stress-ng still hangs though. Only
with the 2MB memory zone reserved via DT or the "arm,filter-ranges"
removed, stress-ng succeeds, too.

Regards, Linus

[0]: "[v7,4/6] ARM: meson: Add SMP bringup code for Meson8 and Meson8b"
     -> https://patchwork.kernel.org/patch/9954935/


On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus L?ssing wrote:
> Subject: Re: [PATCH] ARM: dts: meson8b: add reserved memory zone to fix silent freezes
> To: Kevin Hilman <khilman@baylibre.com>
> Cc: Carlo Caione <carlo@caione.org>, Kevin Hilman <khilman@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Emiliano Ingrassia <ingrassia@epigenesys.com>, linux-amlogic at lists.infradead.org
> 
> Hi Kevin,
> 
> Just wanted to let you know that Emiliano and I are currently
> debugging further off-list.
> 
> So far I can reproduce that:
> 
> a) For the binary kernel image Emiliano sent me I can reproduce
> his hang ups during boot on my Odroid C1+.
> b) The 2MB reserved memory region this patch adds does not help
> for this image.
> c) Removing the "arm,filter-range" as proposed by Emiliano back
> then instead of adding this reserved memory zone fixes my freezes
> during boot in Emiliano's image and during stress-ng for my kernel
> image, too.
> 
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to better understand what it's presence - or
> absence - does exactly)
> 
> 
> If these observations ring a bell for anyone here, I'd be curious
> to hear what they think.
> 
> Regards, Linus
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic