https://bugzilla.kernel.org/show_bug.cgi?id=194645 --- Comment #7 from Christian König (deathsimple@xxxxxxxxxxx) --- (In reply to Mateusz Lenik from comment #6) > I did check that it was using the freshly built kernel manually before every > suspend test and I rebuilt x11 drivers every time the revision was changed. Please don't rebuild the x11 drivers! If it's a kernel bug you only need to build and check the kernel. X11 shouldn't be involved here. Or does it work with an old X11 and a new kernel? Could be that it is a new feature which causes the issue and you need both new kernel and new X drivers to trigger the problem. > Can incremental builds (that means without clean/distclean, just building > whatever files have changed) have some effect on bisect outcome? Well in theory that should work fine. But in practice it is possible (but unlikely) that the build system didn't track some dependencies correctly. It's just that in this case you usually get a kernel which don't want to boot at all. So you notice the problem immediately. > The other weird thing is that after few bisections `make kernelrelease` > returned `4.8.0+` even when I wanted to find out what is wrong in commits > between v4.9 and v4.10-r1. Any idea what did I do incorrectly? You did nothing wrong, bisect just drifted into a branch which was merged in 4.10, but originally based on 4.8. That just happens when that branch was under development for a long time before merging (e.g. started of as something 4.8 based). -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
