Re: Stack dump when try to store uframe_periodic_max
On Mon, Aug 17, 2015 at 12:04:07PM -0400, Alan Stern wrote: On Mon, 17 Aug 2015, Peter Zijlstra wrote: On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: 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. 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. Can it happen this code is called before a corresponding spin_lock_init()? No; the spinlock gets initialized in ehci_init() long before the sysfs file is registered. Alternatively, memory corruption is an option. If something stomped on the lockdep state you can trigger this I suppose. oops, sorry, it is memory corruption. The chipidea driver overrides platform device's drvdata as its private data (struct ci_hdrc *), this data was expected as struct usb_hcd * at store_uframe_periodic_max. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stack dump when try to store uframe_periodic_max
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: r4: r3: [ 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: r5: r4:80cc3188 r3:0001 [ 70.256947] [8006c460] (__lock_acquire) from [8006ec04] (lock_acquire+0x74/0x94) [ 70.264706] r10:bcf73f80 r9:bd7d290c r8:bbd5fe80 r7:0001 r6:804cc2ec r5:60010093 [ 70.272669] r4: [ 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:0004 [ 70.303881] [804cc2a0] (store_uframe_periodic_max) from [803dae98] (dev_attr_store+0x20/0x2c) [ 70.312768] r7: r6:bbd5fe80 r5:bd7d2900 r4:0004 [ 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: r5:0004 r4:bd7d2900 r3:80172cd0 [ 70.340471] [80171e4c] (kernfs_fop_write) from [80103f44] (__vfs_write+0x2c/0xe0) [ 70.348316] r10: 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:0004 r4:bcdad500 [ 70.373029] [80104750] (vfs_write) from [80105064] (SyS_write+0x4c/0xa8) [ 70.380092] r8:80010844 r7:0169d408 r6:0004 r5:bcdad500 r4:bcdad500 [ 70.386941] [80105018] (SyS_write) from [80010660] (ret_fast_syscall+0x0/0x54) [ 70.394525] r7:0004 r6:76f95b48 r5:0169d408 r4:0004 [ 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stack dump when try to store uframe_periodic_max
On Mon, 17 Aug 2015, Peter Zijlstra wrote: On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: 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. 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. Can it happen this code is called before a corresponding spin_lock_init()? No; the spinlock gets initialized in ehci_init() long before the sysfs file is registered. Alternatively, memory corruption is an option. If something stomped on the lockdep state you can trigger this I suppose. Can you suggest any particular debugging printk for Peter C. to try? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stack dump when try to store uframe_periodic_max
On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: 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. 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. Can it happen this code is called before a corresponding spin_lock_init()? Alternatively, memory corruption is an option. If something stomped on the lockdep state you can trigger this I suppose. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Stack dump when try to store uframe_periodic_max
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: r4: r3: [ 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: r5: r4:80cc3188 r3:0001 [ 70.256947] [8006c460] (__lock_acquire) from [8006ec04] (lock_acquire+0x74/0x94) [ 70.264706] r10:bcf73f80 r9:bd7d290c r8:bbd5fe80 r7:0001 r6:804cc2ec r5:60010093 [ 70.272669] r4: [ 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:0004 [ 70.303881] [804cc2a0] (store_uframe_periodic_max) from [803dae98] (dev_attr_store+0x20/0x2c) [ 70.312768] r7: r6:bbd5fe80 r5:bd7d2900 r4:0004 [ 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: r5:0004 r4:bd7d2900 r3:80172cd0 [ 70.340471] [80171e4c] (kernfs_fop_write) from [80103f44] (__vfs_write+0x2c/0xe0) [ 70.348316] r10: 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:0004 r4:bcdad500 [ 70.373029] [80104750] (vfs_write) from [80105064] (SyS_write+0x4c/0xa8) [ 70.380092] r8:80010844 r7:0169d408 r6:0004 r5:bcdad500 r4:bcdad500 [ 70.386941] [80105018] (SyS_write) from [80010660] (ret_fast_syscall+0x0/0x54) [ 70.394525] r7:0004 r6:76f95b48 r5:0169d408 r4:0004 [ 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 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
