[Letux-kernel] Ethernet interface on Beaglebone Black broken since 5.15.0-rc1-letux+

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 24 16:07:21 CEST 2021


Hi all,

> Am 24.09.2021 um 11:56 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> The result is in any case that v5.14.0 + letux is not a direct ancestor of v5.15-rc1 + letux and bisect finds another one. This does not include any Letux feature branches.
> 
> In theory it would be possible to
> 
> git checkout letux-5.15-rc1
> git rebase letux-5.14
> 
> The result should be a "migration path" which can be bisected.
> 
> But this rebases tenthousands of commits and some need manual conflict resolution. And I have not found a way to automate.

I may have found a trick that at least allows to reduce the search area:

assuming

good: v5.14 / letux-5.14
bad: v5.15-rc1 / letux-5.15-rc1

we do

	git checkout -B temp letux-5.14
	git rev-parse  | while COMMIT ...
	git rev-list --reverse v5.14..letux-5.15-rc1 | while read HASH; do git cherry-pick $HASH || git cherry-pick --abort; done
	git checkout letux-5.15-rc1 -- .
	git commit -m 'unresolved diffs' -a

This first packs all changes from upstream v5.14..v5.15-rc1 on top of letux-5.14.
And then all changes of v5.15-rc1 to letux-5.15-rc1.

It skips what it can not apply and adds that as a single commit in the end.
The bug may be there but this is smaller than the whole diff.

After some hours, the result should be a bisectable sequence from letux-5.14..temp(=letux-5.15-rc1).

Either the problem occurs in between or is in the final commit.

Maybe we find an idea how to split the final commit into small bisectable chunks,
but the key problem is that there is no guarantee that we can compile arbitrary
splits or that they break as we want to analyse.

And, what I am not sure is if git merge done upstream or to create letux-5.15-rc1 are properly picked.

BR,
Nikolaus


More information about the Letux-kernel mailing list