On Mon, 17 Aug 2015, Peter Chen wrote: > Hi Alan, > > When run "echo 105 > /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max", > if lockdep check is enabled, there is below dump, I am afraid it can't > find how to fix it, the warning shows the key is not persistent. > (see line 757, kernel/locking/lockdep.c). > > > [ 70.190430] INFO: trying to register non-static key. > [ 70.195437] the code is fine but needs lockdep annotation. > [ 70.200939] turning off the locking correctness validator. > [ 70.206455] CPU: 0 PID: 752 Comm: sh Not tainted 4.2.0-rc6-00030-g91b123e-dirty #475 > [ 70.214216] Hardware name: Freescale i.MX6 SoloX (Device Tree) > [ 70.220064] Backtrace: > [ 70.222585] [<800142e4>] (dump_backtrace) from [<800144d8>] (show_stack+0x18/0x1c) > [ 70.230176] r6:80b39960 r5:00000000 r4:00000000 r3:00000000 > [ 70.235965] [<800144c0>] (show_stack) from [<807d2d58>] (dump_stack+0x8c/0xa4) > [ 70.243231] [<807d2ccc>] (dump_stack) from [<8006e184>] (__lock_acquire+0x1d24/0x1ecc) > [ 70.251164] r6:00000000 r5:00000000 r4:80cc3188 r3:00000001 > [ 70.256947] [<8006c460>] (__lock_acquire) from [<8006ec04>] (lock_acquire+0x74/0x94) > [ 70.264706] r10:bcf73f80 r9:bd7d290c r8:bbd5fe80 r7:00000001 r6:804cc2ec r5:60010093 > [ 70.272669] r4:00000000 > [ 70.275254] [<8006eb90>] (lock_acquire) from [<807dc618>] (_raw_spin_lock_irqsave+0x48/0x5c) > [ 70.283707] r7:bdbba010 r6:804cc2ec r5:80010013 r4:bdbba28c > [ 70.289494] [<807dc5d0>] (_raw_spin_lock_irqsave) from [<804cc2ec>] (store_uframe_periodic_max+0x4c/0x12c) > [ 70.299164] r6:bbd5fe80 r5:bdbba28c r4:00000004 > [ 70.303881] [<804cc2a0>] (store_uframe_periodic_max) from [<803dae98>] (dev_attr_store+0x20/0x2c) > [ 70.312768] r7:00000000 r6:bbd5fe80 r5:bd7d2900 r4:00000004 > [ 70.318549] [<803dae78>] (dev_attr_store) from [<80172d24>] (sysfs_kf_write+0x54/0x58) > [ 70.326494] [<80172cd0>] (sysfs_kf_write) from [<80171f10>] (kernfs_fop_write+0xc4/0x1a8) > [ 70.334686] r6:00000000 r5:00000004 r4:bd7d2900 r3:80172cd0 > [ 70.340471] [<80171e4c>] (kernfs_fop_write) from [<80103f44>] (__vfs_write+0x2c/0xe0) > [ 70.348316] r10:00000000 r9:bcf72000 r8:80010844 r7:bcf73f80 r6:0169d408 r5:bcf73f80 > [ 70.356278] r4:bcdad500 > [ 70.358863] [<80103f18>] (__vfs_write) from [<801047e8>] (vfs_write+0x98/0x16c) > [ 70.366187] r8:80010844 r7:bcf73f80 r6:0169d408 r5:00000004 r4:bcdad500 > [ 70.373029] [<80104750>] (vfs_write) from [<80105064>] (SyS_write+0x4c/0xa8) > [ 70.380092] r8:80010844 r7:0169d408 r6:00000004 r5:bcdad500 r4:bcdad500 > [ 70.386941] [<80105018>] (SyS_write) from [<80010660>] (ret_fast_syscall+0x0/0x54) > [ 70.394525] r7:00000004 r6:76f95b48 r5:0169d408 r4:00000004 > [ 70.400307] ci_hdrc ci_hdrc.1: setting max periodic bandwidth to 84% (== 105 usec/uframe) > [ 70.408507] ci_hdrc ci_hdrc.1: max periodic bandwidth set is non-standard I don't understand this either. Maybe Peter Z. can help. This dump is triggered by the spin_lock_irqsave() call in drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That function doesn't appear to be unusual in any way. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
