Jump to content

Freezing problem with Olimex A20 Lime 2

PaceyIV

By PaceyIV
in Allwinner sunxi

 Share

Recommended Posts

monti

monti

Posted
Posted

No, these ones not.

45-52°C normally. But this is not the problem in this case because if you have max load, the ondemand governor will also speed up to 1 GHz.

 

Just try it and tell us if it gets better or not! Not even a restart is required, but verify it with cpufreq-info before and later if the performance is really running.

Link to comment
Share on other sites
kwa

kwa

Posted
Posted

I've an Olimex Lime 2 and I also have freezing problems.

 

The setup is Olimex Lime2 with SATA-drive connected (drive is powered with additional power supply), console cable connected and network disconnected.

The board freezes when i run a task, that does a lot of reads on the filesystem and there are some big files involved. It freezes sometime during the task. There is no console output that gives any hint.

 

I've tried different power supplies, with or without battery pack. Same problem occurs, when I connect USB-drive instead of SATA-drive.

I've tried different u-boot/kernel combinations (armbian, olimex, debian installer).

I've tried different settings for "frequency switching" as described here.

 

The only stable running system is with "a20-lime2_debian_3.4.90_release_2".

This is base on sunxi-uboot and sunxi-kernel.

 

Any ideas?

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Don't have any smart idea ... perhaps try lowering DRAM speed in u-boot.

 

BTW: Armbian forum is running Armbian Wheezy on Lime2, legacy 3.4.106 ... it never hanged. All downtime was made by human error ;)

1
Link to comment
Share on other sites
lebeno

lebeno

Posted
Posted

I have been experiencing the same problem: freezing almost every day or every week. Running Debian Jessie Vanilla with SSD. I have even upgraded my power supply to a full ATX (PC) power supply, and LiPo battery, but still freezing. I checked the power demand with a digital multimeter in MIN/MAX mode and the current never went above 500mA. I doubt this is a power issue, and if it is, it is on the board, not the external power supply.

 

I also see a lot of ATA errors in /var/log/syslog:

[  753.731120] ata1.00: exception Emask 0x0 SAct 0x600 SErr 0x0 action 0x0
[  753.731144] ata1.00: irq_stat 0x40000000
[  753.731161] ata1.00: failed command: READ FPDMA QUEUED
[  753.731184] ata1.00: cmd 60/08:48:20:cf:f4/00:00:24:00:00/40 tag 9 ncq 4096 in
         res 41/04:08:20:cf:f4/00:00:24:00:00/00 Emask 0x401 (device error) <F>
[  753.731196] ata1.00: status: { DRDY ERR }
[  753.731203] ata1.00: error: { ABRT }
[  753.731212] ata1.00: failed command: READ FPDMA QUEUED
[  753.731232] ata1.00: cmd 60/08:50:28:1e:c0/00:00:24:00:00/40 tag 10 ncq 4096 in
         res 41/04:00:20:cf:f4/00:00:24:00:00/40 Emask 0x1 (device error)
[  753.731242] ata1.00: status: { DRDY ERR }
[  753.731249] ata1.00: error: { ABRT }
[  753.731552] ata1.00: supports DRM functions and may not be fully accessible
[  753.732143] ata1.00: supports DRM functions and may not be fully accessible
[  753.732397] ata1.00: configured for UDMA/133
[  753.732500] sd 0:0:0:0: [sda] tag#10 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  753.732519] sd 0:0:0:0: [sda] tag#10 Sense Key : 0x5 [current] [descriptor]
[  753.732532] sd 0:0:0:0: [sda] tag#10 ASC=0x21 ASCQ=0x4
[  753.732552] sd 0:0:0:0: [sda] tag#10 CDB: opcode=0x28 28 00 24 c0 1e 28 00 00 08 00
[  753.732563] blk_update_request: I/O error, dev sda, sector 616570408
[  753.732615] ata1: EH complete

Do any of you see ATA erros in syslog? I do not know if this is related to the freezing problem. I have tried other SATA cable, but same result.

 

Today, I was monitoring /var/log/syslog and I saw litteraly multiple pages of logs dumping on the HDMI screen because of a crash. I was able to take a picture of the last screen, see http://imgur.com/37ZXssp.

 

EDIT 2016-04-01, extra info:

  • I am running ARMBIAN Debian GNU/Linux 8 (jessie) 4.4.1-sunxi
  • rootfs on uSD card, SSD only holds extra data in ext4
  • I have changed the governor to performance and no problems yet. No SATA errors in syslog, no craches.
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

Unfortunately a lot of informations are missing, eg. which Armbian and kernel version, which distro (Wheezy, Jessie, Trusty?), rootfs on SATA or not.

 

In case you're not running wheezy do an

sudo apt-get -f -qq -y install smartmontools
sudo smartctl -a /dev/sda | grep 199

And if you're running wheezy think about downloading/updating armbianmonitor instead and then running "sudo armbianmonitor -d" before calling smartctl since this will install and patch smartmontools on Wheezy (package outdated as hell as usual and not able to update the disk database).

Link to comment
Share on other sites
kwa

kwa

Posted
Posted

I tried with lowering the DRAM speed in u-boot and lowered it to 384 MHz.

 

