LDP: next-20150402: twl4030 regression?

LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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.

Master looks clean as well

https://github.com/nmenon/kernel-test-logs/blob/v4.0-rc6/omap2plus_defconfig/ldp.txt

LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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.

Master looks clean as well

https://github.com/nmenon/kernel-test-logs/blob/v4.0-rc6/omap2plus_defconfig/ldp.txt

Re: LDP: next-20150402: twl4030 regression?

[Mark Brown]

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

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 -
at least a description of the problem you're seeing and some attempt at
analysis.  For example say what the test was, and if there's logs paste
the relevant section into the e-mail.  Just randomly pasting a couple of
web links in and saying "there's a problem" isn't helpful.

Please also CC people responsible for relevant drivers and systems.

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

LDP: next-20150402: twl4030 regression?

[Mark Brown]

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 -
at least a description of the problem you're seeing and some attempt at
analysis.  For example say what the test was, and if there's logs paste
the relevant section into the e-mail.  Just randomly pasting a couple of
web links in and saying "there's a problem" isn't helpful.

Please also CC people responsible for relevant drivers and systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150406/cd790810/attachment.sig>

Re: LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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
).

> analysis.  For example say what the test was, and if there's logs paste
> the relevant section into the e-mail.  Just randomly pasting a couple of
> web links in and saying "there's a problem" isn't helpful.

Not sure if folks have already seen this or not - clicking the link
should show the lockdep report straight out of the box.. I am thinking
that is a problem... but I might be subjective here :)

> 
> Please also CC people responsible for relevant drivers and systems.
> 

Only quick change I could see was in regulator core, Will try to dig
more at this later today. I dont see the filesystem mounted either, but
that could be something else.

--
Regards,
Nishanth Menon

LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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
).

> analysis.  For example say what the test was, and if there's logs paste
> the relevant section into the e-mail.  Just randomly pasting a couple of
> web links in and saying "there's a problem" isn't helpful.

Not sure if folks have already seen this or not - clicking the link
should show the lockdep report straight out of the box.. I am thinking
that is a problem... but I might be subjective here :)

> 
> Please also CC people responsible for relevant drivers and systems.
> 

Only quick change I could see was in regulator core, Will try to dig
more at this later today. I dont see the filesystem mounted either, but
that could be something else.

--
Regards,
Nishanth Menon

Re: LDP: next-20150402: twl4030 regression?

[Russell King - ARM Linux]

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.

LDP: next-20150402: twl4030 regression?

[Russell King - ARM Linux]

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.

Re: LDP: next-20150402: twl4030 regression?

[Mark Brown]

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

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.

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

LDP: next-20150402: twl4030 regression?

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150406/12c26bd7/attachment.sig>

Re: LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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.

