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
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
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
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 and commit e1df4cb682ab
> ("ftrace: Fix
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
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'
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
On Mon, 2013-02-04 at 22:24 -0500, Steven Rostedt wrote:
> The reason to avoid the wake up of klogd() is that it also grabs the
> wait queue spinlock every time it's called. up() is fast when there's no
> waiters, but wake_up_interruptible() is not so fast.
I take that back. S
Ping?
-- Steve
On Thu, 2013-01-17 at 12:13 -0500, Steven Rostedt wrote:
> [ Sorry for the duplicate email, it's linux...@kvack.org not
> linux...@vger.kernel.org ]
>
> While doing some code inspection, I noticed that the slob constructor
> method can be called with a NUL
On Tue, 2013-02-05 at 06:11 -0800, Paul E. McKenney wrote:
> Steven Rostedt (1):
> rcu: Allow rcutorture to be built at low optimization levels
>
I wish git had dual (or more) authorship, as I started with your patch
and added on to it. We are really both responsible for th
(&console_sem) may do a wake up of any pending waiters. This must be
avoided while holding the logbuf_lock.
Luckily, there's not many places that do the unlock, or hold the
logbuf_lock. By moving things around a little, the console_sem can be
released without ever holding the logbuf_lock,
lock.
Luckily, there's not many places that do the unlock, or hold the
logbuf_lock. By moving things around a little, the console_sem can be
released without ever holding the logbuf_lock, and we can safely have
printk_sched() use the printk buffer directly.
Signed-off-by: Steven Rostedt
diff --gi
On Tue, 2013-02-05 at 14:28 -0800, John Stultz wrote:
> I prefer the ioctl method, since its less likely to be re-purposed/misused.
>
> Though I'd be most comfortable with finding some way for perf-timestamps
> to be CLOCK_MONOTONIC based (or maybe CLOCK_MONOTONIC_RAW if it would be
> easier), a
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
> I'm debugging something that could be my own bug in my wanlink module (but
> then
> again, haven't seen this on 3.5 kernels, and my module is
> basically un-changed since then).
>
> I'm using lockdep, and keep seeing "BUG: MAX_LOCK_DEP
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
> Well, here it is..something is calling rcu_read_lock lots and lots,
Or a bug in the way lockdep handles rcu mappings.
> it seems. Any way to get a better idea of where those calls are
> made?
Yeah, with ftrace.
> 96 locks held by swapper/0
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
>
>
> ===
> [ INFO: suspicious RCU usage. ]
> 3.7.6+ #4 Tainted: G C O
> ---
> /home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360 Illegal idle entry in
> RCU read-side
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:
> It's huge, so here's a link:
>
> http://www.candelatech.com/~greearb/debug.tgz
>
The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see any possible way
that can be true in the code
On Tue, 2013-02-05 at 22:23 -0800, Ben Greear wrote:
> On 02/05/2013 08:36 PM, Steven Rostedt wrote:
> > On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:
> >
> >> It's huge, so here's a link:
> >>
> >> http://www.candelatech.com/
On Wed, 2013-02-06 at 07:56 -0800, Ben Greear wrote:
> > I'm 99% sure that the bug is in your modifications.
>
> I'm sorry, I tried to make that clear.
You said it was an out of tree module, I didn't realize it had changes
to the core Linux as well.
> My tree is here, minus a few debugging pat
On Wed, 2013-02-06 at 17:39 +0100, Ingo Molnar wrote:
> * Steven Rostedt wrote:
> Wondering whether we could improve lockdep to detect 'excessive'
> lock nesting and treat it as a bug - the 'ran out of lockdep
> entries' assert might be too detached and it m
On Wed, 2013-02-06 at 08:58 -0800, Ben Greear wrote:
> > One of many. All those "goto out;"s skip the rcu_read_unlock().
>
> Thank you so much!
You're welcome ;-)
>
> I'll fix this and continue testing...
>
> I can also post a patch to print the held locks when
> the max-lock-depth overflows
Dear RT Folks,
I'm pleased to announce the 3.4.29-rt41 stable release.
This release is just an update to the new stable 3.4.29 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.2.38-rt56 stable release.
This release is just an update to the new stable 3.2.38 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.62-rt87 stable release.
This release is just an update to the new stable 3.0.62 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
From: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/sched/core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index fec5603..e979551 100644
--- a/kernel/sched/core.c
From: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
mm/swap.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index 2051da9..62dc70c 100644
--- a/mm/swap.c
+++ b/mm/swap.c
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 629e0b4..31c892a 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt41
+-rt42-rc1
--
1.7.10.4
--
To unsubscribe from this
/kernel/projects/rt/3.4/incr/patch-3.4.29-rt41-rt42-rc1.patch.xz
Changes from 3.4.29-rt41:
---
Steven Rostedt (1):
Linux 3.4.29-rt42-rc1
Thomas Gleixner (5):
drivers-tty-pl011-irq-disable-madness.patch
mmci: Remove bogus local_irq_save()
sched: Init idle->on_rq
From: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
drivers/tty/serial/amba-pl011.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba
From: Thomas Gleixner
Idle is not allowed to call sleeping functions ever!
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/sched/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel
From: Thomas Gleixner
On !RT interrupt runs with interrupts disabled. On RT it's in a
thread, so no need to disable interrupts at all.
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
drivers/mmc/host/mmci.c |5 -
1 file chang
/kernel/projects/rt/3.2/incr/patch-3.2.38-rt56-rt57-rc1.patch.xz
Changes from 3.2.38-rt56:
---
Steven Rostedt (1):
Linux 3.2.38-rt57-rc1
Thomas Gleixner (5):
drivers-tty-pl011-irq-disable-madness.patch
mmci: Remove bogus local_irq_save()
sched: Init idle->on_rq
From: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
drivers/tty/serial/amba-pl011.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba
From: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/sched.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched.c b/kernel/sched.c
index b318b4a..20b228f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index fdb0f88..c12fc9d 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt56
+-rt57-rc1
--
1.7.10.4
--
To unsubscribe from this
From: Thomas Gleixner
On !RT interrupt runs with interrupts disabled. On RT it's in a
thread, so no need to disable interrupts at all.
Cc: stable...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
drivers/mmc/host/mmci.c |5 -
1 file chang
1 - 100 of 19470 matches
Mail list logo