On Wed, 6 Dec 2006, Jaswinder Singh wrote:
> I am playing with linux kernel but kernel dumps on WARN_ON , when I
> commented WARN_ON in my code my kernel starts working but I get two
> sideeffects :-
Hi,
please, submit a proper bugreport, including all the needed data (see
REPORTING-BUGS docu
Hi,
I am playing with linux kernel but kernel dumps on WARN_ON , when I
commented WARN_ON in my code my kernel starts working but I get two
sideeffects :-
1. During Boot kernel Hangs sometimes in :-
Updating /etc/motd...done.
INIT: Entering runlevel: 3
<>
2. Always Hangs in :-
cat /proc/interru
* Horst H. von Brand <[EMAIL PROTECTED]> wrote:
> Why not just:
>
> WARN_ON(debug_locks_off())
>
> here? Would give a more readable message too, IMHO.
debug_locks_off() has a side-effect, and in general we dont like to put
stuff with side-effects witin WARN_ON().
Ingo
-
To unsubs
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
> Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] let WARN_ON() output the condition
> >
> > It is possible, in some cases, that the output of WARN_ON() is ambig
* Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Ingo Molnar wrote:
>
> > i'll probably ack such a patch, it can be useful even when the line
> > number is unique: if someone reports a WARN_ON() from an old kernel i
> > dont have to dig up the exact source but can see it right fr
On Dec 6 2006 10:07, Ingo Molnar wrote:
>
>i'll probably ack such a patch, it can be useful even when the line
>number is unique: if someone reports a WARN_ON() from an old kernel i
>dont have to dig up the exact source but can see it right from the
>condition what happened. Useful redundancy i
On Wed, 6 Dec 2006, Ingo Molnar wrote:
> i'll probably ack such a patch, it can be useful even when the line
> number is unique: if someone reports a WARN_ON() from an old kernel i
> dont have to dig up the exact source but can see it right from the
> condition what happened. Useful redundancy
* Jiri Kosina <[EMAIL PROTECTED]> wrote:
> > but i agree with you in theory that your proposed output is better, but
> > the side-effect issue is a killer i think. Could you try to rework it to
> > not evaluate the condition twice and to make it dependent on
> > CONFIG_DEBUG_BUGVERBOSE? You ca
On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > DEBUG_LOCKS_WARN_ON(in_interrupt());\
> > local_irq_save(flags); \
> > __raw_spin_lock(&(lock)->raw_lock); \
> > DEBUG_LOCKS_WARN_ON(l->magic != l); \
> > When on
* Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Ingo Molnar wrote:
>
> > a WARN_ON() also triggers a stack dump, which should pinpoint the exact
> > location. (especially if combined with kallsyms) For example:
>
> Actually, I was referring to something a little bit different. F
On Wed, 6 Dec 2006, Ingo Molnar wrote:
> a WARN_ON() also triggers a stack dump, which should pinpoint the exact
> location. (especially if combined with kallsyms) For example:
Actually, I was referring to something a little bit different. For example
kernel/mutex.c:__mutex_lock_common() calls
* Jiri Kosina <[EMAIL PROTECTED]> wrote:
> [PATCH] let WARN_ON() output the condition
>
> It is possible, in some cases, that the output of WARN_ON() is
> ambiguous and can't be properly used to identify the exact condition
> which caused the warning to trigger. This
On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> [PATCH] let WARN_ON() output the condition
>
> It is possible, in some cases, that the output of WARN_ON() is ambiguous
> and can't be properly used to identify the exact condition which c
[PATCH] let WARN_ON() output the condition
It is possible, in some cases, that the output of WARN_ON() is ambiguous
and can't be properly used to identify the exact condition which caused
the warning to trigger. This happens whenever there is a macro that
contains multiple WARN_ONs i
14 matches
Mail list logo
