Jump to content

Freezing problem with Olimex A20 Lime 2


PaceyIV

Recommended Posts

I have a problem similar to post http://forum.armbian.com/index.php/topic/182-freezing-problems-with-bpi-r1/:my board is blocked for the second time.

But my configuration is quite different from that post:

Kernel: linux-image-next-sunxi 4.3 (version 4.2.0-sunxi)

UBoot: linux-image-next-sunxi 4.3 (2015.07)

RootFS: on sda1 powered by the board (WDC WD10JFCX-68N)
UpTime: about 10 days before my last restart.
 
When the board is blocked I can't interact with the debug console on the serial port.
I cant't find anything interesting in /var/log, but I'm not really an expert.
 
 
 
Link to comment
Share on other sites

It just hangs, I know. It happened to me too.

 

It's an rear event so it's very hard to catch. I suspect u-boot, because troubles are present in both kernels.

 

Hardware. That's all you have? Nothing on USB?

Link to comment
Share on other sites

Ok. 

 I've done this.

$ sudo apt-get purge linux-u-boot*
$ sudo dpkg -i linux-u-boot-4.0.4-lime2_1.8_armhf.deb

Now I'm coping some files, then I will restart the system.

Is there some options to enable a verbose log of kernel or something else useful to discover the problem?

 

Link to comment
Share on other sites

I would say conditions are normal at least theoretical. Power supply can be faulty, board can be faulty and yes kernel / u-boot too.

 

Let's see if this will do any better. Remember to reboot ;)

Link to comment
Share on other sites

You should be aware that if you power the 2.5" disk via the board then you might run into power supply troubles. You should first check the power scheme Olimex uses.

 

