Heisath

  • Content Count

    131
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Heisath got a reaction from TRS-80 in ClearfogPro: Difference in switch behaviour between LK4.19 and LK5.8   
    So I figured it out (and wasted 5 hours or so  ) ...
     
    Support for bridge flags for the mv88e6xxx chips was introduced here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/dsa/mv88e6xxx?h=v5.1&id=4f85901f0063e6f435125f8eb54d12e3108ab064
    One of these flags is flooding. Which seems to be enabled by default, and leads to incoming packets on port A to be replayed on all other ports. This naturally lowers the receive speed on port A to the minimum transmit speed of all other ports.
     
    Easy way to fix this is to issue 'bridge link set dev lan4 flood off' for all the lan ports on the clearfog.
    I confirmed this also works on Lk5.8
     
    Does it make sense to add a family tweak which does this for all lan ports? Or is this possible via device tree?

    EDIT: Nevermind, this is not an issue with the dsa but with the default settings of a linux bridge. Let's not touch it, because not everyone will put the lan ports on the clearfog in a bridge. If they do, they hopefully stumble upon this and check the man page: https://www.man7.org/linux/man-pages/man8/bridge.8.html
  2. Like
    Heisath got a reaction from Technicavolous in ClearfogPro: Difference in switch behaviour between LK4.19 and LK5.8   
    Armbianmonitor: http://ix.io/2EIw Hello,
     
    I have discovered interesting behaviour of the clearfogpro switching between lk4.19 and 5.8 and would like to know if others are able to reproduce. And maybe have ideas on how to fix.
     
    Steps to reproduce: 
    - have a clearfogpro
    - get the current armbian image https://archive.armbian.com/clearfogpro/archive/  20.08
    - 'apt update && apt full-upgrade' 
    - set the lan1-6 interfaces to bridging (example via following /etc/network/interfaces : https://pastebin.com/dpXEBe6g )
    - reboot
    - plug into your network should be GBit (on lan1-5). Verify you get ip, and can reach other devices.
    - run iperf3 between clearfogpro and other gbit device in your network. Should yield about 900MBit/s
    Now the interesting part:
    - attach another device to the switch
    - see how both status leds blink when transfering data via iperf3 ?     The bridge seems to run as a hub and not a switch.
    - now plug a 100mbit/s device into the bridge.
    - test speed to a gbit device with iperf (both directions): one direction will only yield about 100mbit/s. 
    - while iperf3 is running to the gbit device, unplug and replug the 100mbit/s device on the switch, you should see the rate jump between 100 and 1000.....
     
    NOTICE: This only happens in the direction where the clearfogpro is receiving data. Send speed is still at 1gbit/s.
     
    Now use armbian-config and switch to LK4.19, reproduce steps from above. You should only see one activity led blinking and the switch functioning correctly at 1gbit/s even with a 100mbit/s device connected. 
     
    So this leads me to think there's either some difference in the handling of the clearfogpro switch chip (between LK4 and 5) or some difference in bridge package. 
     
    It would be great if someone could confirm so I am sure, it is not a problem with my setup.
     
    root@clearfogpro:~# iperf3 -c 192.168.42.3 -t 100 -R Connecting to host 192.168.42.3, port 5201 Reverse mode, remote host 192.168.42.3 is sending [ 5] local 192.168.42.106 port 33648 connected to 192.168.42.3 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.3 MBytes 94.3 Mbits/sec # 100mbit/s device plugged into the switch [ 5] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 4.00-5.00 sec 26.7 MBytes 224 Mbits/sec # 100mbit/s device removed [ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec [ 5] 6.00-7.00 sec 105 MBytes 878 Mbits/sec [ 5] 7.00-8.00 sec 107 MBytes 893 Mbits/sec ^C[ 5] 8.00-8.61 sec 63.9 MBytes 885 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-8.61 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-8.61 sec 454 MBytes 443 Mbits/sec receiver  
  3. Like
    Heisath got a reaction from TRS-80 in ClearfogPro: Difference in switch behaviour between LK4.19 and LK5.8   
    Armbianmonitor: http://ix.io/2EIw Hello,
     
    I have discovered interesting behaviour of the clearfogpro switching between lk4.19 and 5.8 and would like to know if others are able to reproduce. And maybe have ideas on how to fix.
     
    Steps to reproduce: 
    - have a clearfogpro
    - get the current armbian image https://archive.armbian.com/clearfogpro/archive/  20.08
    - 'apt update && apt full-upgrade' 
    - set the lan1-6 interfaces to bridging (example via following /etc/network/interfaces : https://pastebin.com/dpXEBe6g )
    - reboot
    - plug into your network should be GBit (on lan1-5). Verify you get ip, and can reach other devices.
    - run iperf3 between clearfogpro and other gbit device in your network. Should yield about 900MBit/s
    Now the interesting part:
    - attach another device to the switch
    - see how both status leds blink when transfering data via iperf3 ?     The bridge seems to run as a hub and not a switch.
    - now plug a 100mbit/s device into the bridge.
    - test speed to a gbit device with iperf (both directions): one direction will only yield about 100mbit/s. 
    - while iperf3 is running to the gbit device, unplug and replug the 100mbit/s device on the switch, you should see the rate jump between 100 and 1000.....
     
    NOTICE: This only happens in the direction where the clearfogpro is receiving data. Send speed is still at 1gbit/s.
     
    Now use armbian-config and switch to LK4.19, reproduce steps from above. You should only see one activity led blinking and the switch functioning correctly at 1gbit/s even with a 100mbit/s device connected. 
     
    So this leads me to think there's either some difference in the handling of the clearfogpro switch chip (between LK4 and 5) or some difference in bridge package. 
     
    It would be great if someone could confirm so I am sure, it is not a problem with my setup.
     
    root@clearfogpro:~# iperf3 -c 192.168.42.3 -t 100 -R Connecting to host 192.168.42.3, port 5201 Reverse mode, remote host 192.168.42.3 is sending [ 5] local 192.168.42.106 port 33648 connected to 192.168.42.3 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.3 MBytes 94.3 Mbits/sec # 100mbit/s device plugged into the switch [ 5] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 4.00-5.00 sec 26.7 MBytes 224 Mbits/sec # 100mbit/s device removed [ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec [ 5] 6.00-7.00 sec 105 MBytes 878 Mbits/sec [ 5] 7.00-8.00 sec 107 MBytes 893 Mbits/sec ^C[ 5] 8.00-8.61 sec 63.9 MBytes 885 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-8.61 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-8.61 sec 454 MBytes 443 Mbits/sec receiver  
  4. Like
    Heisath got a reaction from lanefu in Armbian v20.11 (Tamandua) Planning Thread   
    I could imagine this weekends saturday night (saturday night in UTC so afternoon for Americans). Would try to get 5.9 for mvebu. 
     
    Not sure if it is worth it to try squeezing all boards in. Depends on ppl. participating w/ testing.
  5. Like
    Heisath got a reaction from gprovost in Helios4 Support   
    @FredK, the LED problem has been fixed in AR-491 [https://github.com/armbian/build/pull/2283]. They will work again with the next bugfix release and 20.11. Thanks for reporting the issue.
  6. Like
    Heisath got a reaction from gprovost in Helios4 Support   
    Hi FredK,
     
    The contradicting armbian version numbers are thing open to discussion. Basically armbian uses many packages and not all of them get updated everytime -> different version number exist. This is synced at every major release.
     
    The fact alone that the linux kernel 5.8 was released with 20.08.xx was a mistake on armbian side. Sorry for the problems we caused. If you can live with the LEDs not working a fix will be available at the latest for the 20.11 release (end of November).
    If you need the LEDs working now you can switch to kernel version 5.4.xx (via armbian-config, pick it by the kernel version on the right. Not the armbian version) there everything should work. ( I tested and can confirm the bug is not yet present in LK5.4.69).
     
    As said the release of 5.8 on 20.08.xx was a mistake. Sorry.
     
    Heisath
  7. Like
    Heisath reacted to Werner in Armbian v20.11 (Tamandua) Planning Thread   
    Release Candidate Code Freeze Date: 2020-10-18 
    Release Date: 2020-11-XX 
    Release Candidate Branch Link: TBD
    Release Changelog: TBD
    Release Coordinator: TBD
    Testing Tracking Sheet: TBD (google sheets)
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. Once the release is complete, this thread should be locked and unpinned.
    ---
     
    Our next release date is coming and perhaps its time to discuss what to push into 20.11, what not, resolve open questions and distract from most used keyword for past few weeks.
     
     
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000@ebin-dev @Heisath@chwe@ning@lanefu@gprovost@aprayoga@5kft
    @JMCC@karabek@Igor@martinayotte@tkaiser@selfbg@Siraj@jock@going ... (please mention whoever is missed)

    Meeting on IRC in Saturday, October 3rd, at 2 pm GMT is being prepared - this is reasonable good timing for US / EU folks.
     
    Agenda:
     
    check meeting attendees (if nick is not self explanatory, add your forum/Github handle. Just say hi or something) present tasks, bugs or project you are working on (open discussion if there will not be much people, otherwise meeting officer call people out). Jira should be open in not already. cycle Jira backlog: discuss task / bug (one at a time) assign to person / release / tag re-prioritise cycle open issues and PR on build engine board status update on download pages and build engine (wip, supported, eol) choosing upcoming release officer (so far it was Igor and Lane) misc / open discussion
    Tips:
    when you got a voice, be concise (1-2 min) and make it clear when you stop. ("No more, I'm done") channel is recorded so a summary and adjustments to Jira can made afterwards, ideally along with the meeting Meeting location is IRC channel #armbian on Freenode. (previous session as an example)  
    Ideally it would be that prior to this meeting we all update tasks/project statuses in Jira - who still does not have access shall PM to @lanefu or @Igor - reviewing, prioritising and releasing goes faster this way.
  8. Like
    Heisath got a reaction from Userlab in Helios64 Annoucement   
    @Userlab If you need to get bigger M.2 cards in there I can suggest using an adapter with extension cable like this:
    https://www.amazon.com/Sintech-M-Key-Extention-Cable-20CMS/dp/B07DZCCGJN/
     
    You can break the device side to any length you need it. And attach larger and wider cards at the other end.
  9. Like
    Heisath got a reaction from wolf7250 in Anyone managed to successfully install OMV5 on Helios4?   
    Also you can (as always) download the current versions directly from armbian.
     
    https://www.armbian.com/helios4/
     
    https://dl.armbian.com/helios4/
  10. Like
    Heisath got a reaction from egg in Espressonbin 2.5Gbps, anyone?   
    The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github.
     
    The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram
    As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.
  11. Like
    Heisath got a reaction from Tido in Armbian v20.08 (Caple) Planning Thread   
    Will need to try this. And talk with @gprovost about it, regarding their time for helios4.
     
    Lets discuss this in its own thread, as this is not coupled with 20.08 release. @Hijax and I are still testing / discussing this. Current plan is to order a few board (4) (assembled) from JLCPCB just for us to test. 
  12. Like
    Heisath got a reaction from lanefu in Espressonbin 2.5Gbps, anyone?   
    The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github.
     
    The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram
    As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.
  13. Like
    Heisath got a reaction from Tido in Boot time - Anything similar to "Boot without waiting for network connection"?   
    Anyway, next steps to save time are:
    - completely remove NetworkManager (you need to do your network config the classic way then). 
    - remove armbian zram and ramlog (which can be done via apt remove or just disable the services) 
    - make sure your device does not run a fsck on every boot 
    - remove u-boot 'prompt timeout' (the time the bootloader waits for user input before booting the system, I guess thats 3s default on armbian) 
     
    Btw. no guarantee that your system works perfectly after above steps - there's a reason for every service running. 
     
     
  14. Like
    Heisath reacted to guidol in Date synchronization   
    All these messages show us, that you network isnt working or isnt working correct.
     
    How did you configure your network? Network-Manager? /etc/network/interfaces? armbian-config?
     
    Can you ping 8.8.8.8?
    Can you ping armbian.com?
    What says ifconfig for eth0 or wlan0?
    whats the IP of your gateway/DNS?
    what is the content of /etc/resolv.conf (when not using network-manager)
     
  15. Like
    Heisath got a reaction from lanefu in Espressobin - Only 1 GB RAM detected on a 2 GB board   
    If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build
    We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).
     
     
  16. Like
    Heisath got a reaction from Werner in Need your help - what else beside Etcher   
    I meant create an issue for displaying a general warning before writing. Like "WARNING: This will erase all existing data on drive X".
     
    The detection can probably not be made entirely perfect & foolproof
     
  17. Like
    Heisath got a reaction from Tido in Need your help - what else beside Etcher   
    Yeah it seems to protect only your system drive in Windows.
    A general warning before writing would also be nice. Maybe someone add an issue on gitlab?
  18. Like
    Heisath got a reaction from gounthar in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    Yeah that might work.
     
    Keep in mind though that this module will still output 3.3V if the input is lower than 5V. Checking the datasheet http://www.advanced-monolithic.com/pdf/ds1117.pdf it seems like this regulator has a dropout voltage of about 1.2V. So 4.5V input would still allow this module to output 3.3V signaling to your SBC that everything is OK while at 4.5V input to your SBC it will probably fail.
     
    This is obviously not ideal!
     
    EDIT: Easiest way to do it would be to instead of the converter just use a potentiometer (10k or something like that). Connect the ends to 5V and GND, and adjust it until the slider is at about 3V (measure with multimeter). Then attach the slider pin to some GPIO and check GPIO state. Keep turning down the voltage just until the GPIO reads as LOW. Turn back up a bit until it is HIGH. Then once the input drops below 5V the poti output will also drop slightly causing the GPIO to go LOW -> use this as shutdown. 
     
    This is also not perfect, beware: never turn the poti to high (watch out for anything >3.3V on your GPIO) also you might have to experiment 'till you have a good setting. Minor power fluctuations should not cause a shutdown. 
  19. Like
    Heisath reacted to Werner in Rename Supporter to Donator   
    38 views and one like. So at the moment the majority of people is for this change
  20. Like
    Heisath got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    Is this not easily possible by using LIBTAG parameter? Or does it not work anymore? 
     
    Apart from the final release confusion  I'd also totally agree with JMCC this release process was way better than older ones. 
  21. Like
    Heisath reacted to lanefu in Armbian 20.02 (Chiru) Release Thread   
    Yes. We definitely need to figure out when to cut a release, when to increment, what a RC version number means, etc.    -rc1 was really a rolling release branch this time.  AR-176
     
     
    I really see that as 2 parts.  
    * Make building alternate armbian build branches easier.
    * Make upstream dependencies consistent.
     
    Both are important, I think the first is a higher priority.    AR-176
     
     
    I partially agree with this.   All features in an RC should exist in master--first.   Bug fixes no.  If a bug fix obviously will improve master, then yes it can be cherry-picked,  But the primary purpose of bugfix is to assure the stability of the release.   Simple Example.. we add a patch to a release on 5.4 kernel...  master has moves to 5.5... may not make sense.

    In practice---during this release we ended up cherry-picking most fixes from master and into the RC branch.
  22. Like
    Heisath got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things? 
     
  23. Like
    Heisath got a reaction from guidol in Armbian 20.02 (Chiru) Release Thread   
    Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things? 
     
  24. Like
    Heisath reacted to Werner in Rename Supporter to Donator   
    Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
     
    Tell me what you think,
  25. Like
    Heisath got a reaction from gounthar in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    You could just add some larger capacitor in parallel to the power bank. If chosen right it should surpress the voltage spike and buffer enough so it does not drop. Might even use more than one to get a better frequency response. Or put a 5.2 volt zener / tvs diode across the board to protect it from the spike. 
     
    I can edit this with some wiring later if needed. 
     
    EDIT: Some wiring idea:
     

     
    Use some resistor voltage divider on the powerbank input (eg. 10k to 10k which gives you 0.5) to get some measurement to your sbc. With the given voltages this would be: 5V in -> 5V * (10k / (10k + 10k)) = 5V * 0.5 = 2.5V .
    If you feed this to some GPIO you can either use some analog pin to measure it directly (and initiate shutdown if it goes to low) or you can hook it up to some digital one if you only want to know wether it is high or low. Might need to change the resistor ratio then. Do not exceed your max gpio voltage!
     
    On the Powerbank output add either D1 or D2  (zener or transient voltage surpressor diodes) rated for slightly above 5V. These will get rid of nasty voltage spikes for you. Additionally use some small capacitor (to remove high frequency ripple) and some larger one in parallel (to reduce low frequency ripple / voltage drops) to buffer over the voltage drop when powerbank is switching on / off.
     
     
     
    Cheers, 
    count-doku