[Letux-kernel] as5013 is crying

H. Nikolaus Schaller hns at goldelico.com
Fri Nov 30 21:13:34 CET 2018


Hi,

> Am 30.11.2018 um 20:54 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> when booting the pyra I get this here:
> 
> [    9.174322] BUG: sleeping function called from invalid context at /home/andi/gta04/pyra-kernel/kernel/locking/mutex.c:908
> [    9.180888] twl6040 0-004b: Failed to get supply 'vddvibl': -517
> [    9.191235] in_atomic(): 1, irqs_disabled(): 0, pid: 1318, name: udevd
> [    9.204447] 1 lock held by udevd/1318:
> [    9.206992] twl6040-vibra twl6040-vibra: couldn't get regulators -517
> [    9.208423]  #0: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x7c/0xd0
> [    9.208456] Preemption disabled at:  
> [    9.208468] [<c084e824>] __radix_tree_preload.constprop.7+0x10/0xe8
> [    9.232980] CPU: 1 PID: 1318 Comm: udevd Tainted: G        W         4.20.0-rc4-letux+ #3
> [    9.241575] Hardware name: Generic OMAP5 (Flattened Device Tree)
> [    9.247892] [<c01110e4>] (unwind_backtrace) from [<c010c664>] (show_stack+0x10/0x14)
> [    9.256023] [<c010c664>] (show_stack) from [<c0846f58>] (dump_stack+0x90/0xc4)
> [    9.263605] [<c0846f58>] (dump_stack) from [<c015f9b4>] (___might_sleep+0x248/0x2a4)
> [    9.271739] [<c015f9b4>] (___might_sleep) from [<c085fd1c>] (__mutex_lock+0x34/0x9c0)
> [    9.279951] [<c085fd1c>] (__mutex_lock) from [<c08606c0>] (mutex_lock_nested+0x18/0x20)
> [    9.288366] [<c08606c0>] (mutex_lock_nested) from [<bf1ebe44>] (as5013_probe+0x1ec/0x658 [as5013])
> [    9.297783] [<bf1ebe44>] (as5013_probe [as5013]) from [<c068b398>] (i2c_device_probe+0x224/0x23c)
> [    9.307092] [<c068b398>] (i2c_device_probe) from [<c0575dd0>] (really_probe+0x1f0/0x2c0)
> [    9.315584] [<c0575dd0>] (really_probe) from [<c057612c>] (driver_probe_device+0x140/0x15c)
> [    9.324350] [<c057612c>] (driver_probe_device) from [<c05761dc>] (__driver_attach+0x94/0xd0)
> [    9.333205] [<c05761dc>] (__driver_attach) from [<c05743c0>] (bus_for_each_dev+0x64/0xa0)
> [    9.341785] [<c05743c0>] (bus_for_each_dev) from [<c0575338>] (bus_add_driver+0x170/0x1d8)
> [    9.350463] [<c0575338>] (bus_add_driver) from [<c057710c>] (driver_register+0xb4/0xf8)
> [    9.358861] [<c057710c>] (driver_register) from [<c068c534>] (i2c_register_driver+0x50/0x78)
> [    9.367725] [<c068c534>] (i2c_register_driver) from [<c010317c>] (do_one_initcall+0x170/0x3d8)
> [    9.376761] [<c010317c>] (do_one_initcall) from [<c01d476c>] (do_init_module+0x58/0x1cc)
> [    9.385248] [<c01d476c>] (do_init_module) from [<c01d344c>] (load_module+0x19dc/0x207c)
> [    9.393650] [<c01d344c>] (load_module) from [<c01d3d1c>] (sys_finit_module+0x94/0xb4)
> [    9.401863] [<c01d3d1c>] (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
> [    9.410441] Exception stack(0xecb19fa8 to 0xecb19ff0)
> [    9.415742] 9fa0:                   b6e327d4 00051fa8 00000006 b6e319f8 00000000 b6e3231c
> [    9.424325] 9fc0: b6e327d4 00051fa8 b446c800 0000017b 00020000 00037f78 00050048 000a4fe8
> [    9.432896] 9fe0: bece2ee0 bece2ed0 b6e2bc4b b6f36a42
> 
> I do not understand the mutex there. At one point it is just aquired
> and then immediately released. Can someone enlighten me?

Well, not immediately:

http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/input/misc/as5013.c;h=09bb5e42521ec3dfc6bd30d95f5ba5ad87447825;hb=4dbc4f238ea4668a8be9f013885d4c066367067e#l662

There is code in between which I think scans for the /proc/pandora directory node.
And creates a new one if not found.
Now, there are two as5013 units at different i2c addresses and probing can run in two parallel threads.
So both might find the directory non-existent and create one unless there is a lock.

Later the /proc files are created in pandora/nub%d so they differ for both chips.

At least that is what I read from looking over the code...

About the lock/unlock this is probably here:

http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/input/misc/as5013.c;h=09bb5e42521ec3dfc6bd30d95f5ba5ad87447825;hb=4dbc4f238ea4668a8be9f013885d4c066367067e#l794

This is obviously nonsense and maybe there was code between long time ago when it was used on the Pandora.

Later on it locks some other /proc removal code so that only the second removal succeeds:

http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/input/misc/as5013.c;h=09bb5e42521ec3dfc6bd30d95f5ba5ad87447825;hb=4dbc4f238ea4668a8be9f013885d4c066367067e#l811

Now the question is why it is crying...

The real error seems to be:

> BUG: sleeping function called from invalid context at /home/andi/gta04/pyra-kernel/kernel/locking/mutex.c:908
> in_atomic(): 1, irqs_disabled(): 0, pid: 1318, name: udevd
>  #0: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x7c/0xd0


No idea why this happens... IMHO it is safe to use mutex during probe. Isn't it?

Or does someone trigger udevd which tries to access something which is not yet initialized?

BR,
Nikolaus


More information about the Letux-kernel mailing list