Rock64 kernel panics
#11
(10-13-2021, 12:49 PM)clay Wrote: I booted into a fresh Armbian install and ran the board with no USB devices attached. I was optimistic at first, because it ran overnight (around 10 hours). But then it crashed. I tried bringing it back up multiple times, but after that first crash, it only lasted about 5-15 minutes each time before it crashed again. I'm not sure if it was just coincidence that it ran so long at first, or if there is, indeed, something related to USB.

Unfortunately, all the other 5V/3A power supplies in my collection have micro USB connectors, not the barrel connector needed for the Rock64.

Thanks again for the help troubleshooting!


Ok. I asked you a number of questions above and you've ruled some of them out. What I'm going to suggest now is remove any attached devices including monitor and any USB devices, remove the board from the case and use Armbian as you boot OS. That's exactly my setup here and my board runs flawlessly 24/7 and has done for nearly three years.

I've suggested to many users here before about swapping out the power supply as a first course of action and in many cases that's worked. To be honest I don't trust those official power supplies. Just for testing purposes the board will boot and run under a 5v 2amp supply but not under heavy load. I've done that myself. You might have one of those lying around. They are popular with the likes of IP webcams etc. Check and see first before sourcing a replacement 5v 3amp power supply. Until you've ruled that out you could waste hours troubleshooting this problem.

You can of course check the supplied voltage to the board with a multimeter. Also if I'm not mistaken Armbian will report under voltage instances. If you run the dmesg command it should yield some information.
  Reply
#12
(10-13-2021, 06:30 PM)Rocklobster Wrote:
(10-13-2021, 12:49 PM)clay Wrote: I booted into a fresh Armbian install and ran the board with no USB devices attached. I was optimistic at first, because it ran overnight (around 10 hours). But then it crashed. I tried bringing it back up multiple times, but after that first crash, it only lasted about 5-15 minutes each time before it crashed again. I'm not sure if it was just coincidence that it ran so long at first, or if there is, indeed, something related to USB.

Unfortunately, all the other 5V/3A power supplies in my collection have micro USB connectors, not the barrel connector needed for the Rock64.

Thanks again for the help troubleshooting!


Ok. I asked you a number of questions above and you've ruled some of them out. What I'm going to suggest now is remove any attached devices including monitor and any USB devices, remove the board from the case and use Armbian as you boot OS. That's exactly my setup here and my board runs flawlessly 24/7 and has done for nearly three years.

I've suggested to many users here before about swapping out the power supply as a first course of action and in many cases that's worked. To be honest I don't trust those official power supplies. Just for testing purposes the board will boot and run under a 12v 2amp supply but not under heavy load.  I've done that myself. You might have one of those lying around. They are popular with the likes of IP webcams etc. Check and see first before sourcing a replacement 12v 3amp power supply. Until you've ruled that out you could waste hours troubleshooting this problem.

You can of course check the supplied voltage to the board with a multimeter. Also if I'm not mistaken Armbian will report under voltage instances. If you run the dmesg command it should yield some information.

Rock64 SBC take 5V input.
  Reply
#13
I've ordered a new 5V/3A power adapter. I hope I'm not throwing good money after bad.

In the meantime, I ran dmesg, and came across the following lines that looked noteworthy. Unfortunately, I don't have the knowledge to interpret them, so thought I would post them here for possible feedback:


Code:
gpio-syscon ff100000.syscon:grf-gpio: can't read the data register offset!

Code:
rk_gmac-dwmac ff540000.ethernet: cannot get clock clk_mac_speed

Code:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000034f8b000
[0000000000000208] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP

Those first two lines were fairly close to each other. That last block was a few pages lower.
  Reply
#14
(10-14-2021, 05:07 PM)clay Wrote: I've ordered a new 5V/3A power adapter. I hope I'm not throwing good money after bad.

In the meantime, I ran dmesg, and came across the following lines that looked noteworthy. Unfortunately, I don't have the knowledge to interpret them, so thought I would post them here for possible feedback:


Code:
gpio-syscon ff100000.syscon:grf-gpio: can't read the data register offset!

Code:
rk_gmac-dwmac ff540000.ethernet: cannot get clock clk_mac_speed

Code:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000034f8b000
[0000000000000208] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP

Those first two lines were fairly close to each other. That last block was a few pages lower.

A quick search and it seems to point to power issues alright. Where did you order your replacement power supply from.

(10-14-2021, 12:46 AM)tllim Wrote:
(10-13-2021, 06:30 PM)Rocklobster Wrote:
(10-13-2021, 12:49 PM)clay Wrote: I booted into a fresh Armbian install and ran the board with no USB devices attached. I was optimistic at first, because it ran overnight (around 10 hours). But then it crashed. I tried bringing it back up multiple times, but after that first crash, it only lasted about 5-15 minutes each time before it crashed again. I'm not sure if it was just coincidence that it ran so long at first, or if there is, indeed, something related to USB.

Unfortunately, all the other 5V/3A power supplies in my collection have micro USB connectors, not the barrel connector needed for the Rock64.

Thanks again for the help troubleshooting!


Ok. I asked you a number of questions above and you've ruled some of them out. What I'm going to suggest now is remove any attached devices including monitor and any USB devices, remove the board from the case and use Armbian as you boot OS. That's exactly my setup here and my board runs flawlessly 24/7 and has done for nearly three years.

