Jump to content

mystery reboot while loading network on Orange Pi Zero


jerryc

Recommended Posts

Hi

 

Just got my first Orange Pi Zero today.  Everything looking good, with the exception, if I run iperf tests between this and a linux host, the Orange Pi Zero will reboot without any error messages.

 

I changed my power supply to a wall plug which can support 2.4amp easily, also tried to tune down the frequency to 900Mhz max, 4 cores, turned off HDMI/GPU, USB.   DRAM is at minimum, 408 I think.  Temperature remains at 55 to 58C

 

Still once a while during heavy network, the board will reboot.

 

The image i used is the legacy image posted on orange pi zero,  Armbian_5.24_Orangepizero_Debian_jessie_3.4.113

 

Thanks

Jerry

Link to comment
Share on other sites

This this image is fairly stable, the temperature seems to be lower as well.   Is the armbian team going to release this image any time soon?  Also will h3consumption tool be included in this kernel?   I find it extremely useful.

 

Latest: the board will reboot after 1 hour or so when under iperf stress.  the temperature 2 min before the reboot is 65C.   Using the older image, it will reboot in less than 2 min.

Link to comment
Share on other sites

the Orange Pi Zero will reboot without any error messages.

 

I changed my power supply to a wall plug which can support 2.4amp easily

The usual problem is called 'voltage drop' and lives most probably inside the cable between PSU and device. In case you did not already please try an AWG24 rated cable (or better, AWG20 would be the best).

 

To isolate this you could use stress or sysbench too.

Link to comment
Share on other sites

Hi, 

 

thank you all for the support, I did change to another power supply, the one I used on my iPad, now it is very stable.   I always thought the none portable 'bigger' plugs are more stable.

 

Temperature is still high, so wondering will the h3consumption tool be ported to this kernel? if not, will armbian create something similar?  

 

And lastly, will there be an official release of this image from Armbian?

 

-jerry

Link to comment
Share on other sites

I always thought the none portable 'bigger' plugs are more stable.

 

Rule of thumb: If a PSU has USB type A jacks then expect that the device is crap (if you manage to get original gear from some vendors -- eg. Apple -- then this doesn't apply).

 

I knew it when I saw the first pictures from Orange Pi Zero: now we get all these reports of 'Armbian not working' just due to this shitty Micro USB crap to power the board :(

 

Temperature is still high, so wondering will the h3consumption tool be ported to this kernel? if not, will armbian create something similar?

 

 

The h3consumption script is our own invention, it won't be available for mainline kernel images anytime soon (due to H3 support there being WiP and device tree stuff changing from version to version). For end users it's easy: Just use legacy kernel images. And read through h3consumption thread to understand that most if not all people have wrong expectations regarding this tool.

 

A question: What can we do to improve perception of this message on download pages: Warning: nightly downloads are automated untested builds and no end user support is provided for them!

 

Really, what do we have to supply so people understand that they shouldn't use these images if they're no developers?

Link to comment
Share on other sites

The reason I am using the main line is the legacy kernel when doing high traffic on the ethernet will reboot for no reason.  The mainline kernel seems to fix it nicely.  

 

With regard to nightly,  my suggestion is to supply images periodically and have users verify and test them. (I will happy to do that).  this way , you have a image that's more stable than the 'automated, untested image'.   And it will be community driven testing.   The key is to have a freeze point .. 

Link to comment
Share on other sites

With regard to nightly,  my suggestion is to supply images periodically and have users verify and test them. (I will happy to do that).  this way , you have a image that's more stable than the 'automated, untested image'.   And it will be community driven testing.   The key is to have a freeze point .. 

Nightlies work fine for now, but the build process needs to be extended in order to report if there were any rejected kernel/u-boot patches, so there are ways to make the nightlies system better and more reliable.

 

"Community driven testing" doesn't work in reality as far as I can see - people don't know what they are testing, don't know what to expect from experimental images, don't know how to properly report any problems (and what is a real problem and what is not).

As for a "freezing point" - we have stable releases, where even if there are problems, they are expected.

Link to comment
Share on other sites

The reason I am using the main line is the legacy kernel when doing high traffic on the ethernet will reboot for no reason.  The mainline kernel seems to fix it nicely.

 

In other words: You fixed your power supply problem in the meantime and blame the kernel :)

 

Again: OPi Zero unfortunately uses the most crappy connector on earth for DC-IN. If you experience a 'reboot for no reason' then this is most probably related to powering problems. If you still have problems 'with legacy kernel' then search for a proper USB cable between PSU and board as already suggested.

Link to comment
Share on other sites

"Community driven testing" doesn't work in reality as far as I can see

 

In fact it works like this (OS images with kernel 4.7 and 4.8 for NanoPi NEO):

 

"Here are experimental images. We need feedback on A. B is known to not working yet. Same applies partially to C"

 

People start to use the images productive and complain about B and C while never mentioning A at all.

Link to comment
Share on other sites

Community driven testing is customer testing.  Is it perfect, no ... Is it realistic ... yes.  As the number of users grow, the coverage will increase.  Even the test cases are not well defined, but law of big numbers will solve that. 

 

-jerry

 

Nightlies work fine for now, but the build process needs to be extended in order to report if there were any rejected kernel/u-boot patches, so there are ways to make the nightlies system better and more reliable.

 

"Community driven testing" doesn't work in reality as far as I can see - people don't know what they are testing, don't know what to expect from experimental images, don't know how to properly report any problems (and what is a real problem and what is not).

As for a "freezing point" - we have stable releases, where even if there are problems, they are expected.

Link to comment
Share on other sites

That's certainly not my case. the initial problem is not power related.  The same image with an apple iPad supply still reboots when network traffic is very high.  This is only solved by the new kernel ...

 

 

 

In other words: You fixed your power supply problem in the meantime and blame the kernel :)

 

