Heisath

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

Yes this rebuildability is something we have been thinking/working on for a while. There even is an existing Jira Ticket for it:
https://armbian.atlassian.net/browse/AR-175?atlOrigin=eyJpIjoiN2FhZTgyMTIxZWMxNDA2NmE5NjIxOTEzYTI4YWNiNDAiLCJwIjoiaiJ9
and the original post 
 
As of know this has not been implemented (probably because no one had enough time / interest / motivation to do it). Maybe you can?  
We'd also need to define how many old tags we support and for how long... 
 
 
 
 

Is there also a status page for the status page? Just to make sure, we know what to do, if the status page is not available

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

https://status.uptimerobot.com
 
lol

I assume the original thinking of the authors of fancontrol was, that when the programm crashes/unexpectedly get closed, it does not leave the fans at a low speed and possibly endanger the system. 
The fancontrol does not differentiate between shutdown and exit / kill.
 
And from a system perspective it is much better to have annoying loud fans (but a cool and healthy system) than slowly burning away components while no sound is heard
 
I guess that also answers your second question, if you comment those lines away, the fans wont auto speed up if fancontrol crashes or similar.

You need to assign a fix version. Compare yours https://armbian.atlassian.net/browse/AR-600 with this one from Igor: https://armbian.atlassian.net/browse/AR-630

This has been fixed via a patch to mvebu-current (LK5.10) so should be available via nightly or with the next armbian release : https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/0001-Revert-block-simplify-set_init_blocksize-to-regain-l.patch

It is fixed in LK 5.11 in mainline, but unsure if Armbian will get LK5.11 on mvebu or if we wait until the next LTS kernel version.

This has been fixed via a patch to mvebu-current (LK5.10) so should be available via nightly or with the next armbian release : https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/0001-Revert-block-simplify-set_init_blocksize-to-regain-l.patch

It is fixed in LK 5.11 in mainline, but unsure if Armbian will get LK5.11 on mvebu or if we wait until the next LTS kernel version.

@Mangix probably not, if he hasn't used it for a few months.
 
 
@pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. 
For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one.
 
For LED meaning: https://wiki.kobol.io/helios4/hardware/
For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/

Hello,
 
I tried to use again my Helios4, but when we put the power on, only the LED8 light up.
 
This Helios4 was working great a few month ago (before we receive the Helios64 :-)
 
So we removed all sata cables (and fan, and power cables for hard drives) to made new tests. But still the same...:-(
 
And the processor is hot.
 
So, if someone have a idea to fix it.
 
Thank you.
 
Regard.

@Mangix probably not, if he hasn't used it for a few months.
 
 
@pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. 
For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one.
 
For LED meaning: https://wiki.kobol.io/helios4/hardware/
For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/

Is it just me, or did we have the exact same question a few weeks/month ago already?
 
EDIT: Found it! 
 
 
 

Yes that is old and only limited switch capability given.
 
 
Correct that thread is pretty up-to-date. I have received the boards and confirmed the Power and Serial Mux is working (with minor changes). Currently we are developing the firmware for the sdcard muxer (STM32 based). The hardware of the sdcard mux seems good, I was able to connect a sd card to USB (and read with PC) and also to some SBC and boot it with reasonable fast speeds. 
 
The current step is advancing the firmware so it is possible to select which SD card to mux where via USB or I2C. 
 
You can check the state on the github https://github.com/armbian/mpads

@FredK the PR has been merged.   Maybe @Igor can give a little notice here, once the next bugfix debs are released? 

Looks nice, but do we need another plattform / bugtracker? We already have forum, github issues, github project / teams, jira.  Although nobody seems to use the github project/teams stuff anymore.

Just in case you misunderstood: I do not want to send any PR to OpenWRT.
 
I am only asking you (as you have a reliable way of crashing) to test once without any DFS patches at all. And once with the OpenWRT DFS patches, which I added to AR-526.

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

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