Re: LDP: next-20150402: twl4030 regression?

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]