All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: balbi@ti.com
Cc: Mark Brown <broonie@kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: LDP: next-20150402: twl4030 regression?
Date: Mon, 6 Apr 2015 13:45:22 -0500	[thread overview]
Message-ID: <5522D442.9090905@ti.com> (raw)
In-Reply-To: <20150406152750.GE11160@saruman.tx.rr.com>

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

Felipe, could you confirm on your end as well on SK (my fs does not
use systemd unfortunately)?

-- 
Regards,
Nishanth Menon

WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: LDP: next-20150402: twl4030 regression?
Date: Mon, 6 Apr 2015 13:45:22 -0500	[thread overview]
Message-ID: <5522D442.9090905@ti.com> (raw)
In-Reply-To: <20150406152750.GE11160@saruman.tx.rr.com>

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

Felipe, could you confirm on your end as well on SK (my fs does not
use systemd unfortunately)?

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2015-04-06 18:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 13:21 LDP: next-20150402: twl4030 regression? Nishanth Menon
2015-04-06 13:21 ` Nishanth Menon
2015-04-06 13:45 ` Mark Brown
2015-04-06 13:45   ` Mark Brown
2015-04-06 13:53   ` Nishanth Menon
2015-04-06 13:53     ` Nishanth Menon
2015-04-06 13:58     ` Russell King - ARM Linux
2015-04-06 13:58       ` Russell King - ARM Linux
2015-04-06 15:01       ` Mark Brown
2015-04-06 15:01         ` Mark Brown
2015-04-06 15:17         ` Nishanth Menon
2015-04-06 15:17           ` Nishanth Menon
2015-04-06 15:27           ` Felipe Balbi
2015-04-06 15:27             ` Felipe Balbi
2015-04-06 18:45             ` Nishanth Menon [this message]
2015-04-06 18:45               ` Nishanth Menon
2015-04-08 16:35               ` Felipe Balbi
2015-04-08 16:35                 ` Felipe Balbi
2015-04-08 21:46                 ` Stephen Rothwell
2015-04-08 21:46                   ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5522D442.9090905@ti.com \
    --to=nm@ti.com \
    --cc=balbi@ti.com \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.