1 1
AxelFoley

sick and tired of my Armbian desktop locking and crashing

Recommended Posts

@pfry

 

Looking at the power Specifications for PCIe x 4 => Suggest that it can be powered from 3.3v (9.9W) & 12v (25W), however from the RockPro64 Power schema it looks like they negate to feed the 12v rail from the Supply voltage to the PCIe.

 

Instead Pine feeds the PCIe Interface on the board only by the 3.3v (3A) rail (9.9W).

From the Power schema It also looks like the board designers feed PCIe from the 5.1v rail converted by the RK808 PMU to 1.8v on vcc1v8_pcie (not sure how this is intended to be used on PCIe) 

 

 

I am using the Pine PCIe ver 3.0 NVMe Card with a Samsung 970 EVO 500GB and a RockPro64 v2.1 Board.  PSU is a 102W 12v LRS-100-12

 

The Max power draw of the EVO 970 NVMe is 5.8W (1.76A) which should be within spec for that 3.3v rail.

 

But this bit worry's me    "vcc_sys: could not add device link regulator.6 err -2"   

 

vcc_sys is the 3.3v rail that feeds the vcc3v3_pcie feed into the PCIe Socket.

Although dmeag later says it can enable a regulator for the 3.3v vcc3v3_pcie rail hanging off vcc3v3_sys.

 

I also see this warning;

 


"Apr  8 19:09:24 localhost kernel: [    2.010352] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-1f] (conflicts with (null) [bus 00-1f])"

 

I may have to get out a JTAG debugger to work this one out :-( 

 

Not sure if this is a kernel driver issue or HW Power design. 

 

ill see if I can get any Gerber files to scope out the voltage and current spikes.

 

 

Share this post


Link to post
Share on other sites

What version RockPro do you have? I think it is 2.0 that has PCI hardware bugs and there is a conflict between wireless and pci somehow. The v2.1 addresses some of the issues.

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites
19 hours ago, AxelFoley said:

 

@AndrewDB    .... looks like you may be correct it was power all along  but it looks like its a kernel issue with the PCIe Power Management ?

Well, I think the one conclusion one can draw here is that it's a bad idea to rely on experimental hardware with a not fully debugged kernel for real, serious development work. As chwe wrote, perhaps a more "conservative" approach would yield better results?

 

Unfortunately I am of the humble opinion that by the time you get your cluster to function reliably and are able to begin using for development work, the rk3399 will be considered obsolete, and you will have invested a lot of time, energy and moolah in essentially what will have become a paperweight.

 

Still, I hope you can sort it out asap. Best of luck! :thumbup:

Share this post


Link to post
Share on other sites
8 hours ago, AxelFoley said:

@pfry

 

Looking at the power Specifications for PCIe x 4 => Suggest that it can be powered from 3.3v (9.9W) & 12v (25W), however from the RockPro64 Power schema it looks like they negate to feed the 12v rail from the Supply voltage to the PCIe.

 

Scroll down to sheet 27 of the schematic.

 

8 hours ago, AxelFoley said:

Instead Pine feeds the PCIe Interface on the board only by the 3.3v (3A) rail (9.9W).

From the Power schema It also looks like the board designers feed PCIe from the 5.1v rail converted by the RK808 PMU to 1.8v on vcc1v8_pcie (not sure how this is intended to be used on PCIe) 

 

The 1.8V power is for the PCI-e phy (power/enable/both? - I didn't look that closely), not the slot itself. If the RK808 wiring is board-specific it could explain a lot of the difficulties with individual boards (I haven't compared 'em).

Share this post


Link to post
Share on other sites

Some regulators can be/are used differently for different boards. For instance, the RK808 is also used on the MiQi and Tinker board RK3288 boards.

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites
58 minutes ago, TonyMac32 said:

Some regulators can be/are used differently for different boards. For instance, the RK808 is also used on the MiQi and Tinker board RK3288 boards.

I was just referring to the RK3399 boards (given the extra regulators for the A72s and GPU, it's apparent that the RK808/818 was designed for a less power-hungry SOC), but yeah, it's pretty obvious to me now (!) that the implementations vary. A lot, considering the relatively minor variances, mostly in the peripherals (audio codec, W-Fi, eMMC, etc.). The Realtek Ethernet phy is pretty much a standard, at least. What a tangle. Nothing that can't be solved with enough time and money. It's too bad both are tough to come by.

Share this post


Link to post
Share on other sites

I have been monitoring the voltage and current draw of an individual RockPro64 on boot with the PCIe NVME Connected going to console.

I then launched the desktop as both root (Armbian desktop) and pico user (looks like XFCE) and looked for any power spikes.

There was none!

Both tests caused a lockup and HW Freeze.

On boot the peak current draw was 0.7A with 12v steady, and current draw dropping to 0.3A steady.

Then I launched Xorg as root (in the past tended to be more stable) and user pico (always locked up immediately)

 

I did notice a difference when I ran startx as pico user and it launched XFCE .. its current draw peaked at 0.7a and voltage dropped to 11.96V

Desktop immediately locked the board on launch.

 

When I ran startx as root and it launched armbian desktop ... it only peaked at 0.6A and voltage never dipped below 12v.

The desktop was responsive until when I loaded the Armbian forum in chrome and triggered the board lockup ..... there was no current spike or voltage drop! The board locked up while only drawing 0.29A.

 

I checked the Pine forum and other people are reporting exactly the same issue as myself with the PCIe/NVMe setup.

One person in 2018 reported he fixed the issue by launching a different kernel.

 

I have logged the problem on the pine forum and got this response;

 

"Currently working on the issue. It seems - as odd is its sounds - that the problem is somehow linked to pulseaudio. If you uninstall pulseaudio, and use alsa instead, the issue will just vanish. We have tried blacklisting PCIe for pulse in udev, and it prevents the issue from happening, but it also returns a segmentation error (SATA card / other adapter not accessible). Its very very strange".

 

Should I stop posting here and move the discussion to Pine ?

 

 

 

 

 

 

XFCEDesktopPowerDraw.jpg

ArmbianDesktopPowerDraw.jpg

ArmbianDesktopLockup.jpg

Share this post


Link to post
Share on other sites
1 1