Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755304AbZJZI2f (ORCPT ); Mon, 26 Oct 2009 04:28:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755292AbZJZI2f (ORCPT ); Mon, 26 Oct 2009 04:28:35 -0400 Received: from aa001msb.fastweb.it ([85.18.95.80]:55420 "EHLO aa001msb.fastweb.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755282AbZJZI2e (ORCPT ); Mon, 26 Oct 2009 04:28:34 -0400 Message-ID: <4AE55D83.7080608@evidence.eu.com> Date: Mon, 26 Oct 2009 09:27:47 +0100 From: Claudio Scordino User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: Catalin Marinas , rmk+kernel@arm.linux.org.uk, linux-arm-kernel@lists.arm.linux.org.uk, akpm@linux-foundation.org Subject: [PATCH][RE-SUBMIT] Default setting of the ARM_UNWIND option References: <4AD73DA4.4050006@evidence.eu.com> <1255620333.10164.77.camel@pc1117.cambridge.arm.com> In-Reply-To: <1255620333.10164.77.camel@pc1117.cambridge.arm.com> Content-Type: multipart/mixed; boundary="------------090103040504000907090608" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3122 Lines: 100 This is a multi-part message in MIME format. --------------090103040504000907090608 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi all, I didn't get any comment on this patch, so I try to re-submit. My ARM board hanged at the initial "Calibrating delay loop" message. After some inspection, I found out the problem to be with commit adf8b37bafc1495393201a2ae4235846371870d0. This commit introduces stack unwinding for ARM, and set it enabled by default. However, it seems to not work with buggy or not-EABI compilers. My suggestion is to keep the feature (which is fine) but change the default setting of the option (see the attached patch). Having this option enabled by default, in fact, means that the kernel does not boot if the user has a wrong compiler. If so, inspecting the reason of the hang may require too much time (especially for people not familiar with this option). Consider that people may not know that their problem is related to the ARM_UNWIND option. Therefore, they may waste time bisecting just to understand where their problem really is. If we disable this option by default, users who know the real meaning of the option will still be able of setting it to the proper value. Any comment ? Many thanks, Claudio --------------090103040504000907090608 Content-Type: text/x-patch; name="0001-Disable-stack-unwinding-support-by-default-since-it.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="0001-Disable-stack-unwinding-support-by-default-since-it.pat"; filename*1="ch" From: Claudio Scordino Date: Mon, 19 Oct 2009 11:59:16 +0200 Subject: [PATCH 1/1] Disable stack unwinding support by default, since it does not work on some buggy or not-EABI compilers. Disable stack unwinding support by default, since it does not work on some buggy or not-EABI compilers. Signed-off-by: Claudio Scordino --- arch/arm/Kconfig.debug | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 1a6f70e..925e3fd 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -19,13 +19,13 @@ config FRAME_POINTER config ARM_UNWIND bool "Enable stack unwinding support" depends on AEABI && EXPERIMENTAL - default y + default n help This option enables stack unwinding support in the kernel using the information automatically generated by the compiler. The resulting kernel image is slightly bigger but the performance is not affected. Currently, this feature - only works with EABI compilers. If unsure say Y. + only works with EABI compilers. If unsure say N. config DEBUG_USER bool "Verbose user fault messages" -- 1.6.0.4 --------------090103040504000907090608-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/