> [    1.970184] twl 0-0048: power (irq 344) chaining IRQs 347..354
> [    2.007751]
> [    2.009338] =====================================
> [    2.014343] [ BUG: swapper/0/1 still has locks held! ]
> [    2.019744] 4.0.0-rc6-next-20150402-00002-gff1da06adc96 #2 Not tainted
> [    2.026611] -------------------------------------
> [    2.031524] 4 locks held by swapper/0/1:
> [    2.035675]  #0:  (&dev->mutex){......}, at: [<c03d9c1c>] __driver_attach+0x48/0x98 
> [    2.043762]  #1:  (&dev->mutex){......}, at: [<c03d9c2c>] __driver_attach+0x58/0x98 
> [    2.051940]  #2:  (&dev->mutex){......}, at: [<c03d98d8>] device_attach+0x18/0x8c 
> [    2.059875]  #3:  (regulator_list_mutex){+.+.+.}, at: [<c03a239c>] regulator_register+0x14c/0xf64 
> [    2.069274]
> [    2.069274] stack backtrace:
> [    2.073852] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc6-next-20150402-00002-gff1da06adc96 #2 
> [    2.083465] Hardware name: Generic OMAP3 (Flattened Device Tree)
> [    2.089813] [<c0016334>] (unwind_backtrace) from [<c0012878>] (show_stack+0x10/0x14) 
> [    2.097991] [<c0012878>] (show_stack) from [<c05dd5ec>] (dump_stack+0x78/0x94) 
> [    2.105621] [<c05dd5ec>] (dump_stack) from [<c05e3144>] (schedule_hrtimeout_range_clock+0x18c/0x25c) 
> [    2.115234] [<c05e3144>] (schedule_hrtimeout_range_clock) from [<c00a7354>] (usleep_range+0x48/0x50) 
> [    2.124877] [<c00a7354>] (usleep_range) from [<c039fee4>] (_regulator_do_enable+0xa4/0x270) 
> [    2.133605] [<c039fee4>] (_regulator_do_enable) from [<c03a2ce4>] (regulator_register+0xa94/0xf64) 
> [    2.143035] [<c03a2ce4>] (regulator_register) from [<c03a3a90>] (devm_regulator_register+0x38/0x6c) 
> [    2.152587] [<c03a3a90>] (devm_regulator_register) from [<c03a9eac>] (twlreg_probe+0x118/0x29c) 
> [    2.161743] [<c03a9eac>] (twlreg_probe) from [<c03db0ac>] (platform_drv_probe+0x48/0x98) 
> [    2.170257] [<c03db0ac>] (platform_drv_probe) from [<c03d9b18>] (driver_probe_device+0x1b0/0x26c) 
> [    2.179626] [<c03d9b18>] (driver_probe_device) from [<c03d833c>] (bus_for_each_drv+0x5c/0x88) 
> [    2.188598] [<c03d833c>] (bus_for_each_drv) from [<c03d9934>] (device_attach+0x74/0x8c) 
> [    2.197021] [<c03d9934>] (device_attach) from [<c03d9044>] (bus_probe_device+0x88/0xb0) 
> [    2.205444] [<c03d9044>] (bus_probe_device) from [<c03d7564>] (device_add+0x324/0x520)  
> [    2.213745] [<c03d7564>] (device_add) from [<c04c7f64>] (of_platform_device_create_pdata+0x7c/0xb4)  
> [    2.223266] [<c04c7f64>] (of_platform_device_create_pdata) from [<c04c8078>] (of_platform_bus_create+0xdc/0x19
> 0)  
> [    2.233978] [<c04c8078>] (of_platform_bus_create) from [<c04c818c>] (of_platform_populate+0x60/0xa8)  
> [    2.243591] [<c04c818c>] (of_platform_populate) from [<c03fa620>] (twl_probe+0x380/0x5d8)  
> [    2.252197] [<c03fa620>] (twl_probe) from [<c0490bdc>] (i2c_device_probe+0x10c/0x154)  
> [    2.260467] [<c0490bdc>] (i2c_device_probe) from [<c03d9b18>] (driver_probe_device+0x1b0/0x26c)  
> [    2.269622] [<c03d9b18>] (driver_probe_device) from [<c03d9c68>] (__driver_attach+0x94/0x98)  
> [    2.278503] [<c03d9c68>] (__driver_attach) from [<c03d83bc>] (bus_for_each_dev+0x54/0x88)  
> [    2.287109] [<c03d83bc>] (bus_for_each_dev) from [<c03d9240>] (bus_add_driver+0xdc/0x1d4)  
> [    2.295715] [<c03d9240>] (bus_add_driver) from [<c03da43c>] (driver_register+0x78/0xf4)  
> [    2.304107] [<c03da43c>] (driver_register) from [<c0493ebc>] (i2c_register_driver+0x2c/0x78)  
> [    2.312988] [<c0493ebc>] (i2c_register_driver) from [<c0009784>] (do_one_initcall+0x80/0x1d8)  
> [    2.321990] [<c0009784>] (do_one_initcall) from [<c085ce74>] (kernel_init_freeable+0x1f4/0x2cc)  
> [    2.331146] [<c085ce74>] (kernel_init_freeable) from [<c05d8628>] (kernel_init+0x8/0xe4)  
> [    2.339660] [<c05d8628>] (kernel_init) from [<c000f490>] (ret_from_fork+0x14/0x24)  
> [    2.373199] twl4030_gpio twl4030-gpio: gpio (irq 339) chaining IRQs 355..372
> [    2.381103] gpiochip_find_base: found new base at 494
> [    2.386810] gpiochip_add: registered GPIOs 494 to 511 on device: twl4030

-- 
Regards,
Nishanth Menon

LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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.

