1GB Pine64+ freezes/crashes with all installs
#1
Been having the problem of whatever OS I run on the 1GB Pine64+ board constantly crashing when, if my suspicions are correct, high memory usage happens. In particular it will always happen when I browse a "heavy" page. Whether it's with Chrome on the Android 5.1 build, Midori on the Arch Linux build, or the browser in RemixOS, it's always the same problem with the same result - after just a few seconds of loading a heavy-ish page, the screen goes black and the device shuts off, or the screen goes black then usually white (sometimes another random color), device stays powered on, and the SoC (heatsinked with proper 14x14x20mm heatsink) goes very warm as if the CPU or GPU is working on full throttle.

I doubt it's an overheating issue due to the big heatsink, and the memory chips never really get warm at all. I'm starting to think that there's a defect in some "higher location" in one or both of the memory chips on my board, as the problem seems to occur only when memory usage ramps up. Doing nothing demanding in particular the device runs just fine with every OS I tried. My board has the same slightly bent shape that many others have pointed out theirs have.

Anyone experiencing the same? Do I have some kind of warranty on the board I got via backing the project?
  Reply
#2
(05-11-2016, 01:50 PM)pinecone Wrote: Been having the problem of whatever OS I run on the 1GB Pine64+ board constantly crashing when, if my suspicions are correct, high memory usage happens. In particular it will always happen when I browse a "heavy" page. Whether it's with Chrome on the Android 5.1 build, Midori on the Arch Linux build, or the browser in RemixOS, it's always the same problem with the same result - after just a few seconds of loading a heavy-ish page, the screen goes black and the device shuts off, or the screen goes black then white, device stays powered on, and the SoC (heatsinked with proper 14x14x20mm heatsink) goes very warm as if the CPU or GPU is working on full throttle.

I doubt it's an overheating issue due to the big heatsink, and the memory chips never really get warm at all. I'm starting to think that there's a defect in some "higher location" in one or both of the memory chips on my board, as the problem seems to occur only when memory usage ramps up. Doing nothing demanding in particular the device runs just fine with every OS I tried. My board has the same slightly bent shape that many others have pointed out theirs have.

Anyone experiencing the same? Do I have some kind of warranty on the board I got via backing the project?

If I were you I would try one of the two current linux builds, Ubuntu or debian. Stay away from gui if you can (potential for more bugs) I would run the stress app to rule out heat/power issues. You can then install memtester and run that to try to test your ram. 

It is not impossible that its the ram but its much much more likely that its a power issue.
  Reply
#3
(05-11-2016, 02:05 PM)rahlquist Wrote: If I were you I would try one of the two current linux builds, Ubuntu or debian. Stay away from gui if you can (potential for more bugs) I would run the stress app to rule out heat/power issues. You can then install memtester and run that to try to test your ram. 

It is not impossible that its the ram but its much much more likely that its a power issue.

Arch is one of the current Linux builds available, and it runs perfectly fine up until the point I launch a browser and load something "heavy". From a software perspective running X.org (or RemixOS/Android's GUI) isn't any more "potential for more bugs" than running any other variety of software, unless the GPU in the SoC happens to be damaged. Pure stressing of the CPU cores in any form doesn't trigger the problem. I'm running on a regulated 2A power supply, so a power issue doesn't seem likely either.

I'm gonna see if I can reproduce the problem another way, over ethernet instead of using the WiFi/BT module, and by filling up the RAM using a tmpfs RAM-disk.
  Reply
#4
(05-11-2016, 02:21 PM)pinecone Wrote: I'm gonna see if I can reproduce the problem another way, over ethernet instead of using the WiFi/BT module, and by filling up the RAM using a tmpfs RAM-disk.

Well, shit. It's the WiFi/BT module causing the crashing. I tried with multiple WiFi access points just to make sure it wasn't a compatibility problem between two specific devices, and that wasn't the case as I can reproduce the crashing every time with all WiFi setups I try. As soon as I use ethernet the problem goes away and everything works great.

Where do I go from here? The WiFi module was bought as an add-on, not part of my backing money, so I suppose there's a warranty right to be claimed?
  Reply
#5
(05-11-2016, 03:45 PM)pinecone Wrote:
(05-11-2016, 02:21 PM)pinecone Wrote: I'm gonna see if I can reproduce the problem another way, over ethernet instead of using the WiFi/BT module, and by filling up the RAM using a tmpfs RAM-disk.

Well, shit. It's the WiFi/BT module causing the crashing. I tried with multiple WiFi access points just to make sure it wasn't a compatibility problem between two specific devices, and that wasn't the case as I can reproduce the crashing every time with all WiFi setups I try. As soon as I use ethernet the problem goes away and everything works great.

Where do I go from here? The WiFi module was bought as an add-on, not part of my backing money, so I suppose there's a warranty right to be claimed?

There is 30 days warranty, if you think you received a bad Wifi/BT module, just PM me and I will make a replacement.
  Reply
#6
Just to add to the conversation....

Arch has been discontinued by it's maintainer longsleep.

I would suggest longsleep's ubuntu build or use my debian build which is built upon longsleep's work.

Of course you can continue with Arch too just putting in my 2 cents Wink
If you like my work be sure to check out my site or wish to donate to the cause

Cheers Big Grin
  Reply
#7
(05-11-2016, 03:45 PM)pinecone Wrote:
(05-11-2016, 02:21 PM)pinecone Wrote: I'm gonna see if I can reproduce the problem another way, over ethernet instead of using the WiFi/BT module, and by filling up the RAM using a tmpfs RAM-disk.

Well, shit. It's the WiFi/BT module causing the crashing. I tried with multiple WiFi access points just to make sure it wasn't a compatibility problem between two specific devices, and that wasn't the case as I can reproduce the crashing every time with all WiFi setups I try. As soon as I use ethernet the problem goes away and everything works great.

Where do I go from here? The WiFi module was bought as an add-on, not part of my backing money, so I suppose there's a warranty right to be claimed?

Does it crash when the driver for the Wifi is activated? If so its likely a power issue.
  Reply
#8
(05-11-2016, 03:45 PM)pinecone Wrote: It's the WiFi/BT module causing the crashing.

All the symptoms you name sound like the usual undervoltage problems so many users run into (you said you use a 2A PSU but you don't know the voltage provided to the board -- in case you have a multimeter use pins 2 and 6/GND on the Euler connector to check that).

In case you really want to nail the problem down you could use any Debian variant, then install RPi-Monitor (to see thermal effects) and then fire up 'stress -c 3 -m 3'.
  Reply
#9
(05-12-2016, 06:09 AM)rahlquist Wrote: Does it crash when the driver for the Wifi is activated? If so its likely a power issue.

No it doesn't crash until there's a massive and constant amount of traffic going over the WiFi link. Small/sporadic traffic does not trigger the problem. It's not a power issue - the power supply is regulated, and I've measured it under load so I know it holds a steady 5V. I suppose there's a small chance the problem is with one of the voltage regulators on the Pine board...


(05-12-2016, 08:11 AM)tkaiser Wrote: All the symptoms you name sound like the usual undervoltage problems so many users run into (you said you use a 2A PSU but you don't know the voltage provided to the board -- in case you have a multimeter use pins 2 and 6/GND on the Euler connector to check that).

In case you really want to nail the problem down you could use any Debian variant, then install RPi-Monitor (to see thermal effects) and then fire up 'stress -c 3 -m 3'.

Of course I know the voltage. It's a regulated 5V supply feeding the Pine via the USB connector, and I know it's stable because I've measured it under load. Maybe it's one of the regulators on the Pine board being the problem?
  Reply
#10
(05-12-2016, 08:41 AM)pinecone Wrote: It's a regulated 5V supply feeding the Pine via the USB connector, and I know it's stable because I've measured it under load.

Where did you measure? Pins 2/6 on Euler connector or somewhere else?
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Pine64 Suddenly Turnoff with Lcd mix359 3 1,601 Yesterday, 02:55 PM
Last Post: karlitos
  Pine64 (analog) Audio Jack Output w/ Kernel 4.19 ecolezen 0 1,191 01-24-2019, 07:00 AM
Last Post: ecolezen
  PINE64 STEREO AUDIO DAC POT jtgiroux 0 1,255 01-12-2019, 04:56 PM
Last Post: jtgiroux
  Does Pine64+ have an internal hardware watchdog ? rahlquist 8 6,527 04-26-2018, 06:27 PM
Last Post: pfeerick
  Using the pine64 with AVR - HDMI pass-through Moshe.Vazan 4 2,484 01-02-2017, 02:58 PM
Last Post: Moshe.Vazan
  I dropped my Pine64 DukeJustice 17 6,533 11-07-2016, 07:23 PM
Last Post: DukeJustice
  pine64+ cad files danlcarr 1 1,644 08-31-2016, 08:26 AM
Last Post: martinayotte
  Pine64+: 3 working, 1 shows nothing on tv zumtra 1 1,658 07-30-2016, 05:47 PM
Last Post: tllim
  mounting root filesystem via NFS on pine64+ issue martind1983 2 2,431 07-29-2016, 06:37 AM
Last Post: martind1983
  Cannot get PINE64 boards to boot andymelton 13 6,059 07-06-2016, 09:20 AM
Last Post: montero65

Forum Jump:


Users browsing this thread: 1 Guest(s)