I've suggested to many users here before about swapping out the power supply as a first course of action and in many cases that's worked. To be honest I don't trust those official power supplies. Just for testing purposes the board will boot and run under a 12v 2amp supply but not under heavy load.  I've done that myself. You might have one of those lying around. They are popular with the likes of IP webcams etc. Check and see first before sourcing a replacement 12v 3amp power supply. Until you've ruled that out you could waste hours troubleshooting this problem.

You can of course check the supplied voltage to the board with a multimeter. Also if I'm not mistaken Armbian will report under voltage instances. If you run the dmesg command it should yield some information.

Rock64 SBC take 5V input.

Typo updated now.
  Reply
#15
Unfortunately, I have to report back that the new power supply hasn't changed the situation. Manjaro XFCE and Armbian both continue to crash within 10-20 minutes after every boot. (I bought the new adapter through Amazon, but am not sure why that's pertinent, especially since we're seeing the exact same behavior between the official adapter and this one.)

I absolutely appreciate the community's attempts to help here, but after a week of runaround from Pine64 support, and no progress, this is getting tiresome and frustrating. Sadly, Pine64 support has been less than helpful. After looking at this thread, they claim it's still inconclusive that this is a hardware issue, and have pawned me off on the retailer. I can't understand why Pine64 would try to get a retailer to take a loss for what are clearly engineering and/or manufacturing shortcomings that are evident throughout these forums and other places around the Web. Maybe they're just trying a weak and transparent attempt to make the retailer the bad guy who has to tell me to take a hike.

In an effort to be a cooperative customer, I've tried running the board with nothing except an Ethernet cable attached. It's a baffling request, that makes one ask why it comes equipped with other connectivity if they're likely to cause the board to become unstable. Even if connecting nothing except Ethernet did bring the board to stability, are we not still honing in on it being a hardware issue? And if that did fix it, but doesn't fit my use case or needs, am I in any better position? The whole exercise has been perplexing.

Definitely a disappointing experience.
  Reply
#16
(10-17-2021, 05:20 PM)clay Wrote: Unfortunately, I have to report back that the new power supply hasn't changed the situation. Manjaro XFCE and Armbian both continue to crash within 10-20 minutes after every boot. (I bought the new adapter through Amazon, but am not sure why that's pertinent, especially since we're seeing the exact same behavior between the official adapter and this one.)

I absolutely appreciate the community's attempts to help here, but after a week of runaround from Pine64 support, and no progress, this is getting tiresome and frustrating. Sadly, Pine64 support has been less than helpful. After looking at this thread, they claim it's still inconclusive that this is a hardware issue, and have pawned me off on the retailer. I can't understand why Pine64 would try to get a retailer to take a loss for what are clearly engineering and/or manufacturing shortcomings that are evident throughout these forums and other places around the Web. Maybe they're just trying a weak and transparent attempt to make the retailer the bad guy who has to tell me to take a hike.

In an effort to be a cooperative customer, I've tried running the board with nothing except an Ethernet cable attached. It's a baffling request, that makes one ask why it comes equipped with other connectivity if they're likely to cause the board to become unstable. Even if connecting nothing except Ethernet did bring the board to stability, are we not still honing in on it being a hardware issue? And if that did fix it, but doesn't fit my use case or needs, am I in any better position? The whole exercise has been perplexing.

Definitely a disappointing experience.

No doubt you are familiar with the troubleshooting process and a complete peripheral strip back would be in order to rule out each individual component. A bare metal setup to get the board booting and stable would be the objective here. From there each peripheral could be added back until the board becomes unstable and the offending hardware can be isolated.

Hobbyist/tinkerers boards are by nature hit and miss. I quickly found that Armbian was right for me. I intended to run headless as a home automation server with a wifi dongle and two other USB devices attached. The board runs stable. What I never use on an SBC is a case, purely to avoid overheating problems. Again that's just me.

I really do suggest running the board as bare metal as possible and add back peripherals one by one until you isolate the source of instability. If nothing else you'll have satisfied the retailer for the basis of a claim for a replacement/refund.

As suggested run the memtest to check the memory integrity if you haven't already done so. I can't stress enough the importance of a stable power supply. There's so much junk on sale out there even from so called reputable suppliers. That's why I asked where you made your purchase from. Two absolute musts are a stable power supply and a quality SD card.

I'll leave it at that for now. It's entirely up to you how you want to proceed.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Pine Rock64 eMMC lifespan moonspell79 3 529 08-19-2021, 06:46 PM
Last Post: bcnaz
  Rock64 No Audio - Solved wbecks 12 17,758 08-13-2021, 01:23 PM
Last Post: blakeadam
Question Hardware issues with Rock64 grobbs 11 3,060 07-24-2021, 10:23 AM
Last Post: robinkyle11
  Trustzone support for Rock64 capablegh 1 420 07-17-2021, 10:15 AM
Last Post: capablegh
  Python GPIO Library for the Rock64 (R64.GPIO) Leapo 37 41,354 07-02-2021, 03:20 PM
Last Post: klausfelix
  rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? klausfelix 0 365 07-02-2021, 03:13 PM
Last Post: klausfelix
Information Serial Console for the Rock64 MarkHaysHarris777 33 35,011 06-24-2021, 12:24 PM
Last Post: mikeklien
  lost eletronic component rock64 marvin1986 1 656 06-01-2021, 06:27 PM
Last Post: 8bit
Shocked Rock64 - Reboots after few minutes addezai 2 935 04-22-2021, 07:03 PM
Last Post: addezai
  Rock64 Long Term stability ramprasad 4 2,630 03-16-2021, 07:23 PM
Last Post: Rocklobster

Forum Jump:


Users browsing this thread: 1 Guest(s)