Re: lockdep issue booting v4.1 upstream kernel with >64 x86_64 CPUs
On 06/27/2015 03:46 AM, Borislav Petkov wrote:
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote:
Yes, tried this successfully both with <64 and >64 CPUs, this does get
rid of the lockdep warning for me.
Thanks, I'll add your Tested-by to the patch.
Just for kicks, can one of you big NUMA owners try running the sigreturn
tests (tools/testing/selftests/x86/sigreturn_{32,64}) on one of these
monsters with that patch applied, preferably on every cpu?
Something like:
for i in `seq 1 64`; do (taskset -c $i ./sigreturn_32 && taskset -c $i
./sigreturn_64) >/dev/null || echo FAIL; done
I don't see why it would fail, but if the percpu conversion was botched,
then these tests are likely to blow up.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
On 06/27/2015 03:46 AM, Borislav Petkov wrote:
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote:
Yes, tried this successfully both with 64 and 64 CPUs, this does get
rid of the lockdep warning for me.
Thanks, I'll add your Tested-by to the patch.
Just for kicks, can one of you big NUMA owners try running the sigreturn
tests (tools/testing/selftests/x86/sigreturn_{32,64}) on one of these
monsters with that patch applied, preferably on every cpu?
Something like:
for i in `seq 1 64`; do (taskset -c $i ./sigreturn_32 taskset -c $i
./sigreturn_64) /dev/null || echo FAIL; done
I don't see why it would fail, but if the percpu conversion was botched,
then these tests are likely to blow up.
--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep issue booting v4.1 upstream kernel with >64 x86_64 CPUs
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote: > Yes, tried this successfully both with <64 and >64 CPUs, this does get > rid of the lockdep warning for me. Thanks, I'll add your Tested-by to the patch. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep issue booting v4.1 upstream kernel with >64 x86_64 CPUs
On Fri, Jun 26, 2015 at 06:38:20PM -0700, Michel Lespinasse wrote: > Hi Peter, > > I am getting a minor issue trying to boot a lockdep enabled x86_64 > kernel with >64 CPUs. > > The kernel boots the first 64 CPUs without issues, but then complains > that lockdep wants to allocate memory while start_secondary -> > init_espfix_ap has IRQs disabled: Does that help: https://lkml.kernel.org/r/1435311202-13248-1-git-send-email-zhugh.f...@cn.fujitsu.com ? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
On Fri, Jun 26, 2015 at 06:38:20PM -0700, Michel Lespinasse wrote: Hi Peter, I am getting a minor issue trying to boot a lockdep enabled x86_64 kernel with 64 CPUs. The kernel boots the first 64 CPUs without issues, but then complains that lockdep wants to allocate memory while start_secondary - init_espfix_ap has IRQs disabled: Does that help: https://lkml.kernel.org/r/1435311202-13248-1-git-send-email-zhugh.f...@cn.fujitsu.com ? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote: Yes, tried this successfully both with 64 and 64 CPUs, this does get rid of the lockdep warning for me. Thanks, I'll add your Tested-by to the patch. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lockdep issue booting v4.1 upstream kernel with >64 x86_64 CPUs
Hi Peter, I am getting a minor issue trying to boot a lockdep enabled x86_64 kernel with >64 CPUs. The kernel boots the first 64 CPUs without issues, but then complains that lockdep wants to allocate memory while start_secondary -> init_espfix_ap has IRQs disabled: [0.310566] x86: Booting SMP configuration: [0.310569] node #0, CPUs:#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 [0.569224] node #1, CPUs: #18 #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31 #32 #33 #34 #35 [0.922841] node #0, CPUs: #36 #37 #38 #39 #40 #41 #42 #43 #44 #45 #46 #47 #48 #49 #50 #51 #52 #53 [1.198048] node #1, CPUs: #54 #55 #56 #57 #58 #59 #60 #61 #62 #63 #64 [1.365553] [ cut here ] [1.370300] WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0xc5/0xd0() [1.379318] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [1.384648] Modules linked in: [1.387851] CPU: 64 PID: 0 Comm: swapper/64 Not tainted 4.1.0-dbg-DEV #1 [1.402368] 81a1da64 881ff137bc48 816eb1cd 8111d921 [1.409705] 881ff137bc98 881ff137bc88 810b9897 0066 [1.417043] 0092 881ffee813b0 00d0 88207380 [1.424379] Call Trace: [1.426799] [] dump_stack+0x4c/0x65 [1.431872] [] ? console_unlock+0x1f1/0x510 [1.437634] [] warn_slowpath_common+0x97/0xe0 [1.443565] [] warn_slowpath_fmt+0x46/0x50 [1.449237] [] lockdep_trace_alloc+0xc5/0xd0 [1.455086] [] __alloc_pages_nodemask+0xad/0xb90 [1.461276] [] ? add_timer_on+0x67/0x290 [1.466779] [] alloc_page_interleave+0x37/0x90 [1.472796] [] alloc_pages_current+0x155/0x170 [1.478814] [] ? __get_free_pages+0x14/0x50 [1.484571] [] __get_free_pages+0x14/0x50 [1.490162] [] init_espfix_ap+0x1b8/0x260 [1.495752] [] start_secondary+0xf9/0x170 [1.501342] ---[ end trace b6700c7f1c6b959e ]--- [1.506350] #65 #66 #67 #68 #69 #70 #71 [1.615186] x86: Booted up 2 nodes, 72 CPUs I think the correct fix may be to change one of the GFP masks in init_espfix_ap(), but I am not 100% sure. Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
Hi Peter, I am getting a minor issue trying to boot a lockdep enabled x86_64 kernel with 64 CPUs. The kernel boots the first 64 CPUs without issues, but then complains that lockdep wants to allocate memory while start_secondary - init_espfix_ap has IRQs disabled: [0.310566] x86: Booting SMP configuration: [0.310569] node #0, CPUs:#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 [0.569224] node #1, CPUs: #18 #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31 #32 #33 #34 #35 [0.922841] node #0, CPUs: #36 #37 #38 #39 #40 #41 #42 #43 #44 #45 #46 #47 #48 #49 #50 #51 #52 #53 [1.198048] node #1, CPUs: #54 #55 #56 #57 #58 #59 #60 #61 #62 #63 #64 [1.365553] [ cut here ] [1.370300] WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0xc5/0xd0() [1.379318] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [1.384648] Modules linked in: [1.387851] CPU: 64 PID: 0 Comm: swapper/64 Not tainted 4.1.0-dbg-DEV #1 [1.402368] 81a1da64 881ff137bc48 816eb1cd 8111d921 [1.409705] 881ff137bc98 881ff137bc88 810b9897 0066 [1.417043] 0092 881ffee813b0 00d0 88207380 [1.424379] Call Trace: [1.426799] [816eb1cd] dump_stack+0x4c/0x65 [1.431872] [8111d921] ? console_unlock+0x1f1/0x510 [1.437634] [810b9897] warn_slowpath_common+0x97/0xe0 [1.443565] [810b9996] warn_slowpath_fmt+0x46/0x50 [1.449237] [81113e85] lockdep_trace_alloc+0xc5/0xd0 [1.455086] [811c97dd] __alloc_pages_nodemask+0xad/0xb90 [1.461276] [811317d7] ? add_timer_on+0x67/0x290 [1.466779] [81214747] alloc_page_interleave+0x37/0x90 [1.472796] [81215a65] alloc_pages_current+0x155/0x170 [1.478814] [811c4284] ? __get_free_pages+0x14/0x50 [1.484571] [811c4284] __get_free_pages+0x14/0x50 [1.490162] [8106adc8] init_espfix_ap+0x1b8/0x260 [1.495752] [8109a329] start_secondary+0xf9/0x170 [1.501342] ---[ end trace b6700c7f1c6b959e ]--- [1.506350] #65 #66 #67 #68 #69 #70 #71 [1.615186] x86: Booted up 2 nodes, 72 CPUs I think the correct fix may be to change one of the GFP masks in init_espfix_ap(), but I am not 100% sure. Thanks, -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
