Edge kernel 7.3.0-rc6

Makes board unstable

 

[ 1173.843180] rockchip-dw-pcie 3c0800000.pcie: PCIe Gen.3 x2 link up
[ 1173.971258] pcieport 0002:20:00.0: Root Port has been reset
[ 1173.971328] nvme nvme0: restart after slot reset
[ 1173.982877] nvme nvme0: D3 entry latency set to 8 seconds
[ 1173.994210] nvme nvme0: 4/0/0 default/read/poll queues
[ 1173.994642] pcieport 0002:20:00.0: AER: device recovery successful
[ 1173.994719] pcieport 0002:20:00.0: Recovering Root Port due to Link Down
[ 1173.994761] nvme nvme0: frozen state error detected, reset controller
[ 1174.028524] phy phy-fe8c0000.phy.7: lane number 0, val 1
[ 1174.343104] rockchip-dw-pcie 3c0800000.pcie: PCIe Gen.3 x2 link up
[ 1174.471131] pcieport 0002:20:00.0: Root Port has been reset
[ 1174.471191] nvme nvme0: restart after slot reset
[ 1174.486326] nvme nvme0: D3 entry latency set to 8 seconds
[ 1174.496045] nvme nvme0: 4/0/0 default/read/poll queues
[ 1174.496250] pcieport 0002:20:00.0: AER: device recovery successful
[ 1174.496284] pcieport 0002:20:00.0: Recovering Root Port due to Link Down
[ 1174.496303] nvme nvme0: frozen state error detected, reset controller

 

Please test rc in bleeding-edge before making it available on edge

Thanks !

Seems it will be fixed with this pr

 

https://github.com/armbian/build/commit/294f074c9da2902b51146ab56ddb36c7236e1f54

 

Until .debs build avoid upgrading

1 hour ago, j0ta said:

Please test rc in bleeding-edge before making it available on edge

 

That is extremely expensive, far beyond what we can afford. On top of work that only buy you a coffee. And I'm not aware of any Linux distribution doing hardware validation at this scale. Perhaps by the end of next year we'll be able to introduce hardware validation at the pull-request level. Until then, we have "just" this small testing setup in place:

 

https://blog.armbian.com/booting-every-board-every-night/

 

And it actually caught this problem.

 

I've already spent an hour investigating it, then making a patch, and more time will go into working with upstream developers to get the fix merged into mainline Linux. Upgrade was broken for cca. two days, and only in nightly builds, which aren't suitable for production use anyway.

 

At the current donation rate, it will take about 33 years for GitHub Sponsors to cover our investment in the existing autotest hardware. And probably another 10–15 years to bring hardware validation closer to the development process. Until then, please don't expect us to provide on-demand hardware testing on rolling test releases.

I understand what you are saying, and I appreciate the work that you guys do here, but since only nightly edge kernels contain the ethernet speed fix for m1 we are kinda forced to use that one

 

I'm not asking for testing it, just move the rc kernels into bleeding-edge until the stable release

 

Thanks once again !

11 minutes ago, j0ta said:

only nightly edge kernels contain the ethernet speed fix for m1

Didn't know that, our tests doesn't show alerts on suboptimal perfomance.
https://docs.armbian.com/status/board-tests/#odroid-m1-01
This is with stable kernel at our tests: eth0 ↑644/↓941 Mbps Annoying but not critical.

 

11 minutes ago, j0ta said:

just move the rc kernels into bleeding-edge until the stable release

 

We can't change operations nor policy just like that. It is stressful and costly for time. Most of processes are automatic and disrupting their regular path is asking for much bigger problems then lower ethernet speed. Our staff and machinery is already operating at extreme edge. 

Idealy for sorting out this problem would be backporting fixes to LTS kernel. RC / edge kernels has different role and I think we are not moving CURRENT (LTS kernel) to 7.x in upcoming release. Its too soon.

Bleeding-edge branch was where 7.1 rc was put first, then moved to edge

 

 

The ethernet fix patch is the following, current kernel gives upload speeds of 10/mbps

 

https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-7.3/board-odroidm1-change-ethernet-TXD-timing-delay-value.patch

 

The following thread describes the issue that various users have with current kernel

 

I'll try with edge kernel instead of current kernel (No nightly build) maybe it's just the current kernel that is doing that speed cut

 

Thanks !

 

 

Edited Thursday at 02:53 PM3 days by j0ta
test edge kernel comment outside nightly

The following thread describes the issue that various users have with current kernel
 

If the issue is so important, why no one dares sending relevant PR as suggested in that thread?

 

51 minutes ago, MaxT said:

If the issue is so important, why no one dares sending relevant PR as suggested in that thread?

 

It was already fixed in 7.2.9 edge nightly, but 7.2 branch is gone due to 7.3 rc 6 edge nightly

which makes the board unstable to use, (yesterday, after .debs build it will be solved, (Thanks Igor for the pr)

 

people who don't know how to upgrade kernel will have that thread issue using current kernel (default)

Edited Thursday at 05:16 PM3 days by j0ta

 
people who don't know how to upgrade kernel will have that thread issue using current kernel (default)

Until someone dares sending PR for Current …