Compiled for Armbian_5.07_Lime2_Debian_jessie_4.4.6, with u-boot (v2015.10) and modified A20_OlinuXino-Lime2_defconfig

 

No freezing issues any more  :)

 

Thank you very much, Igor.

1
Link to comment
Share on other sites
lebeno

lebeno

Posted
Posted

Unfortunately a lot of informations are missing, eg. which Armbian and kernel version, which distro (Wheezy, Jessie, Trusty?), rootfs on SATA or not.

 

@tkaiser Added that to my post under EDIT 2016-04-01, extra info.

 

In case you're not running wheezy do an

sudo apt-get -f -qq -y install smartmontools
sudo smartctl -a /dev/sda | grep 199

 

This is the smart output:

# smartctl -a /dev/sda | grep 199
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       18
Link to comment
Share on other sites
djojo

djojo

Posted
Posted

I tried with lowering the DRAM speed in u-boot and lowered it to 384 MHz.

 

Compiled for Armbian_5.07_Lime2_Debian_jessie_4.4.6, with u-boot (v2015.10) and modified A20_OlinuXino-Lime2_defconfig

 

No freezing issues any more  :)

 

Thank you very much, Igor.

 

Thank you for the idea ! It's ok for me now, no more freeze.

Any idea how to create a patch to auto lower the sdram ? like the one for specifying BOOTBRANCH="v2015.10" ...

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Create a patch from lime u-boot config file difference

diff -u originalconfig updatedconfig > my_dram_settings.patch

and once this "my_dram_settings.patch" is done, place it to the 

userpatches/kernel/sunxi-next

and your u-boot will be always build with those altered settings.

1
Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

Create a patch from lime u-boot config file difference

...

and your u-boot will be always build with those altered settings.

 

More specifically, after editing config file, execute in u-boot sources root directory

git diff configs/A20-OLinuXino-Lime2_defconfig > my_dram_settings.patch

and place it in one or both of these paths

userpatches/u-boot/u-boot-default
userpatches/u-boot/u-boot-next
1
Link to comment
Share on other sites
nabbal

nabbal

Posted
Posted

Hello,

 

I have some stability issues also with the Vanilla Jessie Armbian.

I have a Lime 2 (rev C) board which works perfectly fine, I recently bought a new one, and this board randomly hangs. I have tested many times with the same configuration that the working board (same SD card, power source).

It seems to happen more frequently when the load on the board increases.

 

So I tried changing the "governor" value in /etc/default/cpufrequtils to performance. Same issues.

I have built a new image, lowering the DRAM clock to 384. The board still hangs randomly.

 

As it is the first time I build a new image, I want to make sure that the modification on the DRAM clock speed is in the image.

Is it possible to check on a running board the DRAM clock frequency? If yes, how?

Link to comment
Share on other sites
neomanic

neomanic

Posted
Posted

We have 2x lime2-emmc boards in production now. We were having random hangs on both, and fortunately I remembered this thread. Changing the cpufreq settings such that it was locked at 960 MHz has solved the issue.

 

We're still getting a hang once a day but only on one of the lime2s, so it's likely to be a separate issue. Fortunately, having the hardware watchdog timer set up to reboot the system means that it doesn't cause any major problems.

Link to comment
Share on other sites
monti

monti

Posted
Posted

Hi,

 

you can also try the built-in watchdog. But unfortunatelly, event that's not always working reliable (maybe the Power-Chip goes into safe mode, which is before the processor-watchdog)

Link to comment
Share on other sites
Quadrifoglio Verde

Quadrifoglio Verde

Posted
Posted

 

More specifically, after editing config file, execute in u-boot sources root directory

git diff configs/A20-OLinuXino-Lime2_defconfig > my_dram_settings.patch

and place it in one or both of these paths

userpatches/u-boot/u-boot-default
userpatches/u-boot/u-boot-next

 

Hello, It works, but only for booting from SD, when board boot from NAND then freq. is back on 480Mhz.

Can somebody help me, how to keep lower frequency in case when board boot from NAND?

 

thank you.

Link to comment
Share on other sites
neomanic

neomanic

Posted
Posted

Okay, so we are now are having the same issues with 5 separate Lime2-eMMC rev E boards, which are running SSDs, batteries (to allow for clean shutdown), 2x USB devices and Ethernet. Running recent Armbian, mainline kernel.

 
Changing the CPU governor via cpufrequtils really reduced the number of hangs (from daily), but we are still getting them sporadically, perhaps once a week.
 
We have set the watchdog timer on, so when the board does hang then it reinitialises itself and is back online within 60 seconds. But obviously this is an issue we would like to address.
 
Our next step, assuming that no-one has other suggestions, is to try a legacy kernel.
Link to comment
Share on other sites
PaceyIV

PaceyIV

Posted
  • Author
Posted

After 10 days (I think!) the board freeze again.

If I try to get some html page I've get the timeout error.

If I try to connect to it by ssh using putty I get no error, only the black screen. Same behavior with the debug console.

 

The strange thing is that the board responds to ping request (<= 2ms).

 

Armbianmonitor available at link http://sprunge.us/MQJK

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