ops happens even in 2.6.24-rc8 and the fix is rather obvious, so
it might even be 2.6.24 material (or for 24-stable just after that)
Subject: lockdep: fix kernel crash on module unload
From: Arjan van de Ven <[EMAIL PROTECTED]>
Michael Wu noticed in his lkml post at
http://marc.info
Subject: x86: Add testcases for RODATA and NX protections/attributes
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch adds testcases for the CONFIG_DEBUG_RODATA configuration option
as well as the NX CPU feature/mappings. Both testcases can move to tests/
once that patch gets
On Wed, 23 Jan 2008 17:54:01 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> But ok given that it's already merged I'll shut up now since it's too
> late.
I asked you before to cut the unjustified sarcasm; all I can do is ask again.
--
If you want to reach me at my work email, use [EMAIL
On Wed, 23 Jan 2008 16:27:28 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > What it does is check if the rodata marking was succesful.
>
> The only difference I see is that you check that the TLB flush works,
> but for that it looks awfully incomplete.
you think one level too small.
It
On 23 Jan 2008 10:09:58 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > This patch adds a test module for the DEBUG_RODATA config
> > option to make sure change_page_attr() did indeed make
> > "const"
On 23 Jan 2008 10:09:58 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
This patch adds a test module for the DEBUG_RODATA config
option to make sure change_page_attr() did indeed make
const data read only.
The only that this does that is not done
On Wed, 23 Jan 2008 16:27:28 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
What it does is check if the rodata marking was succesful.
The only difference I see is that you check that the TLB flush works,
but for that it looks awfully incomplete.
you think one level too small.
It tests if
On Wed, 23 Jan 2008 17:54:01 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
But ok given that it's already merged I'll shut up now since it's too
late.
I asked you before to cut the unjustified sarcasm; all I can do is ask again.
--
If you want to reach me at my work email, use [EMAIL
Subject: x86: Add testcases for RODATA and NX protections/attributes
From: Arjan van de Ven [EMAIL PROTECTED]
This patch adds testcases for the CONFIG_DEBUG_RODATA configuration option
as well as the NX CPU feature/mappings. Both testcases can move to tests/
once that patch gets merged
happens even in 2.6.24-rc8 and the fix is rather obvious, so
it might even be 2.6.24 material (or for 24-stable just after that)
Subject: lockdep: fix kernel crash on module unload
From: Arjan van de Ven [EMAIL PROTECTED]
Michael Wu noticed in his lkml post at
http://marc.info/?l=linux
On Wed, 23 Jan 2008 12:11:41 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > #ifdef CONFIG_DEBUG_RODATA
> >
> > +const int rodata_test_data = 5;
>
> I guess this should match the 32-bit case, and be zero instead of
> 5?
actually it should have been 5 for both (well any non-zero number)
>
>
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: x86: test case for the RODATA config option
This patch adds a test module for the DEBUG_RODATA config
option to make sure change_page_attr() did indeed make
"const" data read only.
This testcase both tests the DEBUG_ROD
Török Edwin wrote:
Hi Arjan, Ingo,
[for minor latencytop userspace specific issues see at end of mail]
* if I compile with CONFIG_SCHED_DEBUG I see a 30-40msec latency from
the scheduler, always (Scheduler: waiting for cpu).
There is also a constant ~5% user, ~2% sys CPU usage on an idle
Török Edwin wrote:
Hi Arjan, Ingo,
[for minor latencytop userspace specific issues see at end of mail]
* if I compile with CONFIG_SCHED_DEBUG I see a 30-40msec latency from
the scheduler, always (Scheduler: waiting for cpu).
There is also a constant ~5% user, ~2% sys CPU usage on an idle
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: x86: test case for the RODATA config option
This patch adds a test module for the DEBUG_RODATA config
option to make sure change_page_attr() did indeed make
const data read only.
This testcase both tests the DEBUG_RODATA code as well
On Wed, 23 Jan 2008 12:11:41 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
#ifdef CONFIG_DEBUG_RODATA
+const int rodata_test_data = 5;
I guess this should match the 32-bit case, and be zero instead of
5?
actually it should have been 5 for both (well any non-zero number)
Can you
On Mon, 21 Jan 2008 13:20:46 -0800
Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Introduce printk_address to X86_32 in a simplified form for
> now. Reformat X86_64 printk_address to avoid two declarations.
>
> Change the printk formats on X86_32 and 64 to be similar.
I'm not entirely convinced
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: sched: Keep total / count stats in addition to the max for wait time
Right now, the linux kernel (with scheduler statistics enabled) keeps track
of the maximum time a process is waiting to be scheduled. While the maximum
is a very useful
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 9 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
KOSAKI Motohiro wrote:
Hi
+static void __sched
+account_global_scheduler_latency(struct task_struct *tsk, int usecs)
+{
+ int i;
+ int firstnonnull = MAXLR + 1;
+
+ if (!tsk->latency_reason.reason)
+ return;
+
+ /* skip kernel threads for now */
+ if
KOSAKI Motohiro wrote:
Hi
+static void __sched
+account_global_scheduler_latency(struct task_struct *tsk, int usecs)
+{
+ int i;
+ int firstnonnull = MAXLR + 1;
+
+ if (!tsk-latency_reason.reason)
+ return;
+
+ /* skip kernel threads for now */
+ if
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 9 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: sched: Keep total / count stats in addition to the max for wait time
Right now, the linux kernel (with scheduler statistics enabled) keeps track
of the maximum time a process is waiting to be scheduled. While the maximum
is a very useful metric
On Mon, 21 Jan 2008 13:20:46 -0800
Harvey Harrison [EMAIL PROTECTED] wrote:
Introduce printk_address to X86_32 in a simplified form for
now. Reformat X86_64 printk_address to avoid two declarations.
Change the printk formats on X86_32 and 64 to be similar.
I'm not entirely convinced on
Török Edwin wrote:
Hi Arjan,
One of the top reasons in latencytop is
Unknown reason (blk_execute_rq+0x7a/0xd) 152.3 msec
49.0 msec
Its from hddtemp, hald-addon-storage, ...
I wrote a simple systemtap script [1] to find out where its called from,
and its definitely from the
Andi Kleen wrote:
another thing that the current profiling can't do, is to show what the
system is doing
when it hits the latency.. so someone calling fsync() will show up in the
waiting for
IO function, but not that it was due to an fsync().
Hmm so how about extending oprofile to always log
Andi Kleen wrote:
yes indeed; I sort of use the same infrastructure inside the scheduler; the
biggest
reason I felt I had to do something different was that I wanted to do per
process
data collection, so that you can see for a specific process what was going
on.
Wouldn't it have been easier
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
Just for completeness -- Linux already had a way to profile lat
Frank Ch. Eigler wrote:
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
[...]
Can you suggest of some reason why all this instrumentation could
not be in the form of standard markers (perhaps conditionally
compiled out if necessary)?
sure. Every instrumentation you see
On Fri, 18 Jan 2008 17:26:09 -0500
[EMAIL PROTECTED] (Frank Ch. Eigler) wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > This patch contains the first set of instrumentations for
> > latencytop; each instrumentation needs to be evaluated for
> >
Roberto Fichera wrote:
At 18.36 18/01/2008, Arjan van de Ven wrote:
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
http://www.latencytop.org
[...snip...]
The most basic
A few more high level annotations for LatencyTOP;
split into a separate patch since they're at a higher level
than the first part (and thus hide some lower level details
potentially, but could also obsolete several other low level
instrumentations)
---
fs/read_write.c |7 ++-
This patch contains the first set of instrumentations for latencytop;
each instrumentation needs to be evaluated for usefulness before this
can go into mainline; posting here just to show how the infrastructure
can be used
---
arch/x86/mm/fault_64.c|4
block/ll_rw_blk.c |
===
--- /dev/null
+++ linux-2.6.24-rc7/include/linux/latencytop.h
@@ -0,0 +1,62 @@
+/*
+ * latencytop.h: Infrastructure for displaying latency
+ *
+ * (C) Copyright 2008 Intel Corporation
+ * Author: Arjan van de Ven <[EMAIL PROTEC
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
http://www.latencytop.org
Slow servers, Skipping audio, Jerky video --everyone knows the symptoms
of latency. But to know what's really
On Fri, 18 Jan 2008 13:36:11 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > Subject: x86: Add support for the latest Intel processors to
> > Oprofile From: Arjan van de Ven <[EMAIL PROTECTED]>
> &g
A few more high level annotations for LatencyTOP;
split into a separate patch since they're at a higher level
than the first part (and thus hide some lower level details
potentially, but could also obsolete several other low level
instrumentations)
---
fs/read_write.c |7 ++-
Frank Ch. Eigler wrote:
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
[...]
Can you suggest of some reason why all this instrumentation could
not be in the form of standard markers (perhaps conditionally
compiled out if necessary)?
sure. Every instrumentation you see
On Fri, 18 Jan 2008 17:26:09 -0500
[EMAIL PROTECTED] (Frank Ch. Eigler) wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
This patch contains the first set of instrumentations for
latencytop; each instrumentation needs to be evaluated for
usefulness before this can go into mainline
===
--- /dev/null
+++ linux-2.6.24-rc7/include/linux/latencytop.h
@@ -0,0 +1,62 @@
+/*
+ * latencytop.h: Infrastructure for displaying latency
+ *
+ * (C) Copyright 2008 Intel Corporation
+ * Author: Arjan van de Ven [EMAIL PROTECTED
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
http://www.latencytop.org
Slow servers, Skipping audio, Jerky video --everyone knows the symptoms
of latency. But to know what's really
Roberto Fichera wrote:
At 18.36 18/01/2008, Arjan van de Ven wrote:
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
http://www.latencytop.org
[...snip...]
The most basic
On Fri, 18 Jan 2008 13:36:11 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:
Subject: x86: Add support for the latest Intel processors to
Oprofile From: Arjan van de Ven [EMAIL PROTECTED]
The latest Intel processors (the 45nm ones) have a model
This patch contains the first set of instrumentations for latencytop;
each instrumentation needs to be evaluated for usefulness before this
can go into mainline; posting here just to show how the infrastructure
can be used
---
arch/x86/mm/fault_64.c|4
block/ll_rw_blk.c |
Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
The Intel Open Source Technology Center is pleased to announce the
release of version 0.1 of LatencyTOP, a tool for developers to visualize
system latencies.
Just for completeness -- Linux already had a way to profile latencies
Andi Kleen wrote:
yes indeed; I sort of use the same infrastructure inside the scheduler; the
biggest
reason I felt I had to do something different was that I wanted to do per
process
data collection, so that you can see for a specific process what was going
on.
Wouldn't it have been easier
Andi Kleen wrote:
another thing that the current profiling can't do, is to show what the
system is doing
when it hits the latency.. so someone calling fsync() will show up in the
waiting for
IO function, but not that it was due to an fsync().
Hmm so how about extending oprofile to always log
Subject: x86: Add support for the latest Intel processors to Oprofile
From: Arjan van de Ven <[EMAIL PROTECTED]>
The latest Intel processors (the 45nm ones) have a model number of 23
(old ones had 15); they're otherwise compatible on the oprofile side.
This patch adds the new model
Subject: x86: Add support for the latest Intel processors to Oprofile
From: Arjan van de Ven [EMAIL PROTECTED]
The latest Intel processors (the 45nm ones) have a model number of 23
(old ones had 15); they're otherwise compatible on the oprofile side.
This patch adds the new model number
This required making print_oops_end_marker() nonstatic.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
>
All three are
Acked-by: Arjan van de Ven <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
print_oops_end_marker() nonstatic.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
All three are
Acked-by: Arjan van de Ven [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Mon, 14 Jan 2008 10:23:14 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Mon, 14 Jan 2008 08:01:01 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >>
> >> If we're going to differentiate MMCONFIG from
> >>
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sun, 13 Jan 2008 22:29:23 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >> . There is no need to provide different PCI config access
>
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config
On Mon, 14 Jan 2008 10:23:14 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
If we're going to differentiate MMCONFIG from
some other access mechanism, it only needs to be done
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> . There is no need to provide different PCI config access
>mechanisms at device granularity, since the PCI config access
>mechanism between the CPU and the Northbridge is opaque to
>the devices. PCI config
On Mon, 14 Jan 2008 00:54:34 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jan 2008 16:28:08 -0500
> Tony Camuso <[EMAIL PROTECTED]> wrote:
>
> > Arjan van de Ven wrote:
> >
> > >> The PCI spec provides for conf1 as an architected solutio
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
>
> 2) the pci_enable_ext_config() function and dev->ext_cfg_space field,
> sysfs interface should be
On Sun, 13 Jan 2008 07:43:11 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sat, 12 Jan 2008 20:36:59 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >
> > Just about NOBODY has devices that need the extended c
as a general thing I like where this patch is going
On Sun, 13 Jan 2008 00:24:15 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> +
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int
> devfn,
> + int reg, int len,
> u32 *val) +{
>
as a general thing I like where this patch is going
On Sun, 13 Jan 2008 00:24:15 -0700
Matthew Wilcox [EMAIL PROTECTED] wrote:
+
+int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int
devfn,
+ int reg, int len,
u32 *val) +{
+ if
On Sun, 13 Jan 2008 07:43:11 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Just about NOBODY has devices that need the extended config space.
At all.
The PCI express spec requires
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli [EMAIL PROTECTED] wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and dev-ext_cfg_space field,
sysfs interface should be removed from
On Mon, 14 Jan 2008 00:54:34 +
Alan Cox [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 16:28:08 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's
not going away, and especially not in x86 land where
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the devices. PCI config
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Thanks, Arjan.
>
> The problem we have been experiencing has to do with Northbridges,
> not with devices.
correct for now.
HOWEVER, and this is the point Linus has made several times:
Just about NOBODY has devices that
n this happens (including the name of the
app) so that if the system crashes as a result of this action, the user
can know what action/tool caused it.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentatio
Adrian Bunk wrote:
On Sat, Jan 12, 2008 at 03:13:29PM -0800, Arjan van de Ven wrote:
Adrian Bunk wrote:
All the other reports only contain the plain trace. Is there any way to
get more information whether the former is a pattern or not, and to
get this information somehow displayed
Adrian Bunk wrote:
All the other reports only contain the plain trace. Is there any way to
get more information whether the former is a pattern or not, and to
get this information somehow displayed on the webpage?
IF the kernel prints that its tainted or whatever it'll be shown, as well
as
On Sun, 13 Jan 2008 00:49:11 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> > btw this is my main objection to your patch; it intertwines the
> > conf1 and mmconfig code even more.
>
> There is no
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
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/pci/mmconfig_32.c
> +++ b/arch/x86/pci/mmconfig_32.c
> @@ -30,10 +30,6 @@ static u32 get_base_addr(unsigned int seg, int
> bus, unsigned devfn) struct acpi_mcfg_allocation *cfg;
> int cfg_num;
>
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
e.
>
> > Ivan, you posted one a while ago, but never seemed to get any
> > confirmation if it helped or not. Should I use that and drop
> > Arjan's?
>
> Actually I'm strongly against Arjan's patch. First, it's based
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky [EMAIL PROTECTED] wrote:
e.
Ivan, you posted one a while ago, but never seemed to get any
confirmation if it helped or not. Should I use that and drop
Arjan's?
Actually I'm strongly against Arjan's patch. First, it's based on
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky [EMAIL PROTECTED] wrote:
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -30,10 +30,6 @@ static u32 get_base_addr(unsigned int seg, int
bus, unsigned devfn) struct acpi_mcfg_allocation *cfg;
int cfg_num;
-
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
On Sun, 13 Jan 2008 00:49:11 +0300
Ivan Kokshaysky [EMAIL PROTECTED] wrote:
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
btw this is my main objection to your patch; it intertwines the
conf1 and mmconfig code even more.
There is nothing wrong with it; please realize
Adrian Bunk wrote:
All the other reports only contain the plain trace. Is there any way to
get more information whether the former is a pattern or not, and to
get this information somehow displayed on the webpage?
IF the kernel prints that its tainted or whatever it'll be shown, as well
as
that if the system crashes as a result of this action, the user
can know what action/tool caused it.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
Documentation/ABI/testing/sysfs-pci-extended-config | 39
arch/x86/pci
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Thanks, Arjan.
The problem we have been experiencing has to do with Northbridges,
not with devices.
correct for now.
HOWEVER, and this is the point Linus has made several times:
Just about NOBODY has devices that need
Subject: x86: Add the capability to print fuzzy backtraces
From: Arjan van de Ven <[EMAIL PROTECTED]>
For enhancing the 32 bit EBP based backtracer, I need the capability
for the backtracer to tell it's customer that an entry is either
reliable or unreliable, and the backtrace printin
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
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.
Thi
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
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 back
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 n
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 back
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
Hi,
this patch series improves the x86 backtracing code in the following ways:
1) Fix a bad bug in x86 (32 bit) FRAME_POINTER backtracing (2.6.24 material)
2) Add the capability to mark a backtrace entry as reliable / unreliable
3) Change the x86 (32 bit) FRAME_POINTER backtracing to use the
On Fri, 11 Jan 2008 11:41:40 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 10 Jan 2008, Arjan van de Ven wrote:
> >
> > What do you think of this approach instead of your proposal?
>
> Looks ok to me. I get the feeling
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> >
> > This patch also adds a sysfs property for each device into which
> > root can write a '1' to enable extended configur
On Fri, 11 Jan 2008 12:28:20 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
> > Can you send me a follow-on patch that documents this in
> > Documentation/ABI please.
>
> Greg, if you integrate Ivan's patch, you don't need Arjan's
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> >
> > This patch also adds a sysfs property for each device into which
> > root can write a '1' to enable extended configur
On Fri, 11 Jan 2008 09:02:46 -0800 (PST)
dean gaudet <[EMAIL PROTECTED]> wrote:
> > Bulk ops (string ops, etc.) will do full cacheline writes too,
> > without filling in the cacheline.
>
> on intel with fast strings enabled yes. mind you intel gives hints in
> the documentation these
On Fri, 11 Jan 2008 09:02:46 -0800 (PST)
dean gaudet [EMAIL PROTECTED] wrote:
Bulk ops (string ops, etc.) will do full cacheline writes too,
without filling in the cacheline.
on intel with fast strings enabled yes. mind you intel gives hints in
the documentation these operations don't
On Fri, 11 Jan 2008 11:41:40 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 10 Jan 2008, Arjan van de Ven wrote:
What do you think of this approach instead of your proposal?
Looks ok to me. I get the feeling that we *should* be able to make the
#ifdef
On Fri, 11 Jan 2008 12:28:20 -0700
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
Can you send me a follow-on patch that documents this in
Documentation/ABI please.
Greg, if you integrate Ivan's patch, you don't need Arjan's patch.
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH [EMAIL PROTECTED] wrote:
On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
This patch also adds a sysfs property for each device into which
root can write a '1' to enable extended configuration space. The
kernel will print
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH [EMAIL PROTECTED] wrote:
On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
This patch also adds a sysfs property for each device into which
root can write a '1' to enable extended configuration space. The
kernel will print
Hi,
this patch series improves the x86 backtracing code in the following ways:
1) Fix a bad bug in x86 (32 bit) FRAME_POINTER backtracing (2.6.24 material)
2) Add the capability to mark a backtrace entry as reliable / unreliable
3) Change the x86 (32 bit) FRAME_POINTER backtracing to use the
801 - 900 of 3577 matches
Mail list logo
