From: omar.ramirez@ti.com (Ramirez Luna, Omar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: BUG() dies silently
Date: Mon, 4 Apr 2011 21:29:45 -0500 [thread overview]
Message-ID: <BANLkTimhk_G0fapzHAf0Gc-XhqT0qu+VbQ@mail.gmail.com> (raw)
In-Reply-To: <4D981EAB.8070209@codeaurora.org>
Hi Simon, Stephen,
On Sun, Apr 3, 2011 at 2:15 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> (Please stop top posting)
>
> On 4/1/2011 3:29 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> Sorry for the confusion, but in fact I was talking about the patch to
>> make ARM use the generic bug handling via an undef instruction instead
>> of calling ______bug() or writing to memory address 0. Please see
>> here:
>>
>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6808/1
>
> Yes I've seen your patch (and even posted comments on it which have not
> been responded to).
>
> Correct me if I'm wrong, but that patch with CONFIG_BUG=n would lead to
> the same error that Omar is seeing because the code only modifies the
> bug infrastructure when CONFIG_BUG=y.
I am using CONFIG_BUG=y, however I don't have CONFIG_DEBUG_BUGVERBOSE
and hence I fall into the part which doesn't print the file and the
line where the BUG was found.
With Simon's patch if my .config had:
CONFIG_BUG=y
CONFIG_GENERIC_BUG is not set
CONFIG_DEBUG_BUGVERBOSE is not set
I would fall into the same BUG definition that is causing issues:
#define BUG() do { *(int *)0 = 0; } while (1)
OTOH, is not like "Use generic BUG() handler" gives the choice of
removing GENERIC_BUG given that it is not prompted in menuconfig and
auto selected, if this is the intention is there any reason to keep
the #else part of /* not CONFIG_GENERIC_BUG */? there is no way we can
use it with this patch, right?
Regards,
Omar
next prev parent reply other threads:[~2011-04-05 2:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-31 20:15 [PATCH] ARM: BUG() dies silently Omar Ramirez Luna
2011-04-01 1:47 ` Simon Glass
2011-04-01 8:44 ` Stephen Boyd
2011-04-01 22:29 ` Simon Glass
2011-04-03 7:15 ` Stephen Boyd
2011-04-05 1:55 ` Simon Glass
2011-04-05 17:36 ` Stephen Boyd
2011-04-05 2:29 ` Ramirez Luna, Omar [this message]
2011-04-05 5:46 ` Simon Glass
2011-04-05 16:02 ` Ramirez Luna, Omar
2011-04-05 16:43 ` Simon Glass
2011-09-17 6:07 ` Rabin Vincent
2011-09-19 14:26 ` Ramirez Luna, Omar
2011-09-19 14:43 ` Russell King - ARM Linux
2011-09-19 16:59 ` Russell King - ARM Linux
2011-09-19 18:02 ` Simon Glass
2011-09-19 18:25 ` Russell King - ARM Linux
2011-09-19 18:32 ` Ramirez Luna, Omar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTimhk_G0fapzHAf0Gc-XhqT0qu+VbQ@mail.gmail.com \
--to=omar.ramirez@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).