You are not logged in.
Hello community,
I see that audio latency exceeds a threshold (jack reports xruns) from
arch Linux kernel 6.0.2-arch1onwards in the arch Linux kernel (fetched from the arch archive).
In the mainline Linux the same symptom only appears from version
mainline Linux kernel 6.3onwards (built from linux-git package).
I wrote a log of the versions that I've tested and that lead me to this conclusion. Let me know if I should share the log.
This could either mean that there are two unrelated sources of the problem or the faulty Linux patch from 6.0.2 went into mainline Linux at version 6.3.
I already checked if commits between 6.0.1-arch2 (unaffected) and 6.0.2-arch1 can be found in the mainline Linux commits between 6.2 (unaffected) and 6.3, but I cannot find identical commits.
Before continuing to help finding the issue here by finding the faulty commit, I would like to check if the two faulty versions (mainline and arch) are somehow related (as described above: 6.0.2 patches might have been merged into mainline 6.3).
The reason is that every check of a version currently takes six hours to complete (If the latency threshold is not exceeded within six hours I consider that version unaffected). So finding both commits in arch and mainline takes a lot of time. If there is a relation I could focus on one of the two.
As I said I found no relation using git. Maybe someone here knows about the relation or can show a way to find it.
If there is no relation or if this stays unknown I would like to know some suggestions on how to continue.
Alternatives are:
1. Only find the faulty arch commit and report it
2. Find the arch commit and the mainline commit and report both (a lot of effort!)
3. Just find and report this in mainline
How would you proceed?
Related wiki section: ( Kernel->Debugging_regressions)
Last edited by topasiss (2023-08-28 13:26:54)
Offline
All commits applied to stable must already exist in mainline or be an equivalent fix [1]. You can see the upstream commit it is based on in the commit message of each stable commit [2].
Is the issue still present in the current linux package 6.4.12.arch1-1 and current mainline 6.5-rc7 (6.6 will probably be released within a day)?
I would suggest you bisect between 6.0.1 and 6.0.2 as that will have less steps than bisecting 6.2 to 6.3. I can provide you built bisection kernels if it would help.
You have enabled parallel compilation [3] to reduce build time?
[1] https://docs.kernel.org/process/stable- … rules.html
[2] https://github.com/archlinux/linux/comp … .0.2-arch1
[3] https://wiki.archlinux.org/title/Makepk … ompilation
Offline
All commits applied to stable must already exist in mainline or be an equivalent fix [1].
You can see the upstream commit it is based on in the commit message of each stable commit [2].
I see, thanks. That would mean that there might be two separate problems or causes. One in an arch patch and one in the mainline later. We'll see.
Is the issue still present in the current linux package 6.4.12.arch1-1 and current mainline 6.5-rc7 (6.6 will probably be released within a day)?
Testing takes six hours. I've tested a recent arch and mainline kernel already. These were arch: 6.4.8-arch1 mainline: linux-git-v6.5.rc6.r225.aa9ea98cca3a. They both still had the issue.
I would suggest you bisect between 6.0.1 and 6.0.2 as that will have less steps than bisecting 6.2 to 6.3. I can provide you built bisection kernels if it would help.
You have enabled parallel compilation [3] to reduce build time?
Yes, step by step. Perhaps I can identify a commit in the arch repo. If that problem is fixed I can investigate further causes if the issue persists.
I can build it myself I think (worked with linux-git, too). It took about two hours approximately on four cores in parallel (i5, 3,8GHz, ten years old) with linux-git. Now I'll use the linux PKGBUILD. Should be the same I think.
Anyway, fighting latency is not easy. Maybe I cannot find the cause.
Last edited by topasiss (2023-08-28 07:45:30)
Offline