Posts posted by zgoda_j
Just recently started getting ICE when building large C/C++ code using both GCC and CLANG. I suppose memory is failing in some way related to HW. On x86 Ubuntu I have memtest86+ in GRUB, but how do I test for memory errors on Armbian? I tried memtester and stressapptest but they test only part of memory, and so far don't show any errors, does something similar to memtest86+ exist for ARM?
Benefits of buying locally - I will have replacement next week.
I'm building devices for sale to end users and I do not expect them to disassemble the device to fiddle with SD card.
Bought it from local supplier so replacement is feasible by all means.
Received a batch of OPi PCs and one is not booting. In serial console I get only:
U-Boot SPL 2016.09 (Oct 15 2016 - 14:20:45) DRAM: 1024 MiB Trying to boot from MMC1
And that's all. What's wrong with it? SD card and PSU verified working with another OPi devices.
Network Manager manages only interfaces not configured elsewhere. Remove it from /etc/network/interfaces first if you want it to be managed by NM.
This misbehaviour is not consistent. In most times SSH session does not time out and hangs indefinitely, sometimes it times out and on rare occasions it closes gracefully.
OK, tried to follow procedure. Verbosity is already at max:
$ cat /boot/armbianEnv.txt | grep verbosity verbosity=7
So next step - check storage integrity:
$ armbianmonitor -c / mktemp: failed to create directory via template '//cardtest.XXXXXX': Permission denied /usr/bin/armbianmonitor: line 731: /.starttime: Permission denied $ sudo armbianmonitor -c / Checking disks is not permitted as root or through sudo. Exiting
This is the only device with 8189FTV I have. I have other boards with built in wifi but they have other chip and are not H3 based. This is:
$ uname -a Linux opi3 3.4.113-sun8i #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017 armv7l GNU/Linux
$ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepilite BOARD_NAME="Orange Pi Lite" VERSION=5.25 LINUXFAMILY=sun8i BRANCH=default ARCH=arm IMAGE_TYPE=stable
Armbianmonitor log -> http://sprunge.us/KTMD
Normally pam-systemd closes all user sessions upon power off, including SSH sessions. This looks differently, on client I see SSH session hanging, after issuing eg. sudo reboot board reboots but the session on client remains in half-dead state:
17813 pts/7 S+ 0:00 | | \_ ssh -vvv email@example.com
Which means it's still waiting for some event. Eventually I get packet_write_wait and session times out on client, so I suppose pam does not have chance to close user session.
Sometimes session on client does not time out and I have to kill it manually, IDK why:
$ sudo poweroff debug3: send packet: type 1 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1) debug1: Killed by signal 15.
Does the silence here means nobody apart me is affected by this?
Disabling forced module unloading in /etc/init.d/armhwinfo (commented out the whole line) and no change. Then uncommented the line and added systemctl stop ssh just before this line and still ssh session is not closed properly.
Perhaps this is related to GPIO power being cut too early?
Banana Pro with current Jessie server behaves correctly wrt built in wifi so I think this is specific to OPi Lite and its driver/wifi chip.
I have couple H3 and A20 devices and all run fine except one - Opi Lite, running latest Arbian (5.26) with built in wifi connected does not close SSH session upon reboot/poweroff. The session eventually times out on client but sometimes I have to kill it manually. There are no modifications to PAM nor systemd-logind configurations and the configuration is exactly the same as on other devices. I'm wondering what may cause this misbehaviour, and how can I fix this?
(This topic was created yesterday before db failure/site update and I can't find it now on restored site, I guess it has been lost)
Hi all, i have same display for long time but without usb. I followed this guide and i have display up and running finaly. I still cant get touch-pad running. Did anyone managed to get that touch screen running on Orange Pi PC over SPI?
Here's Waveshare page that describes pins used for touch device - http://www.waveshare.com/wiki/5inch_HDMI_LCD(see "Interface" section). You may want to check Raspbian configuration they provide in installer package.
Perhaps because you built your websockets library against older libmosquitto. I would try to purge websockets lib and mosquitto and start again with building mosquitto first. This way library will link to new libmosquitto.
Speaking of cheap - never had any problem with ralink chips supported by rt2800usb module but you don't get it any cheaper than $2.60 (rt5370) so $2 for built in wifi is bargain.
I did this on A20's Banana Pro but iirc the installation did not require more than simple apt-get... QtQuick is other story because it requires working OpenGL implementation and couple of things has to be compiled from sources.
I always keep Bananian image handy for quick debugging on LeMaker BananaPro. Sometimes something does not work in Armbian and works OK in Bananian so I can boot Bananian to find working configuration.
The one big difference at OS level is that Bananian does not use systemd - this makes it a bit simpler and some things like usbmuxd daemon work better with legacy kernel if launched directly by udevd not by systemd-udevd. But it's a matter of preference and what fits better your use case. For some devices I'm working on Bananian fits better, for other Armbian is at advantage.
Commodity is the key here, I think.
CNX-Software just posted that H2 based Orange Pi Zero appeared on Aliexpress for $7. It has been showcased here before, but now is on sale officially, though I can't find 512MB version on the store pages.
I'm eager to try 256MB version as my home IoT hub (mosquitto + nginx + uwsgi + Twisted, with MySQL database running on Zyxel NAS). It started with OPi PC then I switched to OPi One but I see it still can be lower spec device.
NM management worked fine with another Ralink card. Worth trying.
That's because they don't support nl80211, only wext.
Repeat after every kernel update.
See this discussion on Arch linux forum -> https://bbs.archlinux.org/viewtopic.php?id=194658
I doubt drivers for these chips will ever be included in kernel tree, wext is pending deprecation (or is deprecated already) -> https://wireless.wiki.kernel.org/wext-statement
This 300Mb/s vs. 150Mb/s is a marketing bullshit. All of these dongles are 802.11 b/g/n capable and actual efficiency depends only on chip used, in theory 802.11n data rates may go up to 600Mb/s. 8192eu may not be the worst one, but hey, it's 2016, no one should be forced to build kernel driver for a network card.
lima-memtester fails with "Error: ioctl MALI_IOC_MEM_INIT failed: Inappropriate ioctl for device" on my board.