Subject: Fix x86 32 bit FRAME_POINTER chasing code
From: Arjan van de Ven [EMAIL PROTECTED]
The current x86 32 bit FRAME_POINTER chasing code has a nasty bug in
that the EBP tracer doesn't actually update the value of EBP it is
tracing, so that the code doesn't actually switch to the irq stack
Subject: x86: Improve the 32 bit Frame Pointer backtracer to also use the
traditional backtrace
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit Frame Pointer backtracer code checks if the EBP is valid
to do a backtrace; however currently on a failure it just gives up
and prints nothing
Subject: x86: pull EBP calculation earlier into the backtrace path
From: Arjan van de Ven [EMAIL PROTECTED]
Right now, we take the stack pointer early during the backtrace path, but
only calculate EBP several functions deep later, making it hard to reconcile
the stack and EBP backtraces (as well
Subject: x86: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit
has
From: Arjan van de Ven [EMAIL PROTECTED]
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code
into a function, just like 32 bit has. This is needed pre work in order to
get exact backtraces
Subject: x86: Use the stack frames to get exact stack-traces for
CONFIG_FRAMEPOINTER on x86-64
From: Arjan van de Ven [EMAIL PROTECTED]
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only
Subject: x86: Add a simple backtrace test module
From: Arjan van de Ven [EMAIL PROTECTED]
During the work on the x86 32 and 64 bit backtrace code I found it useful
to have a simple test module to test a process and irq context backtrace.
Since the existing backtrace code was buggy, I figure
Subject: x86: Add the print code before the trapping instruction feature to
64 bit
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit x86 tree has a very useful feature that prints the Code: line
for the code even before the trapping instrution (and the start of the
trapping instruction
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 9 Jan 2008, Arjan van de Ven wrote:
> >
> > + if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
> > + while (valid_stack_ptr(tinfo, frame,
> >
Subject: x86: Add the "print code before the trapping instruction" feature to
64 bit
From: Arjan van de Ven <[EMAIL PROTECTED]>
The 32 bit x86 tree has a very useful feature that prints the Code: line
for the code even before the trapping instrution (and the start of the
trap
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 9 Jan 2008, Arjan van de Ven wrote:
> >
> > + if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
> > + while (valid_stack_ptr(tinfo, frame,
> >
On Thu, 10 Jan 2008 13:46:06 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Arjan, I've been doing some work on traps_32.c porting over the
> > oops_begin()/oops_end()/_die() arrangement from traps_64.c and then
> > use it in unifying some more parts of fault.c.
>
> i've got that applied and
On Thu, 10 Jan 2008 13:46:06 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
Arjan, I've been doing some work on traps_32.c porting over the
oops_begin()/oops_end()/_die() arrangement from traps_64.c and then
use it in unifying some more parts of fault.c.
i've got that applied and it did
Subject: x86: Add the print code before the trapping instruction feature to
64 bit
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit x86 tree has a very useful feature that prints the Code: line
for the code even before the trapping instrution (and the start of the
trapping instruction
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008, Arjan van de Ven wrote:
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
+ while (valid_stack_ptr(tinfo, frame,
sizeof(*frame))) {
Why?
Why not just make
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008, Arjan van de Ven wrote:
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
+ while (valid_stack_ptr(tinfo, frame,
sizeof(*frame))) {
Why?
Why not just make
Subject: Add a simple backtrace test module
From: Arjan van de Ven <[EMAIL PROTECTED]>
During the work on the x86 32 and 64 bit backtrace code I found it useful
to have a simple test module to test a process and irq context backtrace.
Since the existing backtrace code was buggy, I
This patch is simple; I don't know if it's .24 candidate; the bug is pretty bad
but not a recent regression,
and there is obviously some risk with touching this code.
Subject: Fix x86 32 bit FRAME_POINTER chasing code
From: Arjan van de Ven <[EMAIL PROTECTED]>
The current x86
Subject: Make the 32 bit Frame Pointer backtracer fall back to traditional
From: Arjan van de Ven <[EMAIL PROTECTED]>
The 32 bit Frame Pointer backtracer code checks if the EBP is valid
to do a backtrace; however currently on a failure it just gives up
and prints nothing. That's not ver
On Thu, 10 Jan 2008 01:47:16 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > I'm btw all in favor of making mmio tracing full fledged kernel
> > infrastructure. This doesn't mean "notifier" imo; th
On Wed, 9 Jan 2008 20:22:54 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 06:58:23AM +1100, Benjamin Herrenschmidt
> wrote:
> > It's a sane thing to do, Christoph, I don't think it's a
> > unreasonable request to put the hooks back in.
>
> As said a few times
On Wed, 9 Jan 2008 18:48:00 +0100
> And after all that's still by far the most common system call
> (not only for databases; i profiled this using systemtap in some
> loads some time ago and it usually came up with >50%)
> and quite important for many workloads.
>
btw be careful with this; the
Johannes Berg wrote:
Rank 1: __ieee80211_rx
Warning at net/mac80211/rx.c:1672
Reported 6 times (11 total reports)
Same issue that was ranked 2nd last week
Johannes has diagnosed this as a driver bug in the iwlwifi drivers
More info:
On Wed, 9 Jan 2008 03:17:37 + (GMT)
Dave Airlie <[EMAIL PROTECTED]> wrote:
> So all distros with 2.6.24 kernels are useless to mmiotrace I don't
> see why leaving things as is until a suitable replacement mechanism
> can be used..
you work for a distro.. surely you can convince your own
On Wed, 9 Jan 2008 03:17:37 + (GMT)
Dave Airlie [EMAIL PROTECTED] wrote:
So all distros with 2.6.24 kernels are useless to mmiotrace I don't
see why leaving things as is until a suitable replacement mechanism
can be used..
you work for a distro.. surely you can convince your own distro
Johannes Berg wrote:
Rank 1: __ieee80211_rx
Warning at net/mac80211/rx.c:1672
Reported 6 times (11 total reports)
Same issue that was ranked 2nd last week
Johannes has diagnosed this as a driver bug in the iwlwifi drivers
More info:
On Wed, 9 Jan 2008 18:48:00 +0100
And after all that's still by far the most common system call
(not only for databases; i profiled this using systemtap in some
loads some time ago and it usually came up with 50%)
and quite important for many workloads.
btw be careful with this; the X
On Wed, 9 Jan 2008 20:22:54 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 06:58:23AM +1100, Benjamin Herrenschmidt
wrote:
It's a sane thing to do, Christoph, I don't think it's a
unreasonable request to put the hooks back in.
As said a few times before there's
On Thu, 10 Jan 2008 01:47:16 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
I'm btw all in favor of making mmio tracing full fledged kernel
infrastructure. This doesn't mean notifier imo; this means a real
flag in the struct page, and then the page
This patch is simple; I don't know if it's .24 candidate; the bug is pretty bad
but not a recent regression,
and there is obviously some risk with touching this code.
Subject: Fix x86 32 bit FRAME_POINTER chasing code
From: Arjan van de Ven [EMAIL PROTECTED]
The current x86 32 bit
Subject: Make the 32 bit Frame Pointer backtracer fall back to traditional
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit Frame Pointer backtracer code checks if the EBP is valid
to do a backtrace; however currently on a failure it just gives up
and prints nothing. That's not very nice; we
Linus Torvalds wrote:
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
the database has the information so it's just a matter of slightly different
php code ;)
Before I do that... do you want the BUG's separate, part of the warnings or
part of the oopses?
(I rather make this change once ;)
I'd
Linus Torvalds wrote:
Cool.
One thing I wonder about - could you separate out the bug-ons and warnings
from the oopses? They really are different issues, and an oops with
register information etc is very different from a BUG() with line numbers,
which in turn is very different from a
Randy Dunlap wrote:
(You can do it other and smarter ways too, I'm not claiming that's a
particularly good way to do it, and the old "ksymoops" program used to do
a pretty good job of this, but I'm used to that particular idiotic way
myself, since it's how I've basically always done it)
On Tue, 08 Jan 2008 18:01:48 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > The code tries to use the frame pointers to do a backtrace, but if
> > it smells iffy or invalid, falls back to the traditional way of
> > printing backtraces, to make sure that at least some useful
> > backtrace is
On Tue, 8 Jan 2008 14:51:37 +0100
DM <[EMAIL PROTECTED]> wrote:
> On Jan 7, 2008 12:19 AM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> [...]
> > This patch tracks the last unloaded module, and prints this as part
> > of the
On Tue, 8 Jan 2008 14:51:37 +0100
DM [EMAIL PROTECTED] wrote:
On Jan 7, 2008 12:19 AM, Arjan van de Ven [EMAIL PROTECTED] wrote:
[...]
This patch tracks the last unloaded module, and prints this as part
of the module list in the oops trace.
[...]
}
+ /* Store the name
On Tue, 08 Jan 2008 18:01:48 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
The code tries to use the frame pointers to do a backtrace, but if
it smells iffy or invalid, falls back to the traditional way of
printing backtraces, to make sure that at least some useful
backtrace is created.
Randy Dunlap wrote:
(You can do it other and smarter ways too, I'm not claiming that's a
particularly good way to do it, and the old ksymoops program used to do
a pretty good job of this, but I'm used to that particular idiotic way
myself, since it's how I've basically always done it)
One
Linus Torvalds wrote:
Cool.
One thing I wonder about - could you separate out the bug-ons and warnings
from the oopses? They really are different issues, and an oops with
register information etc is very different from a BUG() with line numbers,
which in turn is very different from a
Linus Torvalds wrote:
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
the database has the information so it's just a matter of slightly different
php code ;)
Before I do that... do you want the BUG's separate, part of the warnings or
part of the oopses?
(I rather make this change once ;)
I'd
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven <[EMAIL PROTECTED]>
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
Thi
Subject: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code into
a function, just like 32 bit has. This is needed pre work in order to get exact
back
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> We could replace the __you_cannot_kmalloc_that_much() with a BUG()
> statement so we have the same effect in SLAB?
>
sounds like a bad idea; a compile time failure is of course nicer than
a runtime failure
On Mon, 07 Jan 2008 11:09:23 +0100
[EMAIL PROTECTED] wrote:
> this looks very useful!
>
> >Unfortunatly, it's not always easy to see directly
> >which module is being loaded/unloaded from the oops itself.
>
> no wonder, as most modules seem to be very quiet on on load/unload.
>
>
> but i
On Sun, 6 Jan 2008 23:18:48 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > Venki Pallipadi wrote:
> > > Reintroduce run time configurable max_cstate for !CPU_IDLE case.
> > >
> > > Signed-off-by: Venkatesh Pallipadi
On Sun, 6 Jan 2008 23:18:48 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord [EMAIL PROTECTED] wrote:
Venki Pallipadi wrote:
Reintroduce run time configurable max_cstate for !CPU_IDLE case.
Signed-off-by: Venkatesh Pallipadi [EMAIL
On Mon, 07 Jan 2008 11:09:23 +0100
[EMAIL PROTECTED] wrote:
this looks very useful!
Unfortunatly, it's not always easy to see directly
which module is being loaded/unloaded from the oops itself.
no wonder, as most modules seem to be very quiet on on load/unload.
but i wonder if
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
We could replace the __you_cannot_kmalloc_that_much() with a BUG()
statement so we have the same effect in SLAB?
sounds like a bad idea; a compile time failure is of course nicer than
a runtime failure for
Subject: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
From: Arjan van de Ven [EMAIL PROTECTED]
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code into
a function, just like 32 bit has. This is needed pre work in order to get exact
backtraces
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven [EMAIL PROTECTED]
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only
On Sun, 6 Jan 2008 19:22:37 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> This comment in oops_enter threw me off of using it:
>
> debug_locks_off(); /* can't trust the integrity of the kernel
> anymore */
>
> Since we can very well depend on the integrity of the kernel when
Subject: track and print last unloaded module in the oops trace
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Based on a suggestion from Andi:
In various cases, the unload of a module may leave some bad state around
that
Subject: show being-loaded/being-unloaded indicator for modules in oopses
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
It's rather common that an oops/WARN_ON/BUG happens during the load or
unload of a module. Unfortunatly
t; >> Date : 2007-12-02 04:23
> >> References : http://lkml.org/lkml/2007/12/1/141
> >> http://bugzilla.kernel.org/show_bug.cgi?id=9489
> >> Handled-By : Arjan van de Ven <[EMAIL PROTECTED]>
> >>
> >
> > I
On Sun, 6 Jan 2008 14:22:23 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> Powerpc uses the generic report_bug() from lib/bug.c to report
> warnings, and I'm guessing other arches do as well.
>
> Add the module list as well as the end-of-trace marker to the output.
> This required making
On Sun, 06 Jan 2008 17:09:44 +0100
Richard Knutsson <[EMAIL PROTECTED]> wrote:
> >> (btw, wouldn't 'var != 0' actually be the proper semantic instead
> >> of playing with '!'s?)
> >>
> >
> > no because var could be a pointer for example...
> >
> You mean because in that case it would be
On Sun, 06 Jan 2008 12:44:56 +0100
Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > From: Olof Johansson <[EMAIL PROTECTED]>
> >
> > Introduce __WARN() in the generic case, so the generic WARN_ON()
> > can use arch-speci
://bugzilla.kernel.org/show_bug.cgi?id=9489
Handled-By : Arjan van de Ven [EMAIL PROTECTED]
I wonder if it's just a babbling IRQ on resume, before the driver
has run it's resume code or something ?
i've read the discussions, and i cannot see it analyzed anywhere
_what_ causes the wakeups. And how
Subject: show being-loaded/being-unloaded indicator for modules in oopses
From: Arjan van de Ven [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
It's rather common that an oops/WARN_ON/BUG happens during the load or
unload of a module. Unfortunatly, it's
Subject: track and print last unloaded module in the oops trace
From: Arjan van de Ven [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Based on a suggestion from Andi:
In various cases, the unload of a module may leave some bad state around
that causes
On Sun, 6 Jan 2008 19:22:37 -0600
Olof Johansson [EMAIL PROTECTED] wrote:
This comment in oops_enter threw me off of using it:
debug_locks_off(); /* can't trust the integrity of the kernel
anymore */
Since we can very well depend on the integrity of the kernel when it's
On Sun, 06 Jan 2008 12:44:56 +0100
Richard Knutsson [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
From: Olof Johansson [EMAIL PROTECTED]
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof
On Sun, 06 Jan 2008 17:09:44 +0100
Richard Knutsson [EMAIL PROTECTED] wrote:
(btw, wouldn't 'var != 0' actually be the proper semantic instead
of playing with '!'s?)
no because var could be a pointer for example...
You mean because in that case it would be '!= NULL', do you?
On Sun, 6 Jan 2008 14:22:23 -0600
Olof Johansson [EMAIL PROTECTED] wrote:
Powerpc uses the generic report_bug() from lib/bug.c to report
warnings, and I'm guessing other arches do as well.
Add the module list as well as the end-of-trace marker to the output.
This required making
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
Rank 4: remove_proc_entry
Was also ranked 4th last week
Only in tainted oopses
Reported 3 times (12 total reports)
More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
From: Olof Johansson <[EMAIL PROTECTED]>
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL
From: Olof Johansson <[EMAIL PROTECTED]>
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than just
doing a compare and branch.
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently does't print
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Acked-by: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that ther
From: Olof Johansson <[EMAIL PROTECTED]>
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
3rd try for this patch series; now with a split up patch for __WARN_ON
This series has the goal of extending the usefulness of the WARN_ON()
information,
at least on architectures that use the generic WARN_ON() infrastructure. (Those
who
do their own thing either already have the extra
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted
Jeremy Fitzhardinge wrote:
Yeah, that seems reasonable if you're optimising for overall size. Did
you count the difference of including the function name? We decided not
to include it for BUG because its usefulness/size tradeoff didn't seem
terribly important.
in the WARN_ON case it's not
Arjan van de Ven wrote:
So... call me unconvinced for now. There's 30 Kb on the table with the
easy, obviously safe
transform, and maybe another 1Kb with the much more tricky trapping
scenario, but only
for the vmlinux case; the module case seems to be a loss instead.
Eh I have to retract my
Herbert Xu wrote:
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
While we're here, I'll mention that dump_stack probably ought to take a
severity level argument.
125 files changed, 202 insertions(+), 199 deletions(-)
just to get the api change done.
I can hear akpm cringe from here...
You
Arjan van de Ven wrote:
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch predictor logic and gives
Arjan van de Ven wrote:
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch predictor logic and gives
Herbert Xu wrote:
Arjan van de Ven [EMAIL PROTECTED] wrote:
While we're here, I'll mention that dump_stack probably ought to take a
severity level argument.
125 files changed, 202 insertions(+), 199 deletions(-)
just to get the api change done.
I can hear akpm cringe from here...
You don't
Arjan van de Ven wrote:
So... call me unconvinced for now. There's 30 Kb on the table with the
easy, obviously safe
transform, and maybe another 1Kb with the much more tricky trapping
scenario, but only
for the vmlinux case; the module case seems to be a loss instead.
Eh I have to retract my
Jeremy Fitzhardinge wrote:
Yeah, that seems reasonable if you're optimising for overall size. Did
you count the difference of including the function name? We decided not
to include it for BUG because its usefulness/size tradeoff didn't seem
terribly important.
in the WARN_ON case it's not
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted
From: Olof Johansson [EMAIL PROTECTED]
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
3rd try for this patch series; now with a split up patch for __WARN_ON
This series has the goal of extending the usefulness of the WARN_ON()
information,
at least on architectures that use the generic WARN_ON() infrastructure. (Those
who
do their own thing either already have the extra
Subject: move WARN_ON() out of line
From: Arjan van de Ven [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Olof Johansson [EMAIL PROTECTED]
Acked-by: Matt Meckall [EMAIL PROTECTED]
A quick grep shows that there are currently 1145 instances of WARN_ON
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Olof Johansson [EMAIL PROTECTED]
Unlike oopses, WARN_ON() currently does't print the loaded modules list
From: Olof Johansson [EMAIL PROTECTED]
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL
From: Olof Johansson [EMAIL PROTECTED]
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than just
doing a compare and branch.
Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
Rank 4: remove_proc_entry
Was also ranked 4th last week
Only in tainted oopses
Reported 3 times (12 total reports)
More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Likely
On Tue, 1 Jan 2008 17:23:28 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Theodore Tso <[EMAIL PROTECTED]> wrote:
>
> > [...] doesn't a patch to provide /proc/slabinfo for SLUB already
> > exist?
>
> yes, the complete (and tested) patch is below. It has been through a
> few thousand
Heiko Carstens wrote:
On Thu, Jan 03, 2008 at 10:27:28PM +0100, Arjan van de Ven wrote:
Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, t
Ingo Molnar wrote:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
+ printk(KERN_WARNING "[ cut here ]\n");
printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
line, function);
+ print_mod
Ingo Molnar wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:
+ printk(KERN_WARNING [ cut here ]\n);
printk(KERN_WARNING WARNING: at %s:%d %s()\n, file,
line, function);
+ print_modules();
dump_stack
Heiko Carstens wrote:
On Thu, Jan 03, 2008 at 10:27:28PM +0100, Arjan van de Ven wrote:
Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful cut here line, nor the end of trace marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal
On Tue, 1 Jan 2008 17:23:28 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Theodore Tso [EMAIL PROTECTED] wrote:
[...] doesn't a patch to provide /proc/slabinfo for SLUB already
exist?
yes, the complete (and tested) patch is below. It has been through a
few thousand random-bootup
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently doesn't
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
CC: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that ther
Matt Mackall wrote:
I hate the do_foo naming scheme (how about __warn_on?), but otherwise:
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
after I moved it around based on Olof's work, I've now ended up with
warn_on_slowpath()
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n",
+
Olof Johansson wrote:
On Thu, Jan 03, 2008 at 01:56:58AM +0100, Arjan van de Ven wrote:
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
A quick grep shows that there
901 - 1000 of 3577 matches
Mail list logo