There are two alternatives:

 

  • connecting the SATA power header directly to power-in (this is the way Banana Pi/Pro do it for example). If power-in isn't available the SATA disk (with your rootfs on it) will have to spindown. On the other hand if the board's AXP209 PMU decides that there are voltage drops or an undercurrent situation on power-in and it switches to LiPo then the disk won't be affected
  • the SATA power header is driven also by the PMU (that's the way it is implemented on Lamobo R1). Would then be interesting what happens if the PMU switches between power-in (5V) and LiPo (3.7V) or how good the necessary step-up converters on the board work.

 

In other words: You should check schematics of the board, you should get a second SD-card, use Igor's image with Kernel 3.4.x, install RPi-Monitor with sunxi additions and get a clue what's happening regarding power sources. You can search ages for software bugs if it's just an issue with your power supplies (two of them with a PMU in between that implements special logic on its own)

Link to comment
Share on other sites

The hard disk is not powered directly to the power-in: the battery can power the board and the hard disk.

I've bought the battery to power both of them otherwise I would have taken a ups.

 

I've removed the plug and placed again an the board doesn't hung.

Link to comment
Share on other sites

No, that won't work out of the box. Their uboot probably don't support booting zImage type. You will need to convert it to uImage. Boot scripts might also need some adjustments ...

 

Do you have any EMR near by? Any other electric circuits?

 

My test subjects are still alive, one for 17 days, other 6. No hanging or any sings of problems.

Link to comment
Share on other sites

There is nothing powered near the board.

The board is new, it has about 1 month.

 

Maybe the easier thing is just try the olimex image, copy the kernel firmware from the microsd to the rootfs on the sata, an try a couple of week this settings. So I can use the olimex kernel and uboot, but my actually rootfs.

In the weekend I will try.

Link to comment
Share on other sites

I am just finishing new build, probably tomorrow there will be a legacy (3.4.109) build from another source and 4.2.3

 

Both my Olimex's are still online, one has 4.2.2, other 3.4.108.

 

If no system is stable on your board (bare, without any plugs to USB or else) and if you try different power supplies it could be a defect board. It happens.

Link to comment
Share on other sites

Best chances are with Wheezy if you seek stability. Kernel 4.x is also not completely o.k., I fixed some bugs in latest build.

 

Try this image:

http://mirror.igorpecovnik.com/Armbian_4.5_Lime2_Debian_jessie_4.2.3.zip

(wait until is fully uploaded. can take some time, up to 1h)

 

Or better:

 

http://mirror.igorpecovnik.com/test/linux-image-next-sunxi_4.5_armhf.deb

 

Just update kernel and reboot.

Link to comment
Share on other sites

I see that there is some updates about kernel with the debian jessie image you gave me.

You are trying the board with also these updates?

 
  linux-dtb-next-sunxi
  linux-firmware-image-next-sunxi
  linux-headers-next-sunxi
  linux-image-next-sunxi
  linux-jessie-root-next-lime2
Link to comment
Share on other sites

I haven't update to latest yet if you are asking me that. This requires reboot which I don't wont to do yet. 

Update is usually safe. I do some tests but some minor issues might occur. It happened before and it will in the future.

 

BTW. Package names are always the same but their version is changing.

Link to comment
Share on other sites

You're right, I'm sorry.

I'm a bit confused.

In your post you suggest me to try an image or update kernel with the package 4.5.

 

With the image now I can see this (I've just learned how to show upgrade details with apt-get --just-print upgrade)

The following packages will be upgraded:
  linux-dtb-next-sunxi linux-firmware-image-next-sunxi
  linux-headers-next-sunxi linux-image-next-sunxi linux-jessie-root-next-lime2
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst linux-dtb-next-sunxi [4.2] (4.5 . jessie:jessie [armhf])
Inst linux-firmware-image-next-sunxi [4.2] (4.5 . jessie:jessie [armhf])
Inst linux-headers-next-sunxi [4.2] (4.5 . jessie:jessie [armhf])
Inst linux-image-next-sunxi [4.2] (4.5 . jessie:jessie [armhf])
Inst linux-jessie-root-next-lime2 [4.2] (4.5 . jessie:jessie [armhf])
Conf linux-dtb-next-sunxi (4.5 . jessie:jessie [armhf])
Conf linux-firmware-image-next-sunxi (4.5 . jessie:jessie [armhf])
Conf linux-headers-next-sunxi (4.5 . jessie:jessie [armhf])
Conf linux-image-next-sunxi (4.5 . jessie:jessie [armhf])
Conf linux-jessie-root-next-lime2 (4.5 . jessie:jessie [armhf])

The kernel in the image is 4.1.6 (uname -a response)

Linux olimexa20 4.1.6-sunxi #22 SMP Tue Aug 25 17:54:51 CEST 2015 armv7l GNU/Linux

But in your post you put the kernel 4.5 as an alternative of the image.

 

You can confirm me that your boards are using 4.1.6 and we are doing the same test?

 

In the board I have installed only apache, samba and minidlna.

I'll wait more that my maximum uptime of ten days before install transmission.

Link to comment
Share on other sites

I'm very sad.

The board hangs again.

Every time after about 10 days.

If it was an heat problem, or a damaged board I think the uptime should be very different every time.

I will try official Olimex image. 

 

In the worst case I will reset my board every 7 days.

Link to comment
Share on other sites

I have no idea what else. Board HW issue and a power supply? I would test with different one.

 

All of my "test subjects" are still alive. I upgrade kernel on one so uptime is not full but still it's 11 days, longest 32.

Link to comment
Share on other sites

Oh, I had this problems too. (every few weeks at two of ~10 boards). The hardware watchdog is also not working. Its independent from the power supply.

 

Try to disable the frequency switching in /etc/default/cpufrequtils:

GOVERNOR="performance"

and reboot.

 

Now it runs stable since months with 1GHz on all boards.

 

Maybe that the Power-Chip AXP209 detects some under/overvoltage and stops the whole system while changing frequency and voltage.

Btw. I had also some kernel panics while reading the cpu frequency from the proc system.

Link to comment
Share on other sites

Thanks for the advice, but there is something wrong.

The governor used in the armbian image is "ondemand", but there is no /etc/default/cpufrequtils

$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 244 us.
  hardware limits: 144 MHz - 960 MHz
  available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 480 MHz and 960 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 528 MHz.
  cpufreq stats: 144 MHz:0.00%, 312 MHz:0.00%, 528 MHz:98.64%, 720 MHz:0.54%, 864 MHz:0.09%, 912 MHz:0.03%, 960 MHz:0.70%  (6964)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 244 us.
  hardware limits: 144 MHz - 960 MHz
  available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 480 MHz and 960 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 528 MHz.
  cpufreq stats: 144 MHz:0.00%, 312 MHz:0.00%, 528 MHz:98.64%, 720 MHz:0.54%, 864 MHz:0.09%, 912 MHz:0.03%, 960 MHz:0.70%  (6964)
Link to comment
Share on other sites

The ondemand or interactive governor switches the cpu frequence. Additional to the frequency, the voltage is changed too, which may be problematic.

 

This file may be new, you have to create it (exactly "/etc/default/cpufrequtils"). It' read in /etc/init.d/cpufrequtils:

ENABLE="true"
GOVERNOR="interactive"
MAX_SPEED="1010000"
MIN_SPEED="480000"
...
if [ -f /etc/default/cpufrequtils ] ; then
        . /etc/default/cpufrequtils
fi

You may also restart only this service-script, probably.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines