Hi Felipe, On Wed, 8 Apr 2015 11:35:59 -0500 Felipe Balbi <balbi@xxxxxx> wrote: > > On Mon, Apr 06, 2015 at 01:45:22PM -0500, Nishanth Menon wrote: > > On 04/06/2015 10:27 AM, Felipe Balbi wrote: > > > Hi, > > > > > > On Mon, Apr 06, 2015 at 10:17:37AM -0500, Nishanth Menon wrote: > > >> On 04/06/2015 10:01 AM, Mark Brown wrote: > > >>> On Mon, Apr 06, 2015 at 02:58:29PM +0100, Russell King - ARM Linux wrote: > > >>>> On Mon, Apr 06, 2015 at 08:53:36AM -0500, Nishanth Menon wrote: > > >>> > > >>>>>> 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. > > >>> > > >>> Yes, indeed. I hadn't actually opened the links, I might've got round > > >>> to it later on. > > >>> > > >>>> 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. > > >>> > > >>> I can't think of any regulator side changes which might be relevant in > > >>> that period. It's possible that there might be something in the MFD I > > >>> guess. > > >>> > > >> > > >> Ran a few tests since my original email.. > > >> > > >> 6261b06de565baafa590e58a531a1a5522cea0b6 ("regulator: Defer lookup of > > >> supply to regulator_get") was the only patch that was introduced in > > >> the interval. there seems nothing in mfd either. > > >> > > >> I still have the following in my log.. trying to further down. > > > > > > I noticed a similar warning with AM437x SK > > > > > posting intermediate debug results: > > > > I did a bisect on the merge commits to identify which tree the > > regression got introduced, looks like it is the merge from akpm tree - > > I have not yet looked deeper. > > > > b58a6c0b0808 Merge branch 'akpm-current/current' > > ---> FAIL http://paste.ubuntu.org.cn/2540641 > > > > ef31288bdf44 Merge remote-tracking branch 'livepatching/for-next' > > --> OK -> http://paste.ubuntu.org.cn/2540778 > > yeah, this works on my SK too. I bisected it further down to one commit. > > commit 6dfc11e36ee0 is the first bad commit, but looks like that's not > in linux-next anymore. Please give at least the summary line as well when you refer to commits. They get rebase and rewritten which means that their commit SHA1 changes ... That commit is "kernel/time/hrtimer.c: restart_syscall: use freezable blocking call" and, indeed, it was removed from linux-next and Andrew's tree. -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx
Attachment:
pgpIFjFKAhJ7c.pgp
Description: OpenPGP digital signature
