[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a373a71c-f5b6-471b-b7d2-b1f21dc505ca@leemhuis.info>
Date: Sun, 28 Jan 2024 06:28:52 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Bagas Sanjaya <bagasdotme@...il.com>,
Linux kernel regressions list <regressions@...ts.linux.dev>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Jonathan Corbet <corbet@....net>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: More detailed text about bisecting Linux kernel regression --
request for comments and help
On 28.01.24 03:18, Bagas Sanjaya wrote:
> On Wed, Jan 24, 2024 at 01:19:16PM +0100, Thorsten Leemhuis wrote:
>> .. _bisectstart_bissbs:
>>
>> * Start the bisection and tell Git about the versions earlier
>> established as 'good' and 'bad'::
>>
>> cd ~/linux/
>> git bisect start
>> git bisect good v6.0
>> git bisect bad v6.1.5
>
> If stable release tag is supplied instead as "good" version instead (e.g.
> v6.0.1), as in many regression cases, git will ask to test the merge base
> instead, which is corresponding mainline release (in this case v6.0).
That should not happen if people follow the guide, as this is avoided by
an earlier step:
"'"
. _rangecheck_bissbs:
* Determine the kernel versions considered 'good' and 'bad' throughout
this guide:
[...]
* Some function stopped working when updating from 6.0.11 to 6.1.4?
Then for the time being consider 'v6.0' as the last 'good' version and
'v6.1.4' as the 'bad' one. Note, it is at this point an assumption that
6.0 is fine that will be checked later.
"'"
Ciao, Thorsten
Powered by blists - more mailing lists