USB and network issues with mainline kernel?

[tkaiser]

Is this https://forum.openmediavault.org/index.php/Thread/24299 a known issue with 5.60?

 

In https://github.com/armbian/testings it's written that 'USB hot plugging' doesn't work which is something I'm fine with. But what does 'networking sometimes doesn't work' means exactly?

 

@Igor since I've seen you submitted the test report. What does that mean wrt networking? Isn't the next branch meant as a 'stable' branch where basic functionality has to work flawlessly? Did networking work prior to 5.60 release?

[Igor]

A network was working OK for some time and at the time of testing but it is possible that one wrong patch finds its way upstream. Obviously ... while USB is a bit problematic. Hotplugging sometimes still doesn't work. If you boot with an attached device, it works.

I need to see if I can recreate this.

[tkaiser]

10 minutes ago, Igor said:

A network was working OK for some time and at the time of testing but it is possible that one wrong patch finds its way upstream

 

Seriously: I don't get this policy. But I think any more discussion is useless and Armbian can just not be considered a stable distribution. Or at least people who are interested in stable operation need to freeze kernel and u-boot updates since otherwise updating the software means ending up with a bricked board or some necessary functionality not working any more (and based on Armbian's origin I consider fully functioning network to be the most basic requirement of all -- but I might be wrong and Armbian in the meantime focuses on display stuff trying to compete with Android)

 

I thought once there was a next branch available for ODROID-C2 this could be considered 'stable' (since there's still the 'dev' branch for development and testing). But it seems I've been wrong and we have no definition of 'stable' if it's possible that updates are provided that destroy functionality that has been working flawlessly before.

 

So by accident 'default' seems to be the only stable branch in Armbian for the simple reason no kernel development happens there.

[Igor]

15 minutes ago, tkaiser said:

Seriously: I don't get this policy.

My C2 is working without any issues: http://ix.io/1nGc

[tkaiser]

2 minutes ago, Igor said:

My C2 is working without any issues: http://ix.io/1nGc

 

So where did your comment 'usb hotpluging and network sometimes doesn't work properly' originates from then?

 

I'm not sure whether you get my point: I want Armbian to be a stable distribution. I do not rely unnecessarily on either Debian or Ubuntu with all their 'outdated as hell' software packages if there wouldn't be that great promise of 'being stable'. If I pull in updates I expect that afterwards my device still works. With the userland this is pretty much the case (upstream Debian or Ubuntu) but wrt kernel/u-boot (the Armbian provided stuff) it seems this is impossible.

 

Why did you write 'network sometimes doesn't work properly' in your commit message and especially why did you allow a kernel update for ODROID-C2 that is then supposed to break basic functionality? As already said: I'm fine with USB hotplug issues since USB devices connected at boot are fine for 'stable' use cases. But if there are network issues to be expected I really don't get it why then such a kernel update will be rolled out and not skipped this time?

 

It's about the process! If an update is to be expected to break functionality then why enrolling it?

 

Is it possible to move from playground mode to stable mode? What's the dev branch for when testing obviously also happens in the next branch?

[Igor]

Just now, tkaiser said:

So where did your comment 'usb hotpluging and network sometimes doesn't work properly' originates from then?

Network troubles were in the past while (non-critical) USB hotplugging is still present. As you can see I manually tested most of the boards and already that was on the edge what I can do "by the way". I am not sure I will do that ever again and certainly not within the next 6 months. It's painful, time wasteful and it goes by completely unnoticed.

 

6 minutes ago, tkaiser said:

It's about the process! If an update is to be expected to break functionality then why enrolling it?

I didn't expect that it will break and my C2 works also when updated to latest nightly. Here https://github.com/armbian/testings everything looks fine -> From the information that I have its safe to update. 

[tkaiser]

26 minutes ago, Igor said:

As you can see I manually tested most of the boards and already that was on the edge what I can do "by the way". I am not sure I will do that ever again and certainly not within the next 6 months. It's painful, time wasteful and it goes by completely unnoticed.

 

So what?

 

Armbian supports too many boards for us to handle. Nothing new.

 

The interesting question still is: how do we provide something that could be called 'stable'? It's simply unacceptable that a simple 'apt upgrade' bricks boards or removes basic functionality (which is not the case here now as I understand -- still wondering why there's a comment reading 'network sometimes doesn't work properly' -- but at the beginning of this year we had a bunch of such totally unnecessary issues caused by untested updates rushed out).

 

If it's not possible to prevent such issues (and clearly separating playground area from stable area) the only alternative is to freeze u-boot/kernel updates by default and add to documentation that users when they want to upgrade u-boot and kernel they're responsible for cloning their installation before -- good luck! -- so they can revert to a working version if something breaks.