Again: OPi Zero unfortunately uses the most crappy connector on earth for DC-IN. If you experience a 'reboot for no reason' then this is most probably related to powering problems. If you still have problems 'with legacy kernel' then search for a proper USB cable between PSU and board as already suggested.

Link to comment
Share on other sites

That's certainly not my case. the initial problem is not power related.

 

This is now the third and last time I'll speak about what's most probably the culprit: The cable between PSU and your Pi Zero: http://linux-sunxi.org/Powering_the_boards_and_accessories#Power_cables The average USB cable is shit since the power lines are rated 28AWG and lead to massive voltage drops.

 

I asked you already whether you can try to run stress or sysbench to confirm (since you're the first one ever reporting this sort of problems with H3 Ethernet and 'reboot without any error messages' is usually a clear indication of what's going on)

Link to comment
Share on other sites

That's certainly not my case. the initial problem is not power related.  The same image with an apple iPad supply still reboots when network traffic is very high.  This is only solved by the new kernel ...

It would be best to connect a serial console to the board and capture the kernel output during the crash and reboot. Unless you prove that it is a kernel crash and is related to the Ethernel @tkaiser will assume that it is a power supply problem or a SD card problem.

Link to comment
Share on other sites

@tkaiser will assume that it is a power supply problem or a SD card problem.

 

Pardon? :)

 

While it's close to irrelevant what I assume it's IMO pretty obvious that we're not talking about SD cards now if by exchanging the PSU the mainline kernel image moves from "reboots after one hour" to "pretty stable". The iPad charger being used provides 5.25V (at least that's what mine do) and maybe for whatever reasons consumption with mainline image is lower than with legacy and voltage drops not that low compared to a 'huge' PSU only providing 5V.

 

Useless to speculate if/when a simple 'stress -c 2 -m 2' is sufficient to also trigger reboots (then it's the usual voltage drop associated with crappy USB cables... which is also the reason why Apple refused to adopt Micro USB and chose their lightning connector instead).

Link to comment
Share on other sites

@zador.blood.stained: Another issue we should keep in mind: different throttling and different DVFS settings between mainline and legacy images on H3 boards. So in case undervoltage situations occur and in case VDD_CPUX varies depending on DC-IN (never measured that but thought it was the case at least with NanoPi NEO based on thermal readouts) we might see different behaviour when comparing legacy and mainline.

 

In case VDD_CPUX depends on DC-IN and the latter is let's say as low as 4.6V and throttling occurs at the same time leading to lower cpufreq then it might make a huge difference at which cpufreq the switch between 1.1V and 1.3V happens.

Link to comment
Share on other sites

I feel this forum to be most "international", in the sense that there is a lot of misunderstandings, eternal repetitions of always the same questions and unclear communications. Maybe we customers and/or testers are not that fluent in english to write correct error reports.

Also searching in the forum is still a pain, and there are no pinned threads.

 

Maybe you could attach a simple questionnaire to the nightly builds to be sent to a response address. Something with tick boxes for

"boots, gives image on monitor, stays running more than one night, etc", and a little text field for comments. Might go a long way for

reporting.

 

Disclaimer: I am a fool and understand of nothing. Just my 2 cents.

 

thanks for the great work!

gnasch

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines