Banana Pi randomly not working

[yarciapaul]

I'm running the latest armbian on my Banana Pi M1 as a headless file/media server. My problem is that my Banana Pi would randomly stop working any time of the day. A day would not pass by without me having to reboot my server manually by pressing the reset button. There would still be network activity as the activity lights on the LAN keeps on flashing and it would still respond to my ping requests.

 

I'd know it stopped working if I can't access the server's services anymore through its web ui (webmin, transmission, etc.) and to confirm this I'd try to SSH into it and it wouldn't connect. I tried creating a script where it would restart the LAN if it pinged the router and it didn't respond but still this didn't work.

 

To test if the hardware is the real problem, I tried using raspbian and bananian on it and it worked well for more than 48+ hours respectively without me ever having to reset it just for me to use it remotely anytime of the day.

 

I can just use bananania or raspbian so that I'd never have to deal with the problem of resetting it whenever I can't access it but I am after Armbian for it's continued support and updates. Is there anyway I won't sacrifice having Armbian as the OS of my file/media server? Thank you!

[Naguissa]

I'm first!


As always, try a beefier PSU and a good, short USB cable.

tkaiser will then rant about shitty microUSB (he is completely right)

Enviado desde mi Jolla mediante Tapatalk
 

[yarciapaul]

Thanks for the reply!

 

Honestly I don't think it is a problem with the PSU because it performs well with any older OS for banana pi m1 without a hitch just like I stated before. I'm using a short USB cable between my drives and the banana pi and these drives are connnected to the banana pi through a dock which has its own power. What could be the difference between when I'm using armbian and other distro that I'm only experiencing this with armbian?

[tkaiser]

17 hours ago, yarciapaul said:

A day would not pass by without me having to reboot my server manually by pressing the reset button

 

Which might imply that your whole installation on the SD card is already corrupted as a result of countless 'hard reboots'. It's useless to diagnose at this stage and I doubt anyone is interested in diagnosing it since boards with Micro USB for DC-IN are a support nightmare anyway. You can try to repeat your tests with a fresh Armbian install but unless you fix your underpowering problems it won't help.

 

Most easy way to diagnose underpowering problems is to download latest nightly build from here, burn it on a separate SD card, boot the system with the usual stuff connected and then simply run the following in one terminal and few seconds later start 'stress -c 2 -m 1' in another terminal and watch what happens:

tk@lime2:~$ sudo armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   PMIC   DC-IN
17:24:47:  720MHz  0.11   3%   1%   1%   0%   0%   0% 40.8°C  4.77V
17:24:52:  528MHz  0.10   3%   1%   1%   0%   0%   0% 40.2°C  4.74V
17:24:57:  528MHz  0.09   3%   1%   1%   0%   0%   0% 40.2°C  4.75V
17:25:03:  528MHz  0.08   3%   1%   1%   0%   0%   0% 40.4°C  4.76V^C

(we added voltage monitoring to Armbianmonitor recently since boards with Micro USB for DC-IN are such a support nightmare but this will only work on most recent OS images)

[yarciapaul]

6 minutes ago, tkaiser said:

 

Which might imply that your whole installation on the SD card is already corrupted as a result of countless 'hard reboots'. It's useless to diagnose at this stage and I doubt anyone is interested in diagnosing it since boards with Micro USB for DC-IN are a support nightmare anyway. You can try to repeat your tests with a fresh Armbian install but unless you fix your underpowering problems it won't help.

 

Most easy way to diagnose underpowering problems is to download latest nightly build from here, burn it on a separate SD card, boot the system with the usual stuff connected and then simply run the following in one terminal and few seconds later start 'stress -c 2 -m 1' in another terminal and watch what happens:

tk@lime2:~$ sudo armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   PMIC   DC-IN
17:24:47:  720MHz  0.11   3%   1%   1%   0%   0%   0% 40.8°C  4.77V
17:24:52:  528MHz  0.10   3%   1%   1%   0%   0%   0% 40.2°C  4.74V
17:24:57:  528MHz  0.09   3%   1%   1%   0%   0%   0% 40.2°C  4.75V
17:25:03:  528MHz  0.08   3%   1%   1%   0%   0%   0% 40.4°C  4.76V^C

(we added voltage monitoring to Armbianmonitor recently since boards with Micro USB for DC-IN are such a support nightmare but this will only work on most recent OS images)

Can this stress test trigger the same reaction(if the problem is really the power)? How long do I have to wait for the reaction to happen or stop the test?

 

I also tested CentOS, still doesn't produce the problem I am experiencing with armbian.

[tkaiser]

Just now, yarciapaul said:

Can this stress test trigger the same reaction?

 

Just try it out and report back. Currently you're not even aware of the problem as almost all users (Micro USB being such a shit show) since you talk about an USB cable between your board and disks while it's about the USB cable between your PSU and your board (this is where the voltage drop happens).

 

http://linux-sunxi.org/Powering_the_boards_and_accessories#Micro_USB

http://forum.lemaker.org/forum.php?mod=viewthread&tid=8312&extra=page%3D1

[yarciapaul]

 

6 hours ago, tkaiser said:

 

Just try it out and report back. Currently you're not even aware of the problem as almost all users (Micro USB being such a shit show) since you talk about an USB cable between your board and disks while it's about the USB cable between your PSU and your board (this is where the voltage drop happens).

 

http://linux-sunxi.org/Powering_the_boards_and_accessories#Micro_USB

http://forum.lemaker.org/forum.php?mod=viewthread&tid=8312&extra=page%3D1

Oh I'm sorry. I assumed what Naguissa was talking about was the USB cable between my drives OTHER THAN the power adapter because it usually comes up (portable hard drives having to rely entirely on these boards for power) when having stability issues based on my readings. What Naguissa was actually talking about was the length of micro USB from the power adapter itself. Sorry, my mistake.

 

Will probably test this right away! Thank you!

[Naguissa]

No, I was referring to PSU microUSB cable.

The problem with Armbian could be because its optimizations could cause more power drawing and then more underpower failures

Enviado desde mi Jolla mediante Tapatalk

[yarciapaul]

For how long should I run this? Is it safe if I run this for 24 hours just to be sure? It's been running for 6 hours now and my banana pi m1 is still functioning usually its less than 12 hours before the problem occurs.

 

 

[yarciapaul]

Stress testing for 10 hours now, problem still not appearing.

[yarciapaul]

12 hours have already passed and the problem I was experiencing are not yet showing.  I think this was the longest my banana pi was constantly on.

[chwe]

Were the discs connected during the test? Did you 'force' some disc activity to let them spin up? I know you use some sort of power dock, but just to make sure, there's no voltage drop during spin-up of your drives...  

[tkaiser]

8 hours ago, yarciapaul said:

For how long should I run this?

A minute would've been sufficient if armbianmonitor output would contain both idle and stress situation (yours shows only the latter). This would've allowed to compare input voltages but in your installation powering looks sufficient (still at 5.2V when stress is running).

 

So your instabilities seem not to be related with two of the three major problems that occur with Micro USB powered Bananas. Maybe your installation on the other card is already broken, maybe the SD card there has a problem. Would be interesting to see logs (armbianmonitor -u) from your original installation and also whether you're able to clone the card (on another system using ddrescue for example) and then check it with either F3 or H2testw (if you're running off a counterfeit card with faked capacity your symptoms would also match)

[yarciapaul]

2 hours ago, chwe said:

Were the discs connected during the test? Did you 'force' some disc activity to let them spin up? I know you use some sort of power dock, but just to make sure, there's no voltage drop during spin-up of your drives...  

 

 

1 hour ago, tkaiser said:

A minute would've been sufficient if armbianmonitor output would contain both idle and stress situation (yours shows only the latter). This would've allowed to compare input voltages but in your installation powering looks sufficient (still at 5.2V when stress is running).

 

So your instabilities seem not to be related with two of the three major problems that occur with Micro USB powered Bananas. Maybe your installation on the other card is already broken, maybe the SD card there has a problem. Would be interesting to see logs (armbianmonitor -u) from your original installation and also whether you're able to clone the card (on another system using ddrescue for example) and then check it with either F3 or H2testw (if you're running off a counterfeit card with faked capacity your symptoms would also match)

I just stopped the test and this been the longest time it was constantly on ever under Armbian, 15 hours. I can't remember anything that could've corrupted my installation. Power interruption is very rare where I live and I only resorted to using the "reset" button (for the first time) was when the problem first came up. Sadly, I do not have an image of my old installation of Armbian anymore since I accidentally deleted those backups when I was organizing my files. I'll be scanning my SD card using the tools you recommended above. 

 