> [    1.970184] twl 0-0048: power (irq 344) chaining IRQs 347..354
> [    2.007751]
> [    2.009338] =====================================
> [    2.014343] [ BUG: swapper/0/1 still has locks held! ]
> [    2.019744] 4.0.0-rc6-next-20150402-00002-gff1da06adc96 #2 Not tainted
> [    2.026611] -------------------------------------
> [    2.031524] 4 locks held by swapper/0/1:
> [    2.035675]  #0:  (&dev->mutex){......}, at: [<c03d9c1c>] __driver_attach+0x48/0x98 
> [    2.043762]  #1:  (&dev->mutex){......}, at: [<c03d9c2c>] __driver_attach+0x58/0x98 
> [    2.051940]  #2:  (&dev->mutex){......}, at: [<c03d98d8>] device_attach+0x18/0x8c 
> [    2.059875]  #3:  (regulator_list_mutex){+.+.+.}, at: [<c03a239c>] regulator_register+0x14c/0xf64 
> [    2.069274]
> [    2.069274] stack backtrace:
> [    2.073852] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc6-next-20150402-00002-gff1da06adc96 #2 
> [    2.083465] Hardware name: Generic OMAP3 (Flattened Device Tree)
> [    2.089813] [<c0016334>] (unwind_backtrace) from [<c0012878>] (show_stack+0x10/0x14) 
> [    2.097991] [<c0012878>] (show_stack) from [<c05dd5ec>] (dump_stack+0x78/0x94) 
> [    2.105621] [<c05dd5ec>] (dump_stack) from [<c05e3144>] (schedule_hrtimeout_range_clock+0x18c/0x25c) 
> [    2.115234] [<c05e3144>] (schedule_hrtimeout_range_clock) from [<c00a7354>] (usleep_range+0x48/0x50) 
> [    2.124877] [<c00a7354>] (usleep_range) from [<c039fee4>] (_regulator_do_enable+0xa4/0x270) 
> [    2.133605] [<c039fee4>] (_regulator_do_enable) from [<c03a2ce4>] (regulator_register+0xa94/0xf64) 
> [    2.143035] [<c03a2ce4>] (regulator_register) from [<c03a3a90>] (devm_regulator_register+0x38/0x6c) 
> [    2.152587] [<c03a3a90>] (devm_regulator_register) from [<c03a9eac>] (twlreg_probe+0x118/0x29c) 
> [    2.161743] [<c03a9eac>] (twlreg_probe) from [<c03db0ac>] (platform_drv_probe+0x48/0x98) 
> [    2.170257] [<c03db0ac>] (platform_drv_probe) from [<c03d9b18>] (driver_probe_device+0x1b0/0x26c) 
> [    2.179626] [<c03d9b18>] (driver_probe_device) from [<c03d833c>] (bus_for_each_drv+0x5c/0x88) 
> [    2.188598] [<c03d833c>] (bus_for_each_drv) from [<c03d9934>] (device_attach+0x74/0x8c) 
> [    2.197021] [<c03d9934>] (device_attach) from [<c03d9044>] (bus_probe_device+0x88/0xb0) 
> [    2.205444] [<c03d9044>] (bus_probe_device) from [<c03d7564>] (device_add+0x324/0x520)  
> [    2.213745] [<c03d7564>] (device_add) from [<c04c7f64>] (of_platform_device_create_pdata+0x7c/0xb4)  
> [    2.223266] [<c04c7f64>] (of_platform_device_create_pdata) from [<c04c8078>] (of_platform_bus_create+0xdc/0x19
> 0)  
> [    2.233978] [<c04c8078>] (of_platform_bus_create) from [<c04c818c>] (of_platform_populate+0x60/0xa8)  
> [    2.243591] [<c04c818c>] (of_platform_populate) from [<c03fa620>] (twl_probe+0x380/0x5d8)  
> [    2.252197] [<c03fa620>] (twl_probe) from [<c0490bdc>] (i2c_device_probe+0x10c/0x154)  
> [    2.260467] [<c0490bdc>] (i2c_device_probe) from [<c03d9b18>] (driver_probe_device+0x1b0/0x26c)  
> [    2.269622] [<c03d9b18>] (driver_probe_device) from [<c03d9c68>] (__driver_attach+0x94/0x98)  
> [    2.278503] [<c03d9c68>] (__driver_attach) from [<c03d83bc>] (bus_for_each_dev+0x54/0x88)  
> [    2.287109] [<c03d83bc>] (bus_for_each_dev) from [<c03d9240>] (bus_add_driver+0xdc/0x1d4)  
> [    2.295715] [<c03d9240>] (bus_add_driver) from [<c03da43c>] (driver_register+0x78/0xf4)  
> [    2.304107] [<c03da43c>] (driver_register) from [<c0493ebc>] (i2c_register_driver+0x2c/0x78)  
> [    2.312988] [<c0493ebc>] (i2c_register_driver) from [<c0009784>] (do_one_initcall+0x80/0x1d8)  
> [    2.321990] [<c0009784>] (do_one_initcall) from [<c085ce74>] (kernel_init_freeable+0x1f4/0x2cc)  
> [    2.331146] [<c085ce74>] (kernel_init_freeable) from [<c05d8628>] (kernel_init+0x8/0xe4)  
> [    2.339660] [<c05d8628>] (kernel_init) from [<c000f490>] (ret_from_fork+0x14/0x24)  
> [    2.373199] twl4030_gpio twl4030-gpio: gpio (irq 339) chaining IRQs 355..372
> [    2.381103] gpiochip_find_base: found new base at 494
> [    2.386810] gpiochip_add: registered GPIOs 494 to 511 on device: twl4030

-- 
Regards,
Nishanth Menon

Re: LDP: next-20150402: twl4030 regression?

[Felipe Balbi]

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

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

-- 
balbi

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

LDP: next-20150402: twl4030 regression?

[Felipe Balbi]

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

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150406/47f7341e/attachment.sig>

Re: LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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

LDP: next-20150402: twl4030 regression?

[Nishanth Menon]

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

Re: LDP: next-20150402: twl4030 regression?

[Felipe Balbi]

[-- 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 --]

LDP: next-20150402: twl4030 regression?

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150408/4c860763/attachment.sig>

Re: LDP: next-20150402: twl4030 regression?

[Stephen Rothwell]

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

Hi Felipe,

On Wed, 8 Apr 2015 11:35:59 -0500 Felipe Balbi <balbi@ti.com> 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@canb.auug.org.au

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

LDP: next-20150402: twl4030 regression?

[Stephen Rothwell]

Hi Felipe,

On Wed, 8 Apr 2015 11:35:59 -0500 Felipe Balbi <balbi@ti.com> 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 at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150409/53e56ee0/attachment.sig>