On Tue, 24 Jul 2007 17:19:17 -0500, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me
> that the following commit is to blame, and by reverting that commit, it
> works appropriately.
I have noted the same behavior on a Thinkpad 600X.
On the
On Thu, 26 Jul 2007 16:29:55 +0200, Rafael J. Wysocki wrote:
> OK, so here it goes again with a changelog:
>
> ---
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Generally, sysdev_shutdown() should be called after the ACPI preparation
> for powering the system off. To make it happen, we can
Small problem with kernel/power/tuxonice_checksum.c which causes
compilation to fail with wrong type for get_next_bit_on
--- tuxonice_checksum.c.orig2007-08-11 14:22:52.0 -0700
+++ tuxonice_checksum.c 2007-08-11 14:23:01.0 -0700
@@ -292,7 +292,7 @@
if (check)
look something like this:
some_device/
..features/
eq1/
..band1/
coefficient_a1
coefficient_a2
eq2/
3dbass/
3dtreb/
2. Do you see anything wrong with this approach?
Please CC me in your responses.
Regards,
Steven
):
blackfin: dmc: Improve DDR2 write through in DMC effict controller.
bf609: rsi: Add bf609 rsi MMR macro and board platform data.
blackfin: rename vmImage to uImage after we move to buildroot
Steven Miao (2):
blackfin: smp: fix smp build after drop asm/system.h
bfin cache: dcplb map
):
blackfin: dmc: Improve DDR2 write through in DMC effict controller.
bf609: rsi: Add bf609 rsi MMR macro and board platform data.
blackfin: rename vmImage to uImage after we move to buildroot
Steven Miao (2):
blackfin: smp: fix smp build after drop asm/system.h
bfin cache: dcplb
From: Steven Miao
mm could be removed from current task struct, using previous vma->vm_mm
It will crash on blackfin after updated to Linux 3.15. The commit "mm:
per-thread vma caching" caused the crash.
mm could be removed from current task struct before
mmput()->
On Tue, 2012-11-27 at 00:49 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from drivers/staging/sb105x/sb_pci_mp.c:1:0:
> drivers/staging/sb105x/sb_pci_mp.h:22:25: fatal error: asm
]
Sent: Saturday, November 17, 2012 3:10 PM
To: Kinney, Steven
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
Roedel, Joerg; bhelg...@google.com; sebast...@breakpoint.cc;
myron.st...@redhat.com; hd...@nvidia.com; swar...@wwwdotorg.org;
jkos...@suse.cz; kgene@samsung.com
and attach it before locking.
> > There is no way that the newly allocated bd could be on the ail list,
> > and thus no way for __gfs2_ail_flush() to detach it.
> >
> > Signed-off-by: Benjamin Marzinski
> > Signed-off-by: Steven Whitehouse
> > Signed-off-by:
On Mon, 2012-11-26 at 20:30 +0530, Viresh Kumar wrote:
> On 6 November 2012 16:08, Viresh Kumar wrote:
> > This is V2 Resend of my sched_select_cpu() work. Resend because didn't got
> > much
> > attention on V2. Including more guys now in cc :)
> >
> > In order to save power, it would be useful t
On Mon, 2012-11-26 at 09:03 -0800, Paul E. McKenney wrote:
> If I understand correctly (though also suffering turkey OD), the idea is
> to offload work to more energy-efficient CPUs.
This is determined by a CPU that isn't running the idle task? Is it
because a CPU that just woke up may be runnin
On Fri, 2012-11-23 at 15:21 +0100, Frederic Weisbecker wrote:
> We have thread_group_cputime() and thread_group_times(). The naming
> doesn't provide enough information about the difference between
> these two APIs.
>
> To lower the confusion, rename thread_group_times() to
> thread_group_cputime_
On Mon, 2012-11-26 at 11:03 -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2012 at 12:35:52PM -0500, Steven Rostedt wrote:
> > On Mon, 2012-11-26 at 09:03 -0800, Paul E. McKenney wrote:
> >
> >
> > > If I understand correctly (though also suffering turkey OD), the
On Mon, 2012-11-26 at 20:24 +0100, Frederic Weisbecker wrote:
> 2012/11/26 Steven Rostedt :
> > On Fri, 2012-11-23 at 15:21 +0100, Frederic Weisbecker wrote:
> >> We have thread_group_cputime() and thread_group_times(). The naming
> >> doesn't provide enough
From: "Steven L. Kinney"
Add Kernel configuration selection for AMD IOMMUv2 performance counters.
Add a check that will determine the configuration of the AMD IOMMUv2
performance counter(s) and extend the IOMMUv2 MMIO Region to account for the
additional PC register bank.
Add maxim
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
> Workqueues queues work on current cpu, if the caller haven't passed a
> preferred
> cpu. This may wake up an idle CPU, which is actually not required.
>
> This work can be processed by any CPU and so we must select a non-idle CPU
> here.
>
[ Added John Stultz ]
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
> Till now, we weren't migrating a running timer because with migration
> del_timer_sync() can't detect that the timer's handler yet has not finished.
>
> Now, when can we actually to reach to the code (inside __mod_time
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> On 27 November 2012 18:56, Steven Rostedt wrote:
> > A couple of things. The sched_select_cpu() is not cheap. It has a double
> > loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
> > and we are C
On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
> On 27 November 2012 14:59, Steven Rostedt wrote:
> > On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> >> On 27 November 2012 18:56, Steven Rostedt wrote:
> >> > A couple of things. The sched_selec
usage is to spot a specific device and inode (for example
> /lib/libc.so) to see the eviction cycles, and find out if frequently used
> code is rather spread across many pages (bad) or coallesced (good).
>
> Signed-off-by: Robert Jarzmik
> Cc: Dave Chinner
> Cc: Hugh Dickins
On Wed, 2012-11-28 at 00:51 +0100, Frederic Weisbecker wrote:
> To fix this we apply the above monotonicity fixup.
Thanks for the explanation, although I kind of figured it out
already ;-)
>
> I can add these explanations on comments in a new patch.
Comments are always good.
-- Steve
--
To
g is also going to be used to implement an "on
> > demand" generic virtual cputime accounting. A necessary step to
> > shutdown the tick while still accounting the cputime.
>
> I have queued this, and if it passes tests and inspection will try
> pushing it for 3.8.
>
Dear RT Folks,
I'm pleased to announce the 3.4.20-rt31 stable release.
This release is just an update to the new stable 3.4.20 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
Dear RT Folks,
I'm pleased to announce the 3.0.53-rt77 stable release.
This release is just an update to the new stable 3.0.53 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
On Fri, 2012-11-23 at 18:15 +0100, Lars Ellenberg wrote:
> When toying around with debugfs, intentionally trying to break things,
> I managed to get it into a reproducible endless loop when cleaning up.
>
> debugfs_remove_recursive() completely ignores that entries found
> on ->d_subdirs may alrea
On Fri, 2012-11-23 at 00:02 +0400, Kirill Tkhai wrote:
> Reschedule rq->curr if the first RT task has just been
> pulled to the rq.
>
> Signed-off-by: Kirill V Tkhai
> CC: Steven Rostedt
> CC: Ingo Molnar
> CC: Peter Zijlstra
> ---
> kernel/sched/rt.c |
On Wed, 2012-11-28 at 10:37 +0100, Lars Ellenberg wrote:
> On Tue, Nov 27, 2012 at 10:16:28PM -0500, Steven Rostedt wrote:
> > On Fri, 2012-11-23 at 18:15 +0100, Lars Ellenberg wrote:
> > > When toying around with debugfs, intentionally trying to break things,
> > >
Anton Vorontsov
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_stack.c |4
1 file changed, 4 deletions(-)
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index 0c1b1657..42ca822 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -33,7
Ingo,
This is based off of my last pull request on tip/perf/core.
Please pull the latest tip/perf/core-2 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/core-2
Head SHA1: bf3071f5a054db9e5bab873355d27a7330ce5187
Anton Vorontsov (1
From: Dave Jones
WARN shouldn't be used as a means of communicating failure to a userspace
programmer.
Link: http://lkml.kernel.org/r/20120725153908.ga25...@redhat.com
Signed-off-by: Dave Jones
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c |2 --
1 file changed, 2 dele
w function - resize_buffer_duplicate_size().
Link: http://lkml.kernel.org/r/20121017025616.2627.91226.stgit@falsita
Signed-off-by: Hiraku Toyooka
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c | 58 +++---
1 file changed, 31 insertions(+), 27 deletions(-)
di
On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:
> This header file will define a new trace event that will be triggered when
> a AER event occurs. The following data will be provided to the trace
> event.
>
> char * name - String containing the device path
>
> u32 status - Either the cor
On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:
> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
> @@ -23,6 +23,10 @@
>
> #include "aerdrv.h"
>
> +#define CREATE_TRACE_POINTS
> +#define TRACE_INCLUDE_PATH ../../../../include/ras
> +#include
On Fri, 2012-11-16 at 08:22 -0500, Steven Rostedt wrote:
> Ingo,
Ping?
-- Steve
>
> Please pull the latest tip/perf/urgent tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> tip/perf/urg
ff-by: Steven Whitehouse
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index e6c2fd5..e543871 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -55,8 +55,6 @@ struct gfs2_glock_iter {
typedef void (*glock_examiner) (struct gfs2_glock * gl);
-static int __dump_glock(struct seq_file *seq,
From: Bob Peterson
[Editorial: This is a nit, but has been a minor irritation for a long time:]
This patch renames glops structure item for go_xmote_th to go_sync.
The functionality is unchanged; it's just for readability.
Signed-off-by: Bob Peterson
Signed-off-by: Steven Whitehouse
From: David Teigland
Save the effort of allocating, reading and writing
the lvb for most glocks that do not use it.
Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 9d29a51..2284de4 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2
From: Bob Peterson
This patch adds a return code check after attempting to allocate
a new inode during dinode creation.
Signed-off-by: Bob Peterson
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index e321333..2405695 100644
--- a/fs/gfs2/inode.c
+++ b/fs
ned-off-by: Steven Whitehouse
diff --git a/fs/gfs2/trace_gfs2.h b/fs/gfs2/trace_gfs2.h
index bbdc78a..2ee13e8 100644
--- a/fs/gfs2/trace_gfs2.h
+++ b/fs/gfs2/trace_gfs2.h
@@ -486,7 +486,7 @@ TRACE_EVENT(gfs2_block_alloc,
),
TP_fast_assign(
- __entry->dev
wasn't set. Later, the flush daemon noticed the uncommitted data
and tried to flush it, only to discover the glock was no longer locked
properly in exclusive mode. That caused an assert withdraw.
Signed-off-by: Bob Peterson
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/inode.c b/
this case, dlm_unlock is called because it may update the
lvb of the resource.
Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 6114571..9d29a51 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1526,6 +1526,7 @@ static
From: David Teigland
The lksb struct already contains a pointer to the lvb,
so another directly from the glock struct is not needed.
Signed-off-by: David Teigland
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 2284de4..274b6be 100644
--- a/fs/gfs2
From: Bob Peterson
Since we now have a dirty_inode that takes care of manipulating the
inode buffer and writing from the inode to the buffer, we can
eliminate some unnecessary buffer manipulations in gfs2_unlink_inode
that are now redundant.
Signed-off-by: Bob Peterson
Signed-off-by: Steven
Hi,
So yes, this is a bit early, but the tree seems to have settled down
now, and I'd like to hold off any further feature patches until the
subsequent merge window at this stage.
The main feature this time is the new Orlov allocator and the patches
leading up to it which allow us to allocate new
the parent directory's context. This give us a
lot more flexibility in where the inode is placed on disk.
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 381893c..749b05a 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -364,34 +364,34 @@ static int c
From: Bob Peterson
This patch changes the gfs2_dir_add function so that it uses
the dirty_inode function (via mark_inode_dirty) rather than manually
updating the dinode.
Signed-off-by: Bob Peterson
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index 259b088
For filesystems with only a single resource group, we need to be careful
that the allocation loop will not land up with a NULL resource group. This
fixes a bug in a previous patch where the gfs2_rgrpd_get_next() function
was being used instead of gfs2_rgrpd_get_first()
Signed-off-by: Steven
This patch fixes an issue relating to not having enough revokes
available when truncating journaled data files. In order to ensure
that we do no run out, the truncation is broken into separate pieces
if it is large enough.
Tested using fsx on a journaled data file.
Signed-off-by: Steven
, each of which will contain a
job running on a different node, then by setting +T on the parent
directory before creating the subdirectories, each will land up in a
different resource group, and thus resource group contention between
nodes will be kept to a minimum.
Signed-off-by: Steven Whitehouse
groups too often.
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 669b89b..bdf3e64 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1681,6 +1681,88 @@ static void try_rgrp_unlink(struct gfs2_rgrpd *rgd, u64
*last_unlinked, u64 skip
return
Mixed with transactions: 49913 files (94 per second)
Data:
273.42 megabytes read (467.42 kilobytes per second)
852.13 megabytes written (1.42 megabytes per second)
Signed-off-by: Bob Peterson
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
ind
On Sun, 2013-03-17 at 19:28 +0100, Oleg Nesterov wrote:
> syscall_regfunc() ignores the kernel thread because "it has
> no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
>
> However, this means that a user-space task spawned by
> call_usermodehelper() won't report the system calls if
On Sun, 2013-03-17 at 20:00 +0100, Oleg Nesterov wrote:
> On 03/17, Steven Rostedt wrote:
> >
> > On Sun, 2013-03-17 at 19:28 +0100, Oleg Nesterov wrote:
> > > syscall_regfunc() and syscall_unregfunc() should set/clear
> > > TIF_SYSCALL_TRACEPOINT system-wi
On Sun, 2013-03-17 at 20:04 +0100, Oleg Nesterov wrote:
> > I'm really thinking the TIF_SYSCALL_TRACEPOINT flag is getting a bit
> > ridiculous. We really should have a "swap syscall table when tracepoints
> > enabled" that changes the syscall table that does exactly the same thing
> > as the norm
On Mon, 2013-03-18 at 17:22 +0900, Namhyung Kim wrote:
> > + " example: echo do_fault:traceoff > set_ftrace_filter\n"
> > + " echo do_trap:traceoff:3 > set_ftrace_filter\n"
> > + " The first one will disable tracing everytime do_fault is
> > hit\
On Mon, 2013-03-18 at 18:03 +0900, Keun-O Park wrote:
> >> +#endif
> >> +#ifdef CONFIG_TRACER_SNAPSHOT
> >> + "\n snashot\t\t- Like 'trace' but shows the content of the static
> >> snapshot buffer\n"
> >> + "\t\t\t Read the contents for more infromation\n"
> >> +#endif
>
> There're two
On Mon, 2013-03-18 at 13:00 +1100, Stephen Rothwell wrote:
> Hi Steven,
>
> Today's linux-next merge of the ftrace tree got a conflict in
> kernel/trace/ftrace.c between commit b67bfe0d42ca ("hlist: drop the node
> parameter from iterators") from Linus' tree
Hi Tejun,
I'm debugging a crash on -rt that has the following:
kernel BUG at kernel/sched/core.c:1731!
invalid opcode: [#1] PREEMPT SMP
CPU 5
Pid: 16637, comm: kworker/5:0 Not tainted 3.6.11-rt30.25.el6rt.x86_64 #1 HP
ProLiant DL580 G7
RIP: 0010:[] [] __schedule+0x89a/0x8c0
RSP: 0018:fff
On Mon, 2013-03-18 at 09:06 -0700, Tejun Heo wrote:
> Hello, Steven.
>
> On Mon, Mar 18, 2013 at 10:36:23AM -0400, Steven Rostedt wrote:
> > kernel BUG at kernel/sched/core.c:1731!
> > invalid opcode: [#1] PREEMPT SMP
> > CPU 5
> > Pid: 16637, comm: kwork
On Mon, 2013-03-18 at 12:23 -0400, Steven Rostedt wrote:
> > Maybe I'm confused but I can't really see how the above would be a
> > problem to workqueue in itself. Both rq->lock and gcwq->lock are
> > irq-safe, so spin_lock() not disabling preemption shouldn&#x
On Mon, 2013-03-18 at 12:27 -0400, Steven Rostedt wrote:
> IOW, what can happen in -rt here is:
>
> spin_lock_irq(&gcwq->lock);
> [...]
>
> -> preempt_schedule();
> schedule();
>
On Mon, 2013-03-18 at 09:27 -0700, Tejun Heo wrote:
> Does that mean that a task holding gcwq->lock may be preempted? If
> so, that sure could lead to weird problems. Maybe gcwq->lock should
> be marked non-preemptible somehow?
If the gcwq->lock is never held for a long time (really, more than
On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote:
> Making gcwq locks disable preemption would be much safer / easier, but
> if that's not desirable, anything touching gcwq->idle_list would be a
> good place to start - worker_enter_idle() and worker_leave_idle().
> Hmmm... ignoring CPU hotplug,
On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote:
> Hello, Steven.
>
> On Mon, Mar 18, 2013 at 12:30:43PM -0400, Steven Rostedt wrote:
> > If you happen to know the critical areas that require preemption to be
> > disabled for real, we can encapsulate them with:
> >
On Mon, 2013-03-18 at 11:26 -0700, Tejun Heo wrote:
> > Hmm, the issue is that a "use to be" idle thread got migrated, and is
> > now being woken up by another worker. What can cause an established
> > worker to migrate without HOTPLUG being active?
>
> It doesn't. I think it's trying to wakeup
On Mon, 2013-03-18 at 11:21 -0700, Tejun Heo wrote:
> I've been thinking about it and AFAICS the only way that BUG_ON()
> could trigger from preemption is if preemption happens while the
> idle_list head is becoming or stopping being empty.
> ie. pool->worklist is half updated so list_empty() isn'
aking up new workers.
Signed-off-by: Steven Rostedt
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ff34113..b25bfec 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3630,8 +3630,10 @@ need_resched:
* If a worker went to sleep, notify and ask w
On Mon, 2013-03-18 at 12:06 -0700, Tejun Heo wrote:
> Me neither. Unfortunately, I'm out of ideas at the moment.
> Hmm... last year, there was a similar issue, I think it was in AMD
> cpufreq, which was caused by work function doing
> set_cpus_allowed_ptr(), so the idle worker was on the correct
to be finite either by another work item being
> queued or the one blocked getting unblocked. There's no reason to
> trigger BUG while holding rq lock crashing the whole system.
>
> Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.
>
> Signed-off-by: Tejun H
On Tue, 2013-03-19 at 11:14 +0100, Peter Zijlstra wrote:
> On Mon, 2013-03-18 at 12:22 -0700, Tejun Heo wrote:
> > try_to_wake_up_local() should only be invoked to wake up another task
> > in the same runqueue and BUG_ON()s are used to enforce the rule.
> > Missing try_to_wake_up_local() can stall
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> From: Namhyung Kim
>
> So that it can be used by other places.
>
> Cc: Steven Rostedt
> Cc: Frederic Weisbecker
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/trace-event-info.c | 25
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> struct tracing_data *tracing_data_get(struct list_head *pattrs,
> @@ -465,6 +516,7 @@ struct tracing_data *tracing_data_get(struct list_head
> *pattrs,
> {
> struct tracepoint_path *tps;
> struct tracing_data *tdata;
> + i
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> @@ -3100,7 +3105,7 @@ int perf_event__process_tracing_data(union perf_event
> *event,
> }
> }
>
> - if (size_read + padding != size) {
> + if (size_read + padding != size || session->pevent == NULL) {
>
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> free(version);
> @@ -331,11 +354,12 @@ ssize_t trace_report(int fd, struct pevent **ppevent,
> bool __repipe)
>
> page_size = read4(pevent);
>
> - read_header_files(pevent);
> - read_ftrace_files(pevent);
> - read
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Rename it to do_read and original do_read to __do_read, and check
> their return value.
>
> Cc: Steven Rostedt
> Cc: Frederic Weisbecker
> Signed-off-by: Namhyung Kim
> ---
> tool
On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Convert them to pr_debug() and propagate error code.
Shouldn't they be pr_err(). I mean, if the old code would kill the
process, why just keep it as a debug output?
-- Steve
>
> Cc: Steven Ros
On Tue, 2013-03-19 at 15:49 +0100, Peter Zijlstra wrote:
> On Tue, 2013-03-19 at 10:35 -0400, Steven Rostedt wrote:
> > What about:
> > int err = 0;
> >
> > err += tracing_data_header();
> > err += read_header_files();
> >
On Tue, 2013-03-19 at 15:10 +, David Howells wrote:
> Steven Rostedt wrote:
>
> > Why? If we remove the tracepoint from the slowpath and use a table swap,
> > then we wouldn't need to use the slowpath at all.
>
> How are you engineering a table swap? Do you
Thomas,
Merging 3.4.34 into stable 3.4-rt I hit the following conflict:
diff --cc kernel/hrtimer.c
index 9114899,cdd5607..000
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@@ -643,30 -640,9 +643,33 @@@ static inline void hrtimer_init_hres(st
* and expiry check is done in the hrtimer_inter
On Wed, 2013-03-20 at 10:12 +0900, Namhyung Kim wrote:
> >> +++ b/tools/perf/util/trace-event-read.c
> >> @@ -293,7 +293,10 @@ ssize_t trace_report(int fd, struct pevent **ppevent,
> >> bool __repipe)
> >>int show_version = 0;
> >>int show_funcs = 0;
> >>int show_printk = 0;
> >> - s
On Wed, 2013-03-20 at 10:14 +0900, Namhyung Kim wrote:
> On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
> > On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> >>free(version);
> >> @@ -331,11 +354,12 @@ ssize_t trace_report(int fd, struct pevent
&g
On Wed, 2013-03-20 at 10:24 +0900, Namhyung Kim wrote:
> >> @@ -61,8 +61,10 @@ static int do_read(int fd, void *buf, int size)
> >>if (repipe) {
> >>int retw = write(STDOUT_FILENO, buf, ret);
> >>
> >> - if (retw <= 0 || retw != ret)
> >> -
On Wed, 2013-03-20 at 12:00 +0900, Namhyung Kim wrote:
> On Tue, 19 Mar 2013 21:55:02 -0400, Steven Rostedt wrote:
> > On Wed, 2013-03-20 at 10:14 +0900, Namhyung Kim wrote:
> >> On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
> >> > On Tue, 2013-03-19 at 1
On Wed, 2013-03-20 at 12:18 +0900, kpark3...@gmail.com wrote:
> From: Sahara
>
> Somehow tracepoint_entry_add/remove_probe functions allow a null probe
> function.
You actually hit this in practice, or is this just something that you
observe from code review?
> Especially on getting a null pro
ange syscall_unregfunc() to check PF_KTHREAD to skip
> the kernel threads, ->mm != NULL is the common mistake.
>
> Note: probably this check should be simply removed, needs
> another patch.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Steven Rostedt
-- Steve
On Wed, 2013-03-20 at 14:01 -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 2013-03-20 at 12:18 +0900, kpark3...@gmail.com wrote:
> > > From: Sahara
> > >
> > > Somehow tracepoint_entry_add/remove_probe functio
On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
>
>
> NO_HZ: Reducing Scheduling-Clock Ticks
>
>
> This document covers Kconfig options and boot parameters used to reduce
> the number of scheduling
[ Added Arjan in case he as anything to add about the idle=poll below ]
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
> On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
> > On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKen
trivial tree.
Sure, it can go that path.
Acked-by: Steven Rostedt
-- Steve
>
> Documentation/trace/tracepoints.txt | 15 ---
> 1 file changed, 15 deletions(-)
>
> diff --git a/Documentation/trace/tracepoints.txt
> b/Documentation/trace/tracepoints.t
trace\t\t- Shows the max stack trace when active\n"
And here's the real patch:
tracing: Update debugfs README file
Update the README file in debugfs/tracing to something more useful.
What's currently in the file is very old and what it shows doesn'
On Sat, 2 Feb 2013, 20:18:28 GMT, Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 11:58:41 AM Steven Newbury wrote:
> > On Sat, 2013-01-26 at 15:19 -0800, Yinghai Lu wrote:
> > > On Sat, Jan 26, 2013 at 2:41 PM, Rafael J. Wysocki
> > > wrote:
>
On Sat, 2013-02-02 at 23:27 +0100, Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 08:28:01 PM Steven Newbury wrote:
> > > > Tried merging with linux-pm/bleeding-edge, same behaviour:
> > > >
> > > > [ 3589.013578] ACPI: \_SB_.PCI0.PCIE.GDCK:
The rcu torture test uses trace_clock, and requires that it be built
into the kernel. If it is not, then we get the following build error:
ERROR: "trace_clock_local" [kernel/rcutorture.ko] undefined!
Reported-by: Tetsuo Handa
Signed-off-by: Steven Rostedt
diff --git a/lib/Kconfig.d
On Mon, 2013-02-04 at 21:56 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov [2013-02-04 16:18:50]:
>
> > On 02/04, Srikar Dronamraju wrote:
> > >
> > > * Oleg Nesterov [2013-01-31 20:18:32]:
> > >
> > > > Move tu->nhit++ from uprobe_trace_func() to uprobe_dispatcher().
> > > >
> > > > ->nhit c
On Mon, 2013-02-04 at 08:59 -0800, Paul E. McKenney wrote:
> On Mon, Feb 04, 2013 at 10:52:21AM -0500, Steven Rostedt wrote:
> > The rcu torture test uses trace_clock, and requires that it be built
> > into the kernel. If it is not, then we get the following build error:
On Mon, 2013-02-04 at 17:20 -0800, Andrew Morton wrote:
> On Tue, 5 Feb 2013 01:51:18 +0100
> Frederic Weisbecker wrote:
>
> > printk: Wake up klogd using irq_work
>
> That seems reasonable.
>
> I'm wondering if we can now remove the printk_sched() special-case.
> iirc, that was needed
On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> I don't think so. Conceptually printk() should be "inner" to the
> scheduler and shouldn't call into sched things at all. The (afaik
> sole) exception to that was the klogd wakeup.
>
> Traditionally the deadlock happened when calling pri
On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> Maybe there were other deadlock scenarios, dunno. That knowledge
> appears to be disappearing into the mists of time :(
Discussing this on IRC with Frederic, he brought up that the
up(&console_sem) can do a wake_up as well. I guess that's
On Tue, 2013-02-05 at 04:19 +0100, Frederic Weisbecker wrote:
> 2013/2/5 Steven Rostedt :
> > On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> >
> >> Maybe there were other deadlock scenarios, dunno. That knowledge
> >> appears to be di
1 - 100 of 21370 matches
Mail list logo
