On Sat, Oct 08, 2016 at 01:12:43AM -0700, Ashton Holmes wrote: > 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 Great! Can you email all of the people on that patch, and the author, and we can take it from there? 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