If the people behind Armbian can read this, I hope they include a feature where Armbian can do an integrity scan on itself and would be able to replace any corrupt file or any file with wrong configuration (by the user, especially for those like me which sometimes forgets to backup my image every time I'm about to make a huge change on to the system) at the request of the user. The integrity scan would then pull a file from a repository to replace a file with another known good file.

 

Thanks for the feedback! I really appreciate it!  

[tkaiser]

9 minutes ago, yarciapaul said:

If the people behind Armbian can read this, I hope they include a feature where Armbian can do an integrity scan on itself

 

Those people implemented this already. Just call armbianmonitor without arguments to understand -c (check your SD card for counterfeit/fraud issues) and -v (verify installation -- the latter only available on new images now).

 

BTW: Since you successfully verified that Armbian 'just works' (on another SD card than the one of your broken installation) now you might also understand why Bananian and Raspbian 'just worked'?

[yarciapaul]

45 minutes ago, tkaiser said:

BTW: Since you successfully verified that Armbian 'just works' (on another SD card than the one of your broken installation) now you might also understand why Bananian and Raspbian 'just worked'?

I'm sorry but I'm a little confused what you mean by that.

 

I tested my SD card using h2testw and this was the result

It warned me about using just 7571 of the 7572 MByte of the SD Card before it started the test but I chose the default of using the whole capacity of the SD card. I tried manually setting 7572 MByte but the program still insisted and fell back to 7571 on manual. I don't think there is any problem with my SD card and I think the warning produced by h2testw is not in anyway related with what happened with my previous installation. Well I guess this post ended in more question than answers. I'll just observe it this will happen on a new installation.

[yarciapaul]

UPDATE: It happened to me again when I reverted back to the stable build. I think what's keeping my Banana Pi from fully functioning all the time was already adressed on the nightly build, I guess.

[tkaiser]

12 minutes ago, yarciapaul said:

I think what's keeping my Banana Pi from fully functioning all the time was already adressed on the nightly build, I guess.

 

I think guessing is just a waste of time. I already asked for real information but as usual in this forum this gets ignored

 

On 19.11.2017 at 8:57 AM, tkaiser said:

Would be interesting to see logs (armbianmonitor -u) from your original installation

 

[yarciapaul]

On 11/19/2017 at 3:57 PM, tkaiser said:

Would be interesting to see logs (armbianmonitor -u) from your original installation

 

Which I already answered outright with (if you just read and understood it):

On 11/19/2017 at 5:00 PM, yarciapaul said:

Sadly, I do not have an image of my old installation of Armbian anymore since I accidentally deleted those backups when I was organizing my files.

 

And now you're saying

37 minutes ago, tkaiser said:

I think guessing is just a waste of time. I already asked for real information but as usual in this forum this gets ignored

I don't mean to be rude but if you read our past conversations, it seems that it was you who "ignored" the provided information.

 

I was precise and detailed on how I presented my problem and how I came up with conclusions.

 

On several documented instances, it was you who didn't fully read the previous posts before posting an answer. On this instance, I asked specifically how long should I run the test and you didn't answer it:

On 11/19/2017 at 12:33 AM, yarciapaul said:

How long do I have to wait for the reaction to happen or stop the test?

 

And you answered:

On 11/19/2017 at 12:35 AM, tkaiser said:

Just try it out and report back. Currently you're not even aware of the problem as almost all users (Micro USB being such a shit show) since you talk about an USB cable between your board and disks while it's about the USB cable between your PSU and your board (this is where the voltage drop happens).

 

Almost 6 hours into the test and I asked the same question:

On 11/19/2017 at 7:12 AM, yarciapaul said:

For how long should I run this? Is it safe if I run this for 24 hours just to be sure? It's been running for 6 hours now and my banana pi m1 is still functioning usually its less than 12 hours before the problem occurs.

 

In which you answered 7 hours from the said post, which in total resulted to my Banana Pi stress testing for more than 12 hours. Only to find out that a minute or two under stress testing would suffice.

On 11/19/2017 at 3:57 PM, tkaiser said:

A minute would've been sufficient if armbianmonitor output would contain both idle and stress situation (yours shows only the latter).

 

This could have been prevented if you WERE THE ONE reading previous posts carefully.

 

I diligently provided information as extensively and as relevant as I can evidently if you were not busy assuming that other people don't know what they're doing and that you always know better than other people.

 

I am thankful for any assistance I'm receiving from members of this forum and I have extended due courtesy. But I hope that before you assume that you are getting ignored, you are not the one who ignores in the first place.

 

The fact still remains:

 

Nightly Build - Stress tested for more than 12 hours, never disconnected. (Before re-installation of Stable build that I use as of this moment that randomly disconnected again.)

Stable Build - Functioned for almost 8 hours then disconnected randomly after. (This was after I tested the nightly build and currently using it.)

 

SD Card - not the problem, it can be shown from the picture above

 

Power Adapter - same adapter I used on stress testing on the nightly build and normal usage on the stable build but it was the stable build which disconnected after almost 8 hours of use.

[yarciapaul]

I rest my case and wouldn't expect any "objective" and "informed" comments anymore from anyone regarding this matter. I can say, based from the tests I did which was supported with screenshots, that there isn't anything wrong with the power adapter and SD card I'm using to power my banana pi and run an armbian installation from. But whatever it is, the problem no longer persists in nightly build (which ran stress test for more than 12 hours) and re-appears only in stable build (as of this writing) even after a fresh installation and normal usage for (almost 8) hours. 

[tkaiser]

What a mess. You still do not provide any information NEEDED. No one except you knows what you consider being 'the Stable Build'. We provide a couple of different OS images, some based on Debian, some on Ubuntu, some with 3.4 kernel, some with 4.11 kernel, some with 4.13 kernel. What are you using? No one except you knows. Instead of writing essays you could've provided output from armbianmonitor -u already (yeah, from whatever you call 'Stable Build' NOW of course!)

 

Background info: 

 

[yarciapaul]

1.) This was the "stable" build I was referring to just like you suggested using the latest "nightly" build and stress test my Banana Pi.

2.) You asked the armbianmonitor -u output from my original installation which I already answered that I lost the back up of (and was testing different compatible distros on my banana pi to test if it would disconnect randomly within 24 hours) so I wouldn't be able to provide it for you. What you are asking now is a from the new "stable" build installation I did just after all those rants you did about me ignoring your request while you on the other hand refuse to read in the first place. 

39 minutes ago, tkaiser said:

Instead of writing essays you could've provided output from armbianmonitor -u already (yeah, from whatever you call 'Stable Build' NOW of course!)

On 11/19/2017 at 3:57 PM, tkaiser said:

Would be interesting to see logs (armbianmonitor -u) from your original installation and also whether you're able to clone the card (on another system using ddrescue for example) and then check it with either F3 or H2testw (if you're running off a counterfeit card with faked capacity your symptoms would also match)

 

Instead of outright being rude to other people about not getting what you need, why don't you read the whole post and understand it first before replying. I don't doubt about the superiority of your knowledge on Linux distros and IT in general over me. But the problem with common sense these days is that it is so common some people forget to use it. I was referring to the single latest "stable" build that I had a problem with and just re-appeared again just after I came back from the single latest "nightly" build and you went ballistic about some distros and kernel. The previous screenshot (if you were reading them and not just replying hastily and excitedly) show the answers to your question.

 

I will have to deal this on my own just so I won't deal with any rude people.

 

Reminder: Read, comprehend and think before you click.

 

Good day to you, sir.

[tkaiser]

UNBELIEVABLE! Instead of providing information you still only write essays with personal Blah blah and provide screenshots where you censor the most important information (the kernel version!!!!) away. We provide both a stable Xenial with 3.4.113 kernel and a stable Xenial with 4.x kernel and the debug output would allow us maybe to get a clue what's going on TO IMPROVE ARMBIAN (that's all I'm interested in).

[chwe]

 This thread gets a bit out of control...  So let's see if we bring this thread a bit more productive.

 

5 hours ago, yarciapaul said:

2.) You asked the armbianmonitor -u output from my original installation which I already answered that I lost the back up of (and was testing different compatible distros on my banana pi to test if it would disconnect randomly within 24 hours) so I wouldn't be able to provide it for you. What you are asking now is a from the new "stable" build installation I did just after all those rants you did about me ignoring your request while you on the other hand refuse to read in the first place. 

You explained now at minimum two times that you can't provide sudo armbianmonitor -u from your first build cause you didn't have this image anymore.  But since the 'stable' build you use still crashes, you could provide it for this build? 

5 hours ago, yarciapaul said:

1.) This was the "stable" build I was referring to just like you suggested using the latest "nightly" build and stress test my Banana Pi.

 

Printscreens are the last chance when armbianmonitor isn't possible at all (board doesn't boot or upload fails for whatever reason).  As @tkaiser pointed out here ,  he as an experienced SBC user gets much more Information from armbianmonitor than from printscreens.

 

5 hours ago, yarciapaul said:

 

Reminder: Read, comprehend and think before you click.

A reminder back for you (you should see before your first post):

Quote

We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:

 

1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)

 

2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.

 

3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.  

 

We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

5

 

He might be a little bit harsh but when he several times ask for something and you deliver everything else but not the things he wants he might be a bit annoyed. Others would stop answering your question cause they thought it's a 'waste of time'... 

My personal opinion: It's up to you. If you can't deal with 'harsh' answers, solve it by your self or hope that somebody else joins this thread to help you. But @tkaiser knows those SBCs best better than most of us for server use cases (not that I wanna upset others) and it might be a good idea to follow his advice.