tkaiser

Depending on options at image creation time it can be even a lot lower. We calculate the size with some safety headroom in mind before putting partitions on the image: https://github.com/armbian/build/blob/master/lib/debootstrap-ng.sh#L308-L333

The latter is not sufficient to test for this kind of underpowering and stress-ng is just a lightweight joke. I suggested to you testing with cpuminer (using NEON instructions and pretty good in deadlocking underpowered boards, I personally know just one other tool that is better in this regard: cpuburn -- both tools are at least twice as heavy as stress-ng or other lightweight tests).

Can we read out the 'chip id' (according to this here 0x00000001 for 43430A0 and 0xFFFFFFFE for 43430A1)? There's a lot of work going on around 43430A1 used on RPi 3 (eg. preparing further firmware changes or recently the BroadPwn fix all 'our' AP6212 devices still wait for). Wrt 'all devices'... we support certain boards that exchanged the A0 AP6212 with A1 in between (eg. Banana Pi M2+ or NanoPi Air).

The issue was described in the thread title from the very beginning (Tinkerboard + hangs = underpowering issue) and that's why I suggested numerous times to add a cpuburn run to our firstrun script simply killing all those boards with insufficient powering before all the useless drama starts over and over again. But no, we know that no one is reading documentation, we know that no one is willing to accept the simple fact that hardware might not be sufficient and we allow both our users directly affected and other users trying to help wasting their time over and over again.

Works for me: echo '/srv/dev-disk-by-id-usb-JMicron_USB_to_SATA_bridge_DB00000000013B-0-0-part1/.keep-spinning' >/etc/my-drive echo '* * * * * root [ -f /etc/my-drive ] && read FileToTouch </etc/my-drive && touch "${FileToTouch}" && sync >/dev/null 2>&1' >/etc/cron.d/keep-sda-spinning chmod 600 /etc/cron.d/keep-sda-spinning Edit: Just thought about how to prevent spinning down after 3 min while allowing the disk to spin down after eg. 15 min inactivity? Maybe using any of the available scripts to deal with crappy USB disk enclosures and then partially inverting the logic (using kernel diskstats with a scan interval of 120 seconds, then either doing a smartctl -a -d sat ('-d sat' required with smartmontools versions prior to 6.6) or not. Hmm... getting standby/sleep state would also be challenging since JMS578 wakes the connected disk up when queried with 'hdparm -C')

So disks behind the JMS578 on HC1 are reported to spin down after 3 minutes of inactivity. I've not noticed this before, just booted latest OMV image on HC1 with a 500GB disk. Still not an issue (SMART is not enabled in OMV). On the other hand the disk activity led is constantly blinking which seems wrong to me. If I would come accross this issue with spinning rust then most probably I would either let a cronjob do a 'touch/sync' every 2 minutes or even better install smartmontools, configure smartd and let it run with '-i 179' (querying the disk every 179 seconds and thereby preventing it from spinning down while getting some health data logged or even notifications if the disk shows critical SMART values). Edit: For whatever reasons the 'disk activity led' stopped blinking ~20 minutes after I mounted the fs on the disk, then the disk stopped spinning shortly after That means I can also confirm. And there's something wrong since 'hdparm -C /dev/sda' to check the state of the disk (idle|active|standby|sleeping) wakes up the disk (shouldn't do this) and produces this output: /dev/sda: SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown Anyway: Mounting the disk in OMV and then using this ends up with that keeping the disk spinning root@odroidxu4:~# ps auxww | grep smart root 4149 0.2 0.1 3924 2380 ? Ss 11:17 0:00 /usr/sbin/smartd -n --quit=never --interval=179 Edit 2: Nope, doesn't work either while touch+sync do the job. Kinda annoying Seems like Hardkernel isn't that lucky combining JMicron ICs with JMicron firmware... Edit 3: Since I've another JMS578 lying around I used same HC1 with same HDD this time connected to USB2 port using the ROCK64 SATA cable. Same behaviour though, hdparm -C throws same error and disks spins down after short time. Here 'hdparm -I' output for onboard JMS578 and for external (only difference is 'Advanced power management level': 254 vs. 128)

Or so https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays Edit: sun8i legacy kernel is a 3.4 kernel so we have there high BogoMIPS values, starting with 3.6 on ARM the meaning is something different, now no DVFS so 'next' is a lot slower than 'default' and even if DVFS will work soon those small H3 board with mainline kernel will still be slower compared to before since

Check his log: http://sprunge.us/FJib (it makes no difference where swap that is never used is located on ) I don't know why I'm posting in this thread since I wanted to stay away from shitty boards but anyway... I would recommend this test (while running 'sudo armbianmonitor -m' in another terminal): sudo armbianmonitor -p minerd --benchmark Takes a minute to install cpuminer 2.4.5. If the board locks up within a second after starting minerd it's underpowered, otherwise armbianmonitor -m output might be interesting.

Unfortunately not since I gave up on those brain-dead Allwinner BSP procedures long ago (there's a reason almost no developer wants to deal with this mess where you have to overwrite a few sectors here and exchange a few files there. Also the last time I tried to follow SinoVoip's 'tutorial' how to do this the instructions were wrong as usual since these copy&paste monkeys simply don't care about correctness). You might want to open a thread in their forum, tell everyone that PM support works with R40 just as with A20 years ago (it's confirmed, see above), post this link as a reference in the Banana forum and anyone who has knowledge/nerves over there should be able to help you exchanging the kernel to play with your Port Multiplier. BTW: of course the SinoVoip guys already know that PM support works (they got a Github notification) but as usual instead of providing a tutorial or even prepare the PM capability in a modular way like community did for A20 years ago they prefer to don't give a sh*t. Edit: Meanwhile in Banana land. Unbelievable

When building fresh jessie images the last days I always got somewhere in between: W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-utils/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) Such an image then also reports this as a problem when doing an 'apt update': ... W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-utils/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. root@odroidxu4:~# cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com jessie main jessie-utils jessie-desktop root@odroidxu4:~# I searched for this in the forum and found Zador mentioning he had the problem but deleting cached rootfs solved the problem. Did this right now but compile.sh still complains as above (quoted from most recent run right now). Any ideas? Edit: forgot to provide 'armbianmonitor -u' output from running installation: http://sprunge.us/iXJP

There is no such thing and according to lsusb you also don't use an USB BT dongle.

Yeah, I should've insisted on what was asked in post #2 above (iozone numbers) Anyway, now we're warned and OPi Plus 2 got again a little bit less attractive... but I fear we'll see the switch from KLMAG2GEND-B031 to KLMAG2WEPD-B031 on other Xunlong boards as well. But as already said if we keep use cases in mind then benchmarking the eMMC as we did here is nothing relevant and as long as the eMMC modules on the various boards show nice/high 4K/16K random IOPS they're the way better alternative to slow SD cards since this is what 'OS performance' depends on somewhat. If we keep in mind that most 'average' SD cards show 16K random IOPS values less than 10 (many even just 5 and an awful lot of cards only 2! -- check the numbers) something close to 600 can be considered amazingly fast (9434KB/s / 16KB = 590 IOPS)

Well, on the Banana Pis you get eMMC with sequential write 'performance' as low as 6MB/s, on FriendlyELEC boards with eMMC it's 7.5MB/s, with Xunlong it was 40MB/s a while back (even on the little boards like PC Plus they used KLMAG2GEND-B031) but it seems the insanely rised flash memory costs within this year led them to exchange the eMMC with slower parts now Edit: In fact KLMAG2WEPD-B031 is the type of eMMC the NanoPi also use but since there it's the 8GB variant it's as slow as 7.5MB/s.

Crap, mmc info is missing there (please search for mmc2:0001 here to get the idea how it should look like), seems I've to adjust armhwinfo for latest mainline kernel. At least it's confirmed that you're testing on ext4 (no compression) and it's as expected: the eMMC now used shows dog slow write performance (12.5MB/s max). Xunlong switched to another eMMC variant in the meantime The only good news: random IO is somewhat ok-ish so as soon as you use the eMMC for the OS and attach an USB2 disk (avoiding the crappy GL830 'SATA port') to store data you should be able to get ~37 MB/s now and maybe ~40MB/s in a few weeks (when Armbian provides THS/DVFS for H3 boards running mainline kernel)

Could you please also provide results from cd /home iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 sudo armbianmonitor -u (assuming /home is the eMMC mountpoint?)

Then as already suggested it's now time to check local storage performance. Please change to the mountpoint of the eMMC, execute the iozone call from the 'SD card performance' link above and report back. In the past the eMMC Xunlong used on these boards was able to achieve sequential write speeds of ~40MB/s. Yours seems to be limited to 12-13 MB/s instead (so once filesystem buffers are full fs performance jumps in). There are a lot of other interesting boards available if you look for NAS performance: https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=154980#post154980 https://forum.armbian.com/index.php?/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/ https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/

Yes. Performance should look like this then: https://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=153498#post153498

Funny, I forgot that I generated an OMV image for the Orange Pi Plus / Plus2 already: https://sourceforge.net/projects/openmediavault/files/Other armhf images/

I forgot to mention that exchanging this needs a reboot to have any effect :\ Anyway: the quick check would be a 'sudo cpufreq-set -g performance' and repeating the test. If numbers then are somewhat better one source of the problem were insufficient cpufreq settings (ondemand without tweaks responsible for the H3 all the time clocking with 480MHz instead of 1296 MHz). Then if you installed Samba the usual way you most probably miss some important fixes, just check what the Samba and OMV installation routines here do differently. My recommendation would be to purge Samba, keep /etc/init.d/armhwinfo as it is now, download softy from the link above, execute it and either install OMV (if you're running a Debian Armbian flavour) or Samba from softy. Samba without some tweaks simply sucks on ARM devices.

BTW: 6180195 / 3600 / 24 = 71.5 days until last reboot and 36 times disk disappeared from the bus. It happened every 2nd day on average

No, hardware issue and existing since ages: /var/log/syslog.1:Oct 3 09:00:26 localhost kernel: [6266594.040198] usb 4-1: reset high-speed USB device number 38 using sunxi-ehci /var/log/syslog.2.gz:Oct 2 09:00:27 localhost kernel: [6180195.100167] usb 4-1: reset high-speed USB device number 38 using sunxi-ehci /var/log/syslog.6.gz:Sep 28 09:00:27 localhost kernel: [5834595.040136] usb 4-1: reset high-speed USB device number 35 using sunxi-ehci The kernel enumerates the devices and increases the number after a total device loss (since 'new device'). That's why it today went from 'usb 4-1: reset high-speed USB device number 2' to 'usb 4-1: reset high-speed USB device number 3' (2 --> 3) but as can be seen above prior to the kernel update this also happened all the time since it even incremented the counter up to 38 (so 36 times lost the disk completely since last reboot before). Check cable/contacts, the issue lives there most probably if the disk is externally powered.

Thank you. Just in case please also output from zgrep reset /var/log/syslog* | curl -F 'sprunge=<-' http://sprunge.us I don't think anything is related to the kernel update (since wrt USB support nothing has changed there since ages), this looks more like a hardware problem to me and the first thing I would do is reseating/replacing cables. Also an fsck might be a good idea due to the 'Buffer I/O error on device sda5' occurences. I remember an issue with smartctl and USB resets but that was with an ODROID-XU4 and a JMS561: https://forum.odroid.com/viewtopic.php?f=147&t=27246 -- but IIRC you said you get USB resets also without smartd being active, true?

armbianmonitor -u Edit: And please also output from 'lsusb -t' just in case (armbianmonitor version on current OS images is rather outdated)

Maybe still the best Banana variant to order... but now you might run into this https://forum.armbian.com/index.php?/announcement/1-1-check-power-supply-check-sd-card-and-check-other-people-experiences/ (BPi M1 has for whatever stupid reasons a Micro USB connector for DC-IN, combine this with a powerful Wi-Fi adapter on the USB port and maybe you just run into the next drama). The good news: You can check for undervoltage situations at least if you use Armbian based mainline kernel images since we're the only ones including patches to read out voltage/current with mainline kernel so you can then check for underpowering as explained here: http://linux-sunxi.org/Lamobo_R1#Powering_the_board (you can use the same sysfs nodes and if you choose a wrong cable to power the board it will look like it's graphed here)

If you're somewhat experienced in Terminal please try to exchange contents of etc/init.d/armhwinfo with https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/armhwinfo, then reboot and test again (I would prefer numbers made with 'Helios Lantest' with '10 Gigabit Ethernet' settings since this tool eliminates client-side bottlenecks since running all the tests on the Client from RAM. Of course before/after numbers preferred). And yes, always run some monitoring in parallel, either 'sudo armbianmonitor -m' in another terminal window or as already suggested use RPi-Monitor.