(resubmitting due to non "plain-text" causing virus bounce):
Hey Shuah, after these few days, I FINALLY completed bisecting... much
to my dismay...
It was my first foray into bisecting and it looked simple enough, but
for some reason every subsequent step resulted in a "bad" result.
*****
$ git bisect log
git bisect start
# good: [f0fae702de30331a8ce913cdb87ac0bdf990d85f] Linux 5.1.15
git bisect good f0fae702de30331a8ce913cdb87ac0bdf990d85f
# bad: [d36a8d2fb62c7c9415213bea9cf576d8b1f9071f] Linux 5.2.8
git bisect bad d36a8d2fb62c7c9415213bea9cf576d8b1f9071f
# good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux 5.1
git bisect good e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd
# bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag
'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
# bad: [82efe439599439a5e1e225ce5740e6cfb777a7dd] Merge tag
'devicetree-for-5.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect bad 82efe439599439a5e1e225ce5740e6cfb777a7dd
# bad: [78438ce18f26dbcaa8993bb45d20ffb0cec3bc3e] Merge branch
'stable-fodder' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad 78438ce18f26dbcaa8993bb45d20ffb0cec3bc3e
# bad: [275b103a26e218b3d739e5ab15be6b40303a1428] Merge tag
'edac_for_5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp
git bisect bad 275b103a26e218b3d739e5ab15be6b40303a1428
# bad: [0bc40e549aeea2de20fc571749de9bbfc099fb34] Merge branch
'x86-mm-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 0bc40e549aeea2de20fc571749de9bbfc099fb34
# bad: [007dc78fea62610bf06829e38f1d8c69b6ea5af6] Merge branch
'locking-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 007dc78fea62610bf06829e38f1d8c69b6ea5af6
# bad: [5ba2a4b12f450c5c69099a5c19671c6e59daa435] Merge branch
'core-rcu-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 5ba2a4b12f450c5c69099a5c19671c6e59daa435
# bad: [91df49e187c1a111e423fe0c3aec3472980385e4] Merge LKMM and RCU commits
git bisect bad 91df49e187c1a111e423fe0c3aec3472980385e4
# bad: [add0d37b4f1e77de7d170ece43c8d765572a1eab] rcu: Correct
READ_ONCE()/WRITE_ONCE() for ->rcu_read_unlock_special
git bisect bad add0d37b4f1e77de7d170ece43c8d765572a1eab
# bad: [da8739f23fadf05809c6c37c327367b229467045] rcu: Allow
rcu_nocbs= to specify all CPUs
git bisect bad da8739f23fadf05809c6c37c327367b229467045
# bad: [884157cef0acf05648fe921d80c680afababb428] rcu: Make exit_rcu()
handle non-preempted RCU readers
git bisect bad 884157cef0acf05648fe921d80c680afababb428
# bad: [671a63517cf983ad8eaa324167165cef245ab744] rcu: Avoid
unnecessary softirq when system is idle
git bisect bad 671a63517cf983ad8eaa324167165cef245ab744
# bad: [e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7] rcu: Unconditionally
expedite during suspend/hibernate
git bisect bad e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7
# first bad commit: [e85e6a21b2b5f31148cc3f2e785262b37c3e1ec7] rcu:
Unconditionally expedite during suspend/hibernate
*****
And those were ALL of the steps and I REALLY don't think that rcu
commit is the cause.
My testing went down something like this:
*****
$ git clean -xdf
$ git reset --hard
$ git checkout v5.1.15
$ git bisect start
$ git bisect good
$ git bisect bad v5.2.8
//edit "./drivers/media/usb/au0828/au0828-cards.c", adding my 0x400 tuner.
$ cat /proc/config.gz | gunzip > .config
$ yes '' | make oldconfig
$ make -j4
$ make modules_install
$ cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux-bisect
$ mkinitcpio -k <kernel listed from modules_install command> -g
/boot/initramfs-linux-bisect.img
//reboot into newly compiled kernel (already set in
/boot/loader/entries/bisect.conf)
$ /w_scan-20170107/w_scan -c US //test tuner which results in "...
main:4004: FATAL: ***** NO USEABLE TERRCABLE_ATSC CARD FOUND. *****
...". Same issue with tvheadend and journalctl shows the Tuner is busy
error -19 message.
$ git bisect bad
$ make mrproper //necessary? Took forever to compile all 13 steps cleanly.
//GOTO "cat /proc/config.gz | gunzip > .config" step and repeat 13
times... ugh. About 2-3 hours for each.
*****
I don't know how bisecting does it's magic, but I'd think it'd be
something like this:
v............commits...........v //(from 5.1.15 to 5.2.8)
Good ||||||||||||||||||||||| Bad
| //split the commits
| //split the bottom half if the
previous test failed
| //split the difference again if good,
and repeat.
I'd think a more intelligent way to bisect would be based on a
file/module that is known/thought to produce the error.
In my case, the starting point would be "./drivers/media/usb/au0828/"
All commit changes for any file in that directory given a branch/tag
range would be examined.
If no changes are found in that branch/tag range, then the next step
would be to analyze any commits that are affected by parents/children
(references) of au0828 within that version range, and continually move
up/down the line. (eg. linux/usb.h which is referenced by au0828.h)
This way, the scope is very narrow at the beginning and widens as needed.
I think it's something that could be implemented in the git tool and
the user only needs to provide a starting place. Just a thought.
I can only hope that I incorrectly used bisecting and someone can
point to what I did wrong and provide a better way. (maybe I wouldn't
have to mrproper, so the testing wouldn't take days?)
On Mon, Aug 19, 2019 at 3:49 PM shuah <sh...@kernel.org> wrote:
>
> On 8/16/19 7:15 PM, Nathan Royce wrote:
> Hi Nathan,
>
> Just catching up with this thread. Let me know what you find. Can you
> build your own kernel and see what you can find?
>
> thanks,
> -- Shuah
