On Tue, Oct 4, 2016 at 11:46 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 04, 2016 at 11:07:20PM -0700, Ashton Holmes wrote:
>> On Tue, Oct 4, 2016 at 10:18 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote:
>> >> On Tue, Oct 4, 2016 at 12:11 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> >> >> Also my knowledge of git isn't that extensive and I got the source
>> >> >> from the download on the site not from the git repo so it tells me
>> >> >> there's no .git file but if I can figure out how to run that I'll give
>> >> >> it a go.
>> >> >
>> >> > You can pull Linus's tree from git.kernel.org by doing:
>> >> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> >> >
>> >> > and using your .config in that tree.
>> >> >
>> >> > There is lots of documentation of how to use 'git bisect' but if you
>> >> > have any questions, please let us know.
>> >>
>> >> Alright this is the output of git bisect
>> >> e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit
>> >
>> > That's a great start, but that's the first bad one, you need to now use
>> > 'git bisect bad' and it will keep going and narrow it down to the commit
>> > that causes the problem itself.
>>
>> All the tutorials I saw ended when it got to the first bad commit. I
>> went through and compiled 13 different kernels or so so wouldn't that
>> be the commit that introduced the issue or am I missing something?
>
> No, that's one "leaf" of the tree that does not work (it's a merge
> commit so maybe something in that merge caused the issue). You need to
> keep going and find the real actual commit that caused the problem. You
> will probably run into a few 'good' and 'bad' commits from here on and
> eventually git bisect will spit out a "this is the bad commit" message.
When I re-ran 'git bisect bad' it just repeated the message saying
what the first bad commit was so I went back and re-did the process
from the start. I might have marked a bad commit as good because I
didn't wait long enough to see if it would act up. This time I made
sure to run the system for at least 20-30 minutes before marking it as
good and I got a different bad commit.
a683f390b93f4d1292f849fc48d28e322046120f is the first bad commit
commit a683f390b93f4d1292f849fc48d28e322046120f
Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Date: Mon Jul 4 09:50:36 2016 +0000
timers: Forward the wheel clock whenever possible
The wheel clock is stale when a CPU goes into a long idle sleep.
This has the
side effect that timers which are queued end up in the outer wheel levels.
That results in coarser granularity.
To solve this, we keep track of the idle state and forward the wheel clock
whenever possible.
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Cc: Chris Mason <clm@xxxxxx>
Cc: Eric Dumazet <edumazet@xxxxxxxxxx>
Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>
Cc: George Spelvin <linux@xxxxxxxxxxxxxxxxxxx>
Cc: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
Cc: Len Brown <lenb@xxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxx>
Cc: rt@xxxxxxxxxxxxx
Link: http://lkml.kernel.org/r/20160704094342.512039360@xxxxxxxxxxxxx
Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
:040000 040000 98b12abd4d76e339571150226bdad40fd7a23cf2
3bc24f6e943678c248c35c77f3d2856b9b93173d M kernel
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
