On Mon, Apr 06, 2015 at 08:53:36AM -0500, Nishanth Menon wrote: > On 04/06/2015 08:45 AM, Mark Brown wrote: > > On Mon, Apr 06, 2015 at 08:21:49AM -0500, Nishanth Menon wrote: > > > >> https://github.com/nmenon/kernel-test-logs/blob/next-20150401/omap2plus_defconfig/ldp.txt > >> looks clean, but > > > >> https://github.com/nmenon/kernel-test-logs/blob/next-20150402/omap2plus_defconfig/ldp.txt#L488 > >> seems to have picked up a regression in the regulator driver. > > > > Please provide actual bug reports if you're trying to report something - > > Apologies, I should have been a little more clear. > > > at least a description of the problem you're seeing and some attempt at > > Test was a simple boot test. There seems to be a lockdep reported at the > very least in the log provided (see > https://github.com/nmenon/kernel-test-logs/blob/next-20150402/omap2plus_defconfig/ldp.txt#L488 > ). I think what Mark is trying to say is to include a fuller description of the problem, and don't expect people to fire up their web browser to get a basic overview of what the problem is. My guess is that the problem _appears_ to be that someone's added a call to debug_check_no_locks_held() into schedule_hrtimeout_range_clock() without considering what this means. What it means is that you can't now use usleep_range() from within any driver probe function - which is absolutely absurd. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
