• Content count

  • Joined

  • Last visited


About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

6740 profile views
  1. Bananapi suddenly powers off

    Sure, fix your underpowering problems. I also hope a moderator has splitted the relevant posts here and merges/creates them into just another new thread over at
  2. My OpiPC2's USB HDD read speed is 1MB/s

    This is what I was looking for: /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 12M For whatever reasons that's not Hi-Speed (480Mbps) but so called 'Full-Speed' (12Mbps). The USB-to-SATA bridge you're using (Norelsys) is crap BTW (advertises itself as being UAS capable but isn't and has most probably other flaws as well). Check dmesg output at the bottom please: [19909.593371] usb 8-1: not running at top speed; connect to a high speed hub (no idea why the kernel tells you to 'connect to a high speed hub' since my personal recommendation with Norelsys SATA briges is to throw them away) BTW: If you solved this problem your next challenge will be shitty performance due to NTFS (using FUSE and being slow as hell while fully occupying at least a single CPU core)
  3. My OpiPC2's USB HDD read speed is 1MB/s

    I give up finally. So much time went into tools to help supporting user problems while users refuse to use them and provide the needed information. The link above asks for the output of 'armbianmonitor -u' (containing most important info at the end of the uploaded stuff eg. 'lsusb -t' output). Same with those useless 'headers' in each and every subforum. They are obviously invisible to users. What an insane mess...
  4. My OpiPC2's USB HDD read speed is 1MB/s
  5. Bananapi suddenly powers off

    Thank you, that looks ok (well, I was asking for a reason: when I started with Bananas few years ago being absolutely clueless and not knowing how badly they are designed with Micro USB as power source I managed to poweroff my Banana Pi simply by connecting my Apple keyboard with optical mouse connected to the keyboard's internal USB hub -- the consumption peak led to a brownout every time). So next step for you is to diagnose what's going on, maybe the 'watch + dmesg' recipe over there helps with this...
  6. SD-card destroyed by power-off ???

    This is about filesystem corruption and on the 1st generation Raspberries (A and B, not including A+/B+ and all the later variants!) there was a nice underpowering <--> SD card failure relationship: (reading through all the comments there is also interesting since you can easily see that a lot of Raspberry Pi users consider SD cards totally unreliable). That being said if you do not properly shutdown an Armbian installation filesystem corruption can occur as well though I never ran into this if not the SD card itself became corrupt (they all do after some time but this is just due to wear out or physical damage -- I just cooked one to death recently). Armbian's rather high commit interval of 10 minutes might add to this behaviour as well as an fsck running at boot if necessary (initrd). But if you have to deal with power losses you should not trust in filesystem self-healing but prepare for the worst (using a read-only rootfs, just search the forum for recipes) Not on any of the boards Armbian supports. The only SBCs I own that really need a FAT partition to boot are Raspberry Pis since there the primary OS that runs on the VideoCore IV can only be loaded from FAT due to the 1st stage bootloader living in the SoC not able to deal with anything else (that's also where the 'use SD-Formatter and format your SD card prior to usage' BS originates from since Raspberry Pis can not deal with ExFAT too while all modern SD cards exceeding a certain capacity ship preformatted with ExFAT. SD-Formatter is only needed with Raspberries Pi, SDXC cards and when the user wants to run NOOBS)
  7. Bananapi suddenly powers off

    So it's time to check the voltage available to your setup. Please repeat the test with the same image without the USB hub connected, then execute 'sudo armbianmonitor -m' in a SSH shell, wait 10 seconds and then connect the hub. Please provide armbianmonitor output here afterwards.
  8. Banana Pi randomly not working

    Those people implemented this already. Just call armbianmonitor without arguments to understand -c (check your SD card for counterfeit/fraud issues) and -v (verify installation -- the latter only available on new images now). BTW: Since you successfully verified that Armbian 'just works' (on another SD card than the one of your broken installation) now you might also understand why Bananian and Raspbian 'just worked'?
  9. How? With one of those 'PSP charger cables' which often have too tiny wires? Anyway, this thread should be moved to
  10. Banana Pi randomly not working

    A minute would've been sufficient if armbianmonitor output would contain both idle and stress situation (yours shows only the latter). This would've allowed to compare input voltages but in your installation powering looks sufficient (still at 5.2V when stress is running). So your instabilities seem not to be related with two of the three major problems that occur with Micro USB powered Bananas. Maybe your installation on the other card is already broken, maybe the SD card there has a problem. Would be interesting to see logs (armbianmonitor -u) from your original installation and also whether you're able to clone the card (on another system using ddrescue for example) and then check it with either F3 or H2testw (if you're running off a counterfeit card with faked capacity your symptoms would also match)
  11. SD card speed

    If you want to focus on sequential performance (which is most probably NOT what you should do), then keep in mind that on H3 boards the sequential maximum is ~23 MB/s. So you're talking about '23/20 or 23/10' anyway and it's pretty easy what to prefer though the numbers above look somewhat bogus anyway. Some background info (and why most probably looking at random IO is way better which needs a test on the device itself):
  12. Banana Pi randomly not working

    Just try it out and report back. Currently you're not even aware of the problem as almost all users (Micro USB being such a shit show) since you talk about an USB cable between your board and disks while it's about the USB cable between your PSU and your board (this is where the voltage drop happens).
  13. Banana Pi randomly not working

    Which might imply that your whole installation on the SD card is already corrupted as a result of countless 'hard reboots'. It's useless to diagnose at this stage and I doubt anyone is interested in diagnosing it since boards with Micro USB for DC-IN are a support nightmare anyway. You can try to repeat your tests with a fresh Armbian install but unless you fix your underpowering problems it won't help. Most easy way to diagnose underpowering problems is to download latest nightly build from here, burn it on a separate SD card, boot the system with the usual stuff connected and then simply run the following in one terminal and few seconds later start 'stress -c 2 -m 1' in another terminal and watch what happens: tk@lime2:~$ sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq PMIC DC-IN 17:24:47: 720MHz 0.11 3% 1% 1% 0% 0% 0% 40.8°C 4.77V 17:24:52: 528MHz 0.10 3% 1% 1% 0% 0% 0% 40.2°C 4.74V 17:24:57: 528MHz 0.09 3% 1% 1% 0% 0% 0% 40.2°C 4.75V 17:25:03: 528MHz 0.08 3% 1% 1% 0% 0% 0% 40.4°C 4.76V^C (we added voltage monitoring to Armbianmonitor recently since boards with Micro USB for DC-IN are such a support nightmare but this will only work on most recent OS images)
  14. Orange Pi Zero Plus / H5 Chip

    Hmm... but "we" (Armbian devs) can not test for instabilities (since sample size way too small) and users will not report 'DRAM reliability' issues but problems that sound exactly like our favourite issues which we can't influence (powering problems and SD card crappiness). Just as a reference (not meant to encourage further discussion but for commit message) 24 devices participating, 5 not working reliably at 672 MHz but only at 648 MHz max. That's more than 20% failure rate and justifies switching to the next lower possible value since performance differences are negligible while affected reliability should be the real concern.
  15. Orange Pi Zero Plus / H5 Chip

    Why are we trying to use 672 or 648 MHz in the first place? Since there's somewhere a value in a 3.10 DT or sys_config.fex that gets ignored by BSP anyway? Hmm...; -- I can only see that 672 is bad, while 576 and 624 are good. But most probably I missed something... I don't want to force any fixes upstream since IMO that's just a waste of time. The submitted numbers there are the result of copy&paste gone wrong and no one cares. We wasted one and a half year ago an insane amount of time to test through these issues and it should be common sense that 672 MHz are not reliable. This testing doesn't happen 'upstream' (the only time it happened the results were easy to interpret: stay away from 672 MHz since it will cause issues on some boards) and submitters prefer 'performance' over reliability.