Jump to content

Date changed to 1978,System crash,Mysql run 195% of CPU


arno-ppsspp

Recommended Posts

1 hour ago, denix said:

Are there some new information's? We use more than 1500 pcs of orange pc plus. There are similar problems with freeze and date change. Main difference is that changed date is 1979.

 

I'm just curious.. what do you use 1500 orange pc plus for?

Link to comment
Share on other sites

On 2/18/2020 at 4:00 AM, denix said:

Some bill printer device :)

Hi Denix, with regards to the "some bill printer device" you mentioned, are you referring to using device to control the receipt printer to print out receipt?
Or to make use of the device to intercept the receipt? 
We're currently looking for this kind of solution, if you don't mind, may we get in touch with you?

Link to comment
Share on other sites

On 3/3/2020 at 3:20 AM, Jasontan said:

Hi Denix, with regards to the "some bill printer device" you mentioned, are you referring to using device to control the receipt printer to print out receipt?
Or to make use of the device to intercept the receipt? 
We're currently looking for this kind of solution, if you don't mind, may we get in touch with you?

Reply in private message :)

Link to comment
Share on other sites

This remains a pretty serious issue.

 

Has anyone made any pertinent discoveries?

 

So far I've identified that boot time is unaffected, clock monotonic is getting incremented to the point of causing an overflow of the 32bit time number (hence 197x).

 

Currently suspecting timer inaccuracy during frequency changes or something similar. Although not able to replicate in a lab at all (only in field).

Link to comment
Share on other sites

I have the same problem. I use approx 200. pcs of orange pi zero. use the board to monitor our remote devices, but after the time changed to 1979,  the pi stopped working, ssh not working,  scheduled reboot in crontab not working., not getting dhcp IP address from the router. basiclly just dead.  Then I need drive 50 - 200 Km to fix the issue, really pain in the ass.  Raspberry Pi is good, never fail, but use too much power for Solar powered system. 

 

I tried some different version of armbian, found Buster has more change get the problem than Bionic. I currently using Bionic mainline based kernel 5.4.y for Nanopi Neo/Core on my Orange Pi zero Lts. I have 15 Pis with this version, no one has failed(40+ days).  Waiting on someone find out root cause and a permant solution. 

 

Link to comment
Share on other sites

4 hours ago, Sean Fei said:

  Raspberry Pi is good, never fail

 

You get what you pay for I guess...

 

 

Quote

tried some different version of armbian

All flavors (Focal, Bionic, Buster...) sharing the very same kernel package.

 

Did not follow up, maybe @Splitice can tell us about the mentioned patch if it worked and has been pushed to mainline.

Link to comment
Share on other sites

These are the 2 patches we ended up with. With thanks to everyone at on the linux-sunxi irc, particularly megi.

 

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

index 6b636362379e..ca55c2ae999d 100644

--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

@@ -23,15 +23,21 @@

#include "ccu-sun8i-h3.h"

-static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",

-                "osc24M", 0x000,

-                8, 5,  /* N */

-                4, 2,  /* K */

-                0, 2,  /* M */

-                16, 2, /* P */

-                BIT(31),   /* gate */

-                BIT(28),   /* lock */

-                CLK_SET_RATE_UNGATE);

+static struct ccu_nkmp pll_cpux_clk = {

+   .enable     = BIT(31),

+   .lock       = BIT(28),

+   .n      = _SUNXI_CCU_MULT(8, 5),

+   .k      = _SUNXI_CCU_MULT(4, 2),

+   .m      = _SUNXI_CCU_DIV_MAX(0, 2, 1),

+   .p      = _SUNXI_CCU_DIV_MAX(16, 2, 1),

+   .common     = {

+       .reg        = 0x000,

+       .hw.init    = CLK_HW_INIT("pll-cpux",

+                    "osc24M",

+                    &ccu_nkmp_ops,

+                    CLK_SET_RATE_UNGATE),

+   },

+};

/*

* The Audio PLL is supposed to have 4 outputs: 3 fixed factors from

 

 

 

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

index 5e7e9cccc172..609e889cae3c 100644

--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

@@ -1129,20 +1129,6 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = {

   .num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets),

};

-static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = {

-   .common = &pll_cpux_clk.common,

-   /* copy from pll_cpux_clk */

-   .enable = BIT(31),

-   .lock   = BIT(28),

-};

-

-static struct ccu_mux_nb sun8i_h3_cpu_nb = {

-   .common     = &cpux_clk.common,

-   .cm     = &cpux_clk.mux,

-   .delay_us   = 1, /* > 8 clock cycles at 24 MHz */

-   .bypass_index   = 1, /* index of 24 MHz oscillator */

-};

-

static void __init sunxi_h3_h5_ccu_init(struct device_node *node,

                   const struct sunxi_ccu_desc *desc)

{

@@ -1161,13 +1147,6 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node,

   writel(val | (0 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);

   sunxi_ccu_probe(node, reg, desc);

-

-   /* Gate then ungate PLL CPU after any rate changes */

-   ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb);

-

-   /* Reparent CPU during PLL CPU rate changes */

-   ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,

-                &sun8i_h3_cpu_nb);

}

static void __init sun8i_h3_ccu_setup(struct device_node *node)

 

You may also need to decrease the DDR frequency by 24Mhz in uboot on some boards. No binning on H3 chips, some are inferior.

 

This is not mainlined. Nor am I aware of any effort being put into pushing them upstream.

 

No rights reserved by me. As always apply at your own risk, neither me or my employers provide you with any guarantees.

Link to comment
Share on other sites

On 9/27/2019 at 9:39 AM, StefanH. said:

wow, I wasn't notified about all the replies here since I posted in May 2019. Unfortunately the problem has now occured 3 times since April. I have gone through all the dist-upgrades but the issue still persists.

This is soooo annoying as I run my home automation system on the Orange Pi. The WAF is going dramatically down :-(

Will try the CPU speed setting as well, but usually it takes a few months for the issue to re-appear on my side

 

After I set the CPU speed as described above the issue never came back

Link to comment
Share on other sites

On 5/4/2020 at 9:04 AM, Splitice said:

These are the 2 patches we ended up with. With thanks to everyone at on the linux-sunxi irc, particularly megi.

 


diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

index 6b636362379e..ca55c2ae999d 100644

--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

@@ -23,15 +23,21 @@

#include "ccu-sun8i-h3.h"

-static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",

-                "osc24M", 0x000,

-                8, 5,  /* N */

-                4, 2,  /* K */

-                0, 2,  /* M */

-                16, 2, /* P */

-                BIT(31),   /* gate */

-                BIT(28),   /* lock */

-                CLK_SET_RATE_UNGATE);

+static struct ccu_nkmp pll_cpux_clk = {

+   .enable     = BIT(31),

+   .lock       = BIT(28),

+   .n      = _SUNXI_CCU_MULT(8, 5),

+   .k      = _SUNXI_CCU_MULT(4, 2),

+   .m      = _SUNXI_CCU_DIV_MAX(0, 2, 1),

+   .p      = _SUNXI_CCU_DIV_MAX(16, 2, 1),

+   .common     = {

+       .reg        = 0x000,

+       .hw.init    = CLK_HW_INIT("pll-cpux",

+                    "osc24M",

+                    &ccu_nkmp_ops,

+                    CLK_SET_RATE_UNGATE),

+   },

+};

/*

* The Audio PLL is supposed to have 4 outputs: 3 fixed factors from

 

 

 


diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

index 5e7e9cccc172..609e889cae3c 100644

--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c

@@ -1129,20 +1129,6 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = {

   .num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets),

};

-static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = {

-   .common = &pll_cpux_clk.common,

-   /* copy from pll_cpux_clk */

-   .enable = BIT(31),

-   .lock   = BIT(28),

-};

-

-static struct ccu_mux_nb sun8i_h3_cpu_nb = {

-   .common     = &cpux_clk.common,

-   .cm     = &cpux_clk.mux,

-   .delay_us   = 1, /* > 8 clock cycles at 24 MHz */

-   .bypass_index   = 1, /* index of 24 MHz oscillator */

-};

-

static void __init sunxi_h3_h5_ccu_init(struct device_node *node,

                   const struct sunxi_ccu_desc *desc)

{

@@ -1161,13 +1147,6 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node,

   writel(val | (0 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);

   sunxi_ccu_probe(node, reg, desc);

-

-   /* Gate then ungate PLL CPU after any rate changes */

-   ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb);

-

-   /* Reparent CPU during PLL CPU rate changes */

-   ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,

-                &sun8i_h3_cpu_nb);

}

static void __init sun8i_h3_ccu_setup(struct device_node *node)

 

You may also need to decrease the DDR frequency by 24Mhz in uboot on some boards. No binning on H3 chips, some are inferior.

 

This is not mainlined. Nor am I aware of any effort being put into pushing them upstream.

 

No rights reserved by me. As always apply at your own risk, neither me or my employers provide you with any guarantees.

 

 

Was this patch ever added to upstream? Experiencing the same issue with couple of OrangePI One boards.

Link to comment
Share on other sites

12 hours ago, Mikhail Kulinich said:

Just curious, if I build an image based on 5.8 or 5.9 branches, it will contain those fixes, right?

Correct.

Armbian is using these very same branches to build image for sunxi and sunxi64 families with some extra patches on top. 5.8 is current and 5.9 is dev atm.

Link to comment
Share on other sites

It's 2021 and this issue still persists on ARMBIAN 5.83 stable Ubuntu 18.04.5 LTS 4.19.38-sunxi.

 

My time is always Apr 1st 1980 (like it's a joke).

fake-hwclock release date is in the future: 2016-04-15 00:00:00
Current system time: 1980-04-01 10:17:02

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines