| View previous topic :: View next topic |
| Author |
Message |
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 269
Location: Pennsylvania, USA
|
 Posted: Sat Jun 01, 2024 12:50 am Post subject: |
 |
|
| gord wrote: | | pietinger wrote: | | but be aware they want surely that you bisect it. |
What's the recomended approach for doing that in Gentoo? I see there aren't any gentoo-sources or vanilla-sources package versions between 6.1 and 6.6. Should I just clone the Git repository directly and compile from that? |
That's what I did when I hit a regression. Start with https://wiki.gentoo.org/wiki/Kernel_git-bisect . |
|
| Back to top |
|
 |
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Mon Jun 03, 2024 12:56 am Post subject: |
|
|
Thanks, will do! I'll be away from this machine for a while, but will report back in when I return and am able to spend some time on this. |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Tue Jul 02, 2024 6:53 am Post subject: |
|
|
Hi all, I'm back and have had some more time to investigate this. With some "manual" bisection of the Linux repo history I've determined that the v6.2 tagged commit works as expected while the v6.3-rc1 commit doesn't. I also tried v6.9.7 which also doesn't work (so the issue presumably hasn't been fixed in the past month).
I can start a "proper" git bisect between v6.2 and v6.3-rc1. But before I do I'm curious about the relationship between release candidate tags (e.g. v6.3-rc1) and the v6.2.1+ releases, especially in the context of a non-LTS release which isn't receiving backports? The code at the v6.2 commit is labelled as v6.2.0. So do the subsequent commits between that and v6.3-rc1 map to 6.2.y releases (with y>0), or do they all introduce "new" code/features for v6.3? Or some mix of both? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22624
|
| Posted: Tue Jul 02, 2024 12:15 pm Post subject: |
|
|
v6.3-rc1 contains all commits from v6.2, plus the first part of the v6.3 merge window. v6.2.1 contains all commits from v6.2, plus some selected set of backports that, by policy, should have appeared in a Linus release (including v6.3 release candidates). Barring exceptional circumstances, every commit in v6.2.y (for y > 0) should be a backport of a commit from a later kernel. Sometimes these backports were modified by hand due to patch conflicts, but they should at least logically descend from a later release. There should be no original development in v6.2.y.
The commits in v6.2.y are some mixture of bugfixes and, where believed safe and desirable, feature enablements (such as adding new hardware IDs to lists of devices the kernel can handle, if the v6.2 code was adequate aside from it not knowing it could handle that device successfully). In general, v6.2..v6.2.y (for y > 0) will have far fewer commits than v6.2..v6.3-rc1. For example: | Code: | $ git rev-list v6.2..v6.2.1 | wc
13 13 533
$ git rev-list v6.2..v6.3-rc1 | wc
13565 13565 556165 |
Since you write that v6.2 is good and v6.3-rc1 is bad, we know some commit added in the v6.3 merge window is bad for you. If you are very lucky, you will find that some v6.2.y is also bad because someone backported the bad commit into v6.2.y. This is good for you, since the search space of v6.2..v6.2.y is small, and contains believed safe changes, so the bad commit will be easy to find. If you are not lucky, then the latest v6.2.y is still good, and the bad commit was never backported. At that point, you will need to find it among the thousands of other commits added in v6.3-rc1, some of which may exhibit unrelated bugs that make testing this harder. |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Wed Jul 03, 2024 1:24 am Post subject: |
|
|
| Thanks, that's a really helpful explanation! Unfortunately 6.2.16 works as expected, so I'll have to start bisecting the gap between 6.2 and 6.3-rc1. Each compile takes an hour or more, so this could take a while... |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5094
Location: Bavaria
|
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 269
Location: Pennsylvania, USA
|
| Posted: Thu Jul 04, 2024 10:14 pm Post subject: |
|
|
Or reply to the intel-gfx mailing list. For my regressions I got no activity in the bugzilla, but the mailing lists rocked.
The commit message has a Link: footer just above the start of the patch, that takes you into the message proposing the patch. In the message there is a download mbox link that pulls a plain text version of the message, with email headers.
Hmph. Seems every kernel tribe has a different workflow. In my case, there were detailed replying instruction at the bottom of the list display. I don't see that in intel-gfx. Try replying to both the From: and To: addresses and include the X-Patchwork-Id: and Message-Id: in your message body (unless your email client already references them in its email headers). Describe your issue and include a link to this forum topic. (That way they can blame me if they think you are rude  )
It helps if you can test patches. Plus, you'll get your name in a Tested-by: commit header.
EDIT: Additional reading:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/reporting-regressions.rst?h=v6.9.8
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/reporting-issues.rst?h=v6.9.8
Overwhelming at first sight, but you already did most of the work with your bisection. |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 269
Location: Pennsylvania, USA
|
|
| Back to top |
|
|
|
Installing Gentoo
