Jump to content

sick and tired of my Armbian desktop locking and crashing

AxelFoley

By AxelFoley
in Pine RockPro64

 Share

Recommended Posts

AxelFoley

AxelFoley

Posted
Posted

Is it just me .... all the time I start to use the Armbian web browser  ...including simply loading this forum the whole RockPro64 OS locks up and I have to reset,.

Typically its when I load Media web sites like the BBC ,.... but it even occurs when I load this forum!!

 

I am trying to develop some C GPIO library to help the rockPro64 community, but its hopeless. I have to work on console and web brows on a laptop.

I have ordered a KVM to help but this is really frustrating.

 

Because the HW locks up I can not detect any issues in the logs and I don't know how to set up a HW trace in the graphics drivers.

 

I have eliminated any Power issues. I have a pico cluster case and decent heatsink ... I have ordered some Heatsink fans but CPU is in the 40 Deg C.

 

Any Ideas how I find out why the HW just freezes ?

 

It must have something to do with the mali drivers ?

 

Any ideas welcome

 

 

 

Link to comment
Share on other sites
NicoD

NicoD

Posted
Posted

 

37 minutes ago, AxelFoley said:

Any Ideas how I find out why the HW just freezes ?

Do you use the Media Script from JMCC on it?
Did you try another browser? Armbian browser doesn't exist. You can try firefox or Vivaldi browser.
https://vivaldi.com/nl/blog/snapshots/vivaldi-2-3-rc-2-vivaldi-browser-snapshot-1440-37/
 

Or you using Stretch or Bionic? Did you try the other?

 

1
Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

I am using the web browser default (chromium) that came with Armbian Bionic Desktop 18.04.2 LTS  kernel 4.4.174 Armbian 7.53

 

I am trying to install the media script but the browser keeps hanging the HW\OS.

 

I will give wget\curl a try

 

Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

I had to transfer the script to a USB stick on a laptop then transfer it to the RockPro64 because the browser kept locking up when trying to point Chromium to the armbian media script site. I selected the defaults of System, MPV and Gstreamer from the install CLI. I then opted for the Armsoc fullscreen vsync.

 

Tonight development is a write off so I will start again tomorrow.

 

Thanks for all your help ..  fingers crossed I can stop the desktop from locking up.

Its only been this bad recently since the distro upgrades (I upgrade daily).

 

Normally the forums are fine ... and I avoid sites with media content (video always locks up) but recently even the Armbiam forum causes the OS to lock the RockPro64 OS\HW Up.

 

The install script threw errors (see attached)

 

I will do an apt autoremove, reboot

 

and report back if stability improves

install.log

Link to comment
Share on other sites
NicoD

NicoD

Posted
Posted
48 minutes ago, AxelFoley said:

Nope .... I rebooted ... went straight into the Armbian forum using the default Chromium browser and the OS/HW locked up and froze :-(


So it started to do this after an upgrade?
I only asked if you were using the media script to know if that's not the problem. You didn't need to install it. But it could help, you never know. I'm not sure it works on the RockPro64.
Did you try another browser? Firefox? Vivaldi?

I know what browser crashes look like, I've had enough of them myself. I've worked with the Rock64 this week and always had them. I then tried an older kernel and it was better.
Maybe it's the same problem, or related.
@JMCC Could it be? Did you find anything?

What are the crashes like? Different kinds of crashes? Messages you get?
You could run Chromium with the terminal (just type chromium)and see if it gives any clues to what's going on.

Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

I have had these lockup issues  ever since I built the cluster in Dec 2018.

I initially thought it was a power issues (I was seeing some behaviour that suggested power was a problem)..

However since then I have resolved / upgraded my power source and eliminated that instability.

When I installed the base Armbian image I did follow some instructions to install some lib-mali drivers.

I suspected that may have been the issue and I associated the crashes trying to run video in a browser, so I avoided that.

However now more than ever I am seeing lockups just loading a browser and going to the armbian folder.

I will try to install firefox and see if that has similar problems.

 

 

Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

Right ... I think I can recreate the problem 100% by simply loading the Armbian Forum in chromium.

I have tried for 30min to create the same OS lockup using firefox with no problems what so ever. Indeed video on sites like BBC News play flawlessly.

So it looks like the issue is specific to the default Chromium install of Armbian.

 

I had overlooked it being chromium simply because it looked like it was a HW Video Driver glitch as the entire desktop would lock up and the mouse curser would typically not even move.

 

but bingo 30seconds after I loaded Chromium ... I went straight into the Armbian Forum and it locked up on the default forum page.

 

It did not used to be this reproducible ... I avoided media sites and generally I could get on with coding befoe a crash/lock would occur.

 

I am not sure what has made the environment so much more unstable and easy to reproduce a crash as I apt update && apt upgrade several times a day.

 

is there a way I can run chromium in debug mode and get it not to delete the log files when I have to hard reboot the device ?

Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

Another reproducible issue is that I can get exactly the same screen lockup on boot

 

When I re installed the desktop from  the armbian-config it installed lightdm and removed nodm.

I backed out this change .. uninstalled lightdm and reinstallled nodm in case that was what was causing the instability.

 

Unfortunately in doing so ... it changed the default nodm auto login to root instead of mu default user (pico).

 

if i edit /etc/default/nodm  back to pico instead of root ..... it locks up every time in the same manner 100% every time.

 

To fix the issue I have to mount the emmc module externa,,y and edit the file back to default login as root to be able to access the desktop.

 

 

 

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
19 minutes ago, AxelFoley said:

default Chromium install


Armbian don't develop nor fix Chromium https://www.chromium.org/for-testers/bug-reporting-guidelines

 

12 minutes ago, AxelFoley said:

When I re installed the desktop from  the armbian-config it installed lightdm and removed nodm.


Not a bug but feature. We are about to drop nodm since bugs are not getting fixed.

Link to comment
Share on other sites
AxelFoley

AxelFoley

Posted
  • Author
Posted

armbian-config does not do a good job of installing lightdm, it failed to launch lightdm on boot with errors around trying to restart the service too quickly after it initially failed to start.

 

I don't have time to troubleshoot somebody else's sloppy mess.

I have reverted back to nodm so I can get back to writing some code.

 

The display lockup when nodm boots and logs in as any other user apart from root ... is not going to be nodm's problem I suspect.

more likely an Xorg config issue \ graphics driver.

 

good to know I can avoid 90% of my stability issues just but not using the default armbian chromium browser.

 

I am soon going to have to face facts and accept I need to reformat my entire cluster with a different distro, I just can not get Armbian stable on rockPro64.

I have been trying for 4 months. I have these lockup issues with my master node and I have 20% of my nodes constantly restarting.

I have eliminated power issues.

I have ordered a load of heatsink fans to eliminate the last thing I can think of ... heat as being the problem (despite them all having heat sinks and a pico cluster case).

 

The fans are the last thing I try before giving up on armbian and starting from scratch and loosing all my salt/cassandra/promethious/grafana cluster configuration.

Link to comment
Share on other sites
Da Alchemist

Da Alchemist

Posted
Posted

Using Rockpro64 for Desktop Scenarios is a really bad idea at this state of development. There is no distro i would recommend for using , i have tried ayufans images, the one from mrfixit and armbian. There is a big lack of developement for this board and i really do not know why it is moved to "stable" on Armbians build system.

 

My Nanopi M4 is running really stable and smooth; acts as Desktop replacemanent since I got the SATA Hat. There are absolutely no crashes running Chromium on armbian, so i think that there are no chromium related issues.

I suspect bad hardware design on RockPro.

Link to comment
Share on other sites
AndrewDB

AndrewDB

Posted
Posted
4 hours ago, AxelFoley said:

Right ... I think I can recreate the problem 100% by simply loading the Armbian Forum in chromium.

In Chromium (if you absolutely insist on using it instead of Firefox), check in advanced options if hardware acceleration support is enabled or not. If it is enabled, disable it. Also check your memory/swap usage while loading the Armbian Forum in Chromium.

Finally, if your system locks up due to a kernel oops, the information is still available in dmesg, you may want to check that in a terminal, try: 

tail -f /var/log/{messages,kernel,dmesg,syslog}

 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted
10 hours ago, Da Alchemist said:

There is a big lack of developement for this board and i really do not know why it is moved to "stable" on Armbians build system.

If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?

 

rockpro.thumb.png.29ffe0379630543e1e6d9fe224cc6985.png

 

but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..

 

but also this sub-forum has a nice reminder:

rk3399.PNG.88816f3f4f84c719241c4669d60dfc2c.PNG

 

My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.

 

Just another reminder: https://forum.armbian.com/guidelines

especially this points here:

Quote

A support question must include the following:

  • Board you use
  • Issue you face
  • Description of your set-up (e.g. powering, connected hardware, used SD-Card)
  • 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!

 

 

12 hours ago, AxelFoley said:

I have eliminated power issues.

what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?

1
Link to comment
Share on other sites
Da Alchemist

Da Alchemist

Posted
Posted

@chwei think you understood what i wanted to say: Everywhere on Armbian Rk3399 devices are marked as WIP , only on the build-system we will find them under "stable".

 I can only compare the Rockpro64 to my Nanopi M4 an my NEO4 and I must say at this moment Rockpros performance is worse. Developement on Rockpro is done by ayufan and mrfixit, both not active members on this forum, posting Issues here does not make make much sense. There are lot crashing reports on Pines IRC channel.

 

I would not only move this Board back to the "Expert" Side, i think i would kick it completely out of Armbian, so  bad performing issues are not being related to Armbian, like it was done by @AxelFoley

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

@ayufan Last visited Saturday at 09:35 PM, it's not that he doesn't read the forum.. he just doesn't post as much as others do.. ;) Which is understandable.. Dealing with other peoples issues isn't much fun.. especially if you can't replicate them.. The whole situation with RK3399 is a bit complicated, especially when we talk about the 4.4 kernel. Nanopis are part of the rk3399 sources with friendlyarms 4.4 fork of the Rockchip bsp kernel acts as a source (https://github.com/armbian/build/blob/f1d1ca51f32bd1a2593349ba82a1013fa55f389f/config/sources/rk3399.conf#L34-L37) whereas RockPro64 is part of the rockchip64 family with ayufans kernel as 4.4 source, but also a fork of Rockchips bsp kernel (https://github.com/armbian/build/blob/f1d1ca51f32bd1a2593349ba82a1013fa55f389f/config/sources/rockchip64.conf#L47-L49) I don't remember exactly the issue which lead to it (if I've it right in mind it's related to u-boot in the beginnings.. but maybe @martinayotte or @TonyMac32 can comment on this cause it comes from a time when I was not involved at all in rk3399 boards.. Surly this mix avoids us partly from marking rk3399 boards as stable. But surely chances are higher that a boardvendor provided/modified kernel is likely to work 'better' as an independent one.. Especially when we consider that FriendlyArm normally know what they're doing (it's not their first arm board.. :D)

Spoiler

mini2440-35.jpg

They know what they're doing...

 

 

23 hours ago, Da Alchemist said:

posting Issues here does not make make much sense.

wouldn't agree on this one.. It's not that we don't fix broken kernels.. :lol:  https://github.com/armbian/build/tree/master/patch IMO the most important part of armbian is related to kernelwork and get things working which don't work (well) from the sources we rely on.. But blaming a board which is marked as WIP on the downloadpage and the whole SoC family sub-forum is marked as wip as well is IMO pointless.. We do catch up issues.. that's one of the porposes of this forum.. Getting feedback what's working and what's not working to enhance support for boards. But this thread didn't show much progress.. Basically also cause:

On 4/1/2019 at 11:50 PM, chwe said:

Just another reminder: https://forum.armbian.com/guidelines

especially this points here:

Quote

A support question must include the following:

  • Board you use
  • Issue you face
  • Description of your set-up (e.g. powering, connected hardware, used SD-Card)
  • 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!

was never answered.. A part which should actually be in the starter..

 

23 hours ago, Da Alchemist said:

I would not only move this Board back to the "Expert" Side, i think i would kick it completely out of Armbian, so  bad performing issues are not being related to Armbian, like it was done by @AxelFoley

if we would kick out every board which is a bit troublesome during wip.. We would support only a few boards here.. :D Just a reminder again:

Quote

RK3399 board support is WIP, "for testing only" and problems are expected! If you want to use those boards for some real cases, don't.

 

Especially if it's a platform you don't know well, just don't. Things might just not be ready.. It needs some time until they get mature.

Link to comment
Share on other sites
Da Alchemist

Da Alchemist

Posted
Posted
40 minutes ago, TonyMac32 said:

To be fair I am of the opinion we should not have any downloadable images for WIP targets.
 

Totally agree to this.

 

@chwe, think you never had a Rockpro in your hands.

53 minutes ago, chwe said:

 

if we would kick out every board which is a bit troublesome during wip.. We would support only a few boards here..

 

So Devs can concentrate on the Boards that are worth to be supported.

Link to comment
Share on other sites
pfry

pfry

Posted
Posted
1 hour ago, TonyMac32 said:

To be fair I am of the opinion we should not have any downloadable images for WIP targets.

Whoa, I'm not. I'm a total leech on y'all's work, and I have no desire to cross-compile an image. (I prefer PC-style native installations like LFS and Gentoo - from an end-user perspective Armbian is the least-customized distro that I use.) I've had no issues with my NanoPC-T4, and the super-easy eMMC+NVMe install is unique (afaik). Can't beat it with a stick. I can't contribute much, as all I have in excess is Internet bandwidth and old PC hardware (and somewhat off-the-rails forum posts).

Link to comment
Share on other sites
NicoD

NicoD

Posted
Posted

Boy, this has gotten off topic :D
 

2 hours ago, TonyMac32 said:

To be fair I am of the opinion we should not have any downloadable images for WIP targets.

Hard to agree with this situation of the NanoPi M4/T4/NEO4 still being in WIP. 
I don't have a RockPro64, so I can't judge on that. 
I do have many other boards. And I know that it's better to have an image with faults than to have nothing at all. 
 

 

15 minutes ago, martinayotte said:

Euuh ? I've just turn it ON for PineH64 ... I will turn it OFF tomorrow ...

(That was because of confidence of @NicoD  ;))


:o

 

6 minutes ago, martinayotte said:

Right ! at least for the "reset/reboot" question, and it has 3GB RAM ... I will leave @NicoD to provide his testimonies ... :P

Reset works, 3GB also. Display resolution is set right, wifi works from first boot, ... 
You just can't choose 1.8Ghz. But it is actually better to run it at 1.5Ghz. Maybe an idea for the OPi3, but keep 1.8Ghz available. I know most people will not use a fan on it, so it's not useful to leave it at 1.8Ghz. 

 

13 minutes ago, Da Alchemist said:

@martinayotte, pineH64 is working better than Rockpro :D

I was surprised. I kept it on the side for after the Orange Pi 3. And expected it to be worse. It runs great barebones. It isn't going to break performance records, but it behaves nice.
 

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
27 minutes ago, NicoD said:

Hard to agree with this situation of the NanoPi M4/T4/NEO4 still being in WIP. 

 

RK3399 support is a total and utter mess.  When we finally fix it, it will break the upgrade path on very nearly every board, since our current patching/boot situation is impossibly convoluted.  Given the OP is not alone, and I completely understand his frustration, just imagine when that happens.  

 

51 minutes ago, martinayotte said:

Euuh ? I've just turned it ON for PineH64 ... I will turn it OFF tomorrow ...

Well, I did say "opinion".  I would guess it takes more than my automotive-engineering-minded release conservatism to shut down or change the direction of the entire project.  I will open a new thread on this topic, I may have a compromise in mind. 

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept