On Wed, Feb 17, 2016 at 03:20:05PM +0100, Peter Zijlstra wrote: > On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote: > > On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote: > > > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote: > > > > Quoting my original patch; > > > > > > > > "See the Bugzilla link for more details. > > > > > > If its not in the Changelog it doesn't exist. Patches should be self > > > contained and not refer to external sources for critical information. > > > > The exact locking case in CPUfreq drivers causing a splat is described > > in the patch. Details were already included, that's why term "more > > details" was used. > > Barely. What was not described was why you went to tinker with the > hotplug lock instead of sanitizing cpufreq. Nor why your chosen solution > is good. > > > This is not exactly taking us closer to a fix, > > Why you think we can discuss fixes if you've not actually described your > problem is beyond me. Can we please stop the petty-fights while figuring out how to work out a solution here, thanks. And for context we're hitting this on CI in a bunch of our machines, which means no more lockdep checking for us. Which is, at least for me, pretty serious, and why we're throwing complete cpu-anything newbies at that code trying to come up with some solution to unblock our CI efforts for the intel gfx driver. Unfortunately our attempts at just disabling lots of Kconfig symbols proofed futile, so ideas to avoid all that code highly welcome. As soon as CI stops hitting this we'll jump out of your inbox, if you want so. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
