On Wed, 28 Nov 2012, Joseph Salisbury wrote:
> On 11/23/2012 08:11 AM, Norbert Warmuth wrote:
> > Thomas Gleixner writes:
> > > On Wed, 21 Nov 2012, Norbert Warmuth wrote:
> > > > 3.7-rc6 booted with nmi_watchdog=0 fails to suspend to RAM or
> > > > offlin
On Wed, 28 Nov 2012, Frank Rowand wrote:
> 3.6.7-rt18: kernel BUG at .../kernel/sched/core.c:3817!
>
> Grant reported this same problem for 3.6.5-rt15.
>
> I am seeing it on a different arm board.
>
> Here is the BUG_ON():
>
>asmlinkage void __sched preempt_schedule_irq(void)
>{
>
On Sun, 3 Feb 2013, Izik Eidus wrote:
> Hi,
>
> it seems like hrtimer_enqueue_reprogram contain a race which could result in
> timer.base switch during unlock/lock sequence.
>
> See the code at __hrtimer_start_range_ns where it calls
> hrtimer_enqueue_reprogram. The later is releasing lock prote
On Fri, 25 Jan 2013, Paul Gortmaker wrote:
> From: Thomas Gleixner
>
> There is no real reason to use a rwlock for devtree_lock. It even
> could be a mutex, but unfortunately it's locked from cpu hotplug
> paths which can't schedule :(
>
> So it needs to become
Dear RT Folks,
I'm pleased to announce the 3.6.11-rt26 release.
Changes since 3.6.11-rt25:
1) Fix the RT highmem implementation on x86
2) Support highmem + RT on ARM
3) Fix an one off error in the generic highmem code (upstream fix
did not make it into 3.6.stable)
4) Upstrea
On Mon, 4 Feb 2013, Thomas Gleixner wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.6.11-rt26 release.
>
> Changes since 3.6.11-rt25:
Forgot to mention the change from EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
for pagefault_dis/enable. I really hate it, but it break
On Mon, 4 Feb 2013, Clark Williams wrote:
> More changes; I was running into a collision with the name kmap_prot.
Bah. I knew that I should have decided that today is still part of the
weekend.
Pushed out rt27 with the fixed merged back. Sorry for the noise.
Thanks,
tglx
--
To unsubscri
On Tue, 5 Feb 2013, Qiang Huang wrote:
> On 2013/2/4 22:58, Thomas Gleixner wrote:
> >From patches-3.6.11-rt28.patch.gz, your patch x86-highmem-make-it-work.patch
> did this work. And you said
> "It had been enabled quite some time, but never really worked."
>
>
On Mon, 4 Feb 2013, Leonid Shatz wrote:
> I assume the race can also happen between hrtimer cancel and start. In both
> cases timer base switch can happen.
>
> Izik, please check if you can arrange the patch in the standard format (do
> we need to do it against latest kernel version?)
Yes please
On Mon, 4 Feb 2013, Izik Eidus wrote:
> From: leonid Shatz
>
> it seems like hrtimer_enqueue_reprogram contain a race which could result in
> timer.base switch during unlock/lock sequence.
>
> See the code at __hrtimer_start_range_ns where it calls
> hrtimer_enqueue_reprogram. The later is rele
On Tue, 5 Feb 2013, Stanislaw Gruszka wrote:
> On Mon, Feb 04, 2013 at 08:32:23PM +0100, Oleg Nesterov wrote:
> > On 02/01, Thomas Gleixner wrote:
> > >
> > > B1;2601;0cOn Fri, 1 Feb 2013, Tommi Rantala wrote:
> > >
> > > > Hello,
> >
Leonid,
On Tue, 5 Feb 2013, Leonid Shatz wrote:
Please stop top posting!
> The explanation were submitted as possible scenario which could explain how
> the bug in kernel could happen and it does not mean that serious designer
> could do exactly that. As I said before, it's also possible that a
> # detach_timer( ): __list_del( )
>
> ld r4,[r13,4] # .entry.prev, D.31439
> st r4,[r3,4] # .prev, D.31439
> st r3,[r4]# .next, D.30246
>
> Signed-off-by: Vineet Gupta
> Reported-by: Christian Ruppert
> Cc: Thomas Gleixner
> Cc:
the
issue.
Reported-by: Siegfried Wulsch
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
Index: linux-stable/kernel/sched/clock.c
===
--- linux.orig/kernel/sched/clock.c
+++ linux/kernel/sched/clock.c
@@ -176,10 +176,3
Split out into separate functions, so we can convert it to a state machine.
Signed-off-by: Thomas Gleixner
---
kernel/cpu.c | 69 ---
1 file changed, 47 insertions(+), 22 deletions(-)
Index: linux-2.6/kernel/cpu.c
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online cpus.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_amd_ibs.c | 54 +++
include/linux/cpuhotplug.h |1
2 files changed, 21
From: Richard Weinberger
Signed-off-by: Richard Weinberger
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |7 +
kernel/cpu.c |4 +++
kernel/relay.c | 59 ++---
3 files changed, 25 insertions(+), 45
From: Richard Weinberger
Signed-off-by: Richard Weinberger
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h | 15 ++
kernel/cpu.c |8 +++
mm/slab.c | 102 ++---
3 files changed, 64 insertions(+), 61
.
Signed-off-by: Thomas Gleixner
---
kernel/cpu.c | 66 ---
1 file changed, 27 insertions(+), 39 deletions(-)
Index: linux-2.6/kernel/cpu.c
===
--- linux-2.6.orig/kernel/cpu.c
Straight forward replacement.
Signed-off-by: Thomas Gleixner
---
drivers/clocksource/arm_generic.c | 40 +++---
include/linux/cpuhotplug.h|1
2 files changed, 13 insertions(+), 28 deletions(-)
Index: linux-2.6/drivers/clocksource/arm_generic.c
Straight forward conversion to state machine callbacks w/o fixing the
obvious brokeness of the asymetric state invocations.
Signed-off-by: Thomas Gleixner
---
drivers/cpufreq/cpufreq_stats.c | 55 +---
include/linux/cpuhotplug.h |2 +
2 files
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |1 +
virt/kvm/kvm_main.c| 42 --
2 files changed, 17 insertions(+), 26 deletions(-)
Index: linux-2.6/include/linux/cpuhotplug.h
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tboot.c| 23 +++
include/linux/cpuhotplug.h |1 +
2 files changed, 8 insertions(+), 16 deletions(-)
Index: linux-2.6/arch/x86/kernel/tboot.c
From: Richard Weinberger
Signed-off-by: Richard Weinberger
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |5
kernel/cpu.c |4 +++
kernel/smp.c | 50 -
3 files changed, 27 insertions(+), 32
one
Add a create callback function as well.
Signed-off-by: Thomas Gleixner
---
include/linux/smpboot.h |5 +
kernel/smpboot.c|5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
Index: linux-2.6/include/linux
Replace the perf_notifier() install mechanism, which invokes magically
the callback on the current cpu. Convert the hardware specific
callbacks which are invoked from the x86 perf core to return proper
error codes instead of totally pointless NOTIFY_BAD return values.
Signed-off-by: Thomas
From: Richard Weinberger
Signed-off-by: Richard Weinberger
---
include/linux/cpuhotplug.h | 12 +
kernel/cpu.c |8 +++
kernel/profile.c | 92 +
3 files changed, 63 insertions(+), 49 deletions(-)
Index: linux-2.6/in
From: Richard Weinberger
Signed-off-by: Richard Weinberger
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/x2apic_cluster.c | 80 --
include/linux/cpuhotplug.h|1
2 files changed, 31 insertions(+), 50 deletions(-)
Index: linux-2.6
From: Richard Weinberger
Signed-off-by: Richard Weinberger
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |4
kernel/cpu.c |4
kernel/timer.c | 43 +--
3 files changed, 13 insertions(+), 38
All users gone.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|6 --
include/linux/cpuhotplug.h |1 -
kernel/cpu.c | 11 ---
3 files changed, 18 deletions(-)
Index: linux-2.6/include/linux/cpu.h
Split out the clockevents callbacks instead of piggypacking them on
hrtimers.
This gets rid of a POST_DEAD user. See commit 54e88fad. We just move
the callback state to the proper place in the state machine.
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h | 18
Do we really need so many states here ?
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h | 18
kernel/cpu.c | 12 +
kernel/rcutree.c | 95 -
3 files changed, 73 insertions(+), 52 deletions
Use the smpboot thread infrastructure. Mark the stopper thread
selfparking and park it after it has finished the take_cpu_down()
work.
Signed-off-by: Thomas Gleixner
---
kernel/cpu.c |2
kernel/stop_machine.c | 134 ++
2 files
No point calling this from the dying cpu.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/perf_event_intel_uncore.c
original code did not check the return values of the setup
functions and I could not be bothered to twist my brain around undoing
the previous steps. Marked with a FIXME.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 109 ++
include/linux
Straight forward conversion which leaves the question whether this
couldn't be combined with already existing infrastructure in the
scheduler instead of having an extra state.
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |6 ++
kernel/cpu.c |
Signed-off-by: Thomas Gleixner
---
arch/s390/kernel/vtime.c | 18 +-
include/linux/cpuhotplug.h |1 +
2 files changed, 6 insertions(+), 13 deletions(-)
Index: linux-2.6/arch/s390/kernel/vtime.c
===
--- linux
All users converted to state machine.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|6 --
include/linux/cpuhotplug.h |1 -
kernel/cpu.c | 13 +
3 files changed, 1 insertion(+), 19 deletions(-)
Index: linux-2.6/include/linux/cpu.h
Straight forward conversion w/o bells and whistles.
Signed-off-by: Thomas Gleixner
---
arch/arm/kernel/perf_event_cpu.c | 28 +---
include/linux/cpuhotplug.h |1 +
2 files changed, 6 insertions(+), 23 deletions(-)
Index: linux-2.6/arch/arm/kernel
Straight forward conversion plus commentry why code which is executed
in hotplug callbacks needs to be invoked before installing them.
Signed-off-by: Thomas Gleixner
---
arch/arm/vfp/vfpmodule.c | 29 +
include/linux/cpuhotplug.h |1 +
2 files changed, 18
for
this state for (or on) all cpus which have a hotplug state >= the
installed state.
For both setup and remove helper functions are provided, which prevent
the core to issue the callbacks. This simplifies the conversion of
existing hotplug notifiers.
Signed-off-by: Thomas Gleixner
---
include
Get rid of the prio ordering of the separate notifiers and use a
proper state callback pair.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|8
include/linux/cpuhotplug.h |7 +++
kernel/cpu.c |8
kernel/workqueue.c | 80
It's not clear why the ordering needs to be this way, but for the time
being we just keep the current working state. Want's to be revisited.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|2
include/linux/cpuhotplug.h | 12 +
kernel/cpu.c
All users converted to state machine callbacks.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|2 --
include/linux/perf_event.h | 21 -
2 files changed, 23 deletions(-)
Index: linux-2.6/include/linux/cpu.h
To allow the stopper thread being managed by the smpboot thread
infrastructure separate out the task storage from the stopper data
structure.
Signed-off-by: Thomas Gleixner
---
kernel/stop_machine.c | 32
1 file changed, 16 insertions(+), 16 deletions
Signed-off-by: Thomas Gleixner
---
arch/sh/kernel/perf_event.c | 22 +++---
include/linux/cpuhotplug.h |1 +
2 files changed, 4 insertions(+), 19 deletions(-)
Index: linux-2.6/arch/sh/kernel/perf_event.c
Signed-off-by: Thomas Gleixner
---
arch/s390/kernel/perf_cpum_cf.c | 37 +++--
include/linux/cpuhotplug.h |1 +
2 files changed, 16 insertions(+), 22 deletions(-)
Index: linux-2.6/arch/s390/kernel/perf_cpum_cf.c
Signed-off-by: Thomas Gleixner
---
arch/powerpc/perf/core-book3s.c | 29 ++---
include/linux/cpuhotplug.h |1 +
2 files changed, 7 insertions(+), 23 deletions(-)
Index: linux-2.6/arch/powerpc/perf/core-book3s.c
Signed-off-by: Thomas Gleixner
---
arch/blackfin/kernel/perf_event.c | 25 -
include/linux/cpuhotplug.h|1 +
2 files changed, 5 insertions(+), 21 deletions(-)
Index: linux-2.6/arch/blackfin/kernel/perf_event.c
them in, but that needs a larger surgery to the scheduler code
and is beyond the scope of this patch.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h| 16
include/linux/cpuhotplug.h |6 +
kernel/cpu.c |4 +
kernel/sched/core.c|
Actually a nice symetric startup/teardown pair which fits proper in
the state machine concept. In the long run we should be able to invoke
the startup callback for the boot cpu via the state machine and get
rid of the init function which invokes it on the boot cpu.
Signed-off-by: Thomas Gleixner
implementations of the synchronizations to the
core.
Signed-off-by: Thomas Gleixner
---
include/linux/cpuhotplug.h |4 ++
kernel/cpu.c | 70 +++--
2 files changed, 59 insertions(+), 15 deletions(-)
Index: linux-2.6/include/linux
Move the split out steps into a callback array and let the cpu_up/down
code iterate through the array functions. For now most of the
callbacks are asymetric to resemble the current hotplug maze.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h|4 +
include/linux/cpuhotplug.h
Split cpu_down in separate functions in preparation for state machine
conversion.
Signed-off-by: Thomas Gleixner
---
kernel/cpu.c | 83 +--
1 file changed, 53 insertions(+), 30 deletions(-)
Index: linux-2.6/kernel/cpu.c
The current CPU hotplug implementation has become an increasing
nightmare full of races and undocumented behaviour. The main issue of
the current hotplug scheme is the completely asymetric
startup/teardown process. The hotplug notifiers are mostly
undocumented and the CPU_* actions in lots of imple
On Mon, 21 Jan 2013, Matt Sealey wrote:
> And if I wanted to I could register 8 more timers. That seems rather
> excessive, but the ability to use those extra 8 as clock outputs from
> the SoC or otherwise directly use comparators is useful to some
> people, does Linux in general really give a damn
On Thu, 31 Jan 2013, Andrew Morton wrote:
> On Thu, 31 Jan 2013 15:44:10 -
> Thomas Gleixner wrote:
>
> > At the end hotplug should run through an array of callbacks on both
> > sides with explicit core synchronization points. The ordering should
> > look like t
On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner wrote:
> I think we want as many people as possible cc'd on this. You may think
> it's an obvious improvement, but maybe it's just because you now
> understand the code because
On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner wrote:
> >
> > Just face it. The current hotplug maze has 100+ states which are
> > completely undocumented. They are asymetric vs. startup and
> > teardown. They just exists an
B1;2601;0cOn Fri, 1 Feb 2013, Tommi Rantala wrote:
> Hello,
>
> Trinity discovered a task_struct leak with clock_nanosleep(), reproducible
> with:
>
> -8<-8<-8<-
> #include
>
> static const struct timespec req;
>
> int main(void) {
> return clock_nanosleep(CLOCK_PROCE
On Fri, 1 Feb 2013, Hillf Danton wrote:
> On Thu, Jan 31, 2013 at 8:11 PM, Thomas Gleixner wrote:
> > +/**
> > + for_each_present_cpu(cpu) {
> > + int ret, cpustate = per_cpu(cpuhp_state, cpu);
>
> s/ret,//
Duh, yes.
--
To unsubscribe fr
On Fri, 22 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
> >>
> >> I prefer to let you guys have the final word on this patch. Whether you
> >> apply it or not, I fear I'll never be entirely happy either way :)
>
On Fri, 22 Feb 2013, John Stultz wrote:
> On 02/21/2013 02:51 PM, Thomas Gleixner wrote:
> > Use the shadow timekeeper to do the update_wall_time() adjustments and
> > then copy it over to the real timekeeper.
> >
> > Keep the shadow timekeeper in sync whe
On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>
> I don't know if this is b/c the Xen code is missing something or
> expects something that never happend. I hadn't looked at your
> patch in any detail (was going to do that on Monday).
>
> Either way, if I boot a HVM guest with PV extensions (
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/26 Thomas Gleixner :
> > On Fri, 22 Feb 2013, Linus Torvalds wrote:
> >> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner
> >> wrote:
> >> >>
> >> >> I prefer to let you guys hav
On Tue, 26 Feb 2013, Sander Eikelenboom wrote:
> Tuesday, February 26, 2013, 1:36:36 PM, you wrote:
> > On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> >>
> >> I don't know if this is b/c the Xen code is missing something or
> >> expects something that never happend. I hadn't looked at your
>
qchip: intc-irqpin: Make use of devm functions
> [PATCH 05/05] irqchip: intc-irqpin: GPL header for platform data
>
> These patches update the v1 of the INTC External IRQ pin driver
> in various ways based on feedback kindly received from:
> - Simon Horman
> - Kuninori Morimo
On Tue, 26 Feb 2013, Paul E. McKenney wrote:
> On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
> >
> > On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
> > > And what do you think about Linus's idea to move tick_nohz_irq_exit()
> > > to do_sof
On Wed, 27 Feb 2013, Russell King - ARM Linux wrote:
> On Wed, Feb 27, 2013 at 11:30:11AM +0530, Santosh Shilimkar wrote:
> > P.S: Time and again it proves that making the local timer wakeup
> > capable solves the issue.
>
> Slightly different take: it proves that hardware people don't talk to
>
Dear RT Folks,
I'm pleased to announce the 3.6.11-rt30 release.
Changes since 3.6.11-rt29:
1) Fix a deadlock on imx serial
2) Fix a ACPI scheduling while atomic issue (Steven)
3) Fix a longstanding mainline issue in printk (Yitian Bu)
I know I said that a few days ago already,
On Mon, 18 Feb 2013, Frederic Weisbecker wrote:
> On Sun, Feb 17, 2013 at 10:02:11PM +0100, Frederic Weisbecker wrote:
> > 2013/2/17 Frederic Weisbecker :
> > > 2013/2/17 Linus Torvalds :
> > >> On Sun, Feb 17, 2013 at 7:11 AM, Frederic Weisbecker
> > >> wrote:
> > >>>
> > >>> preempt_value_in_in
On Tue, 5 Feb 2013, John Stultz wrote:
> On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > But if people are strongly opposed to the clock_gettime() approach, then
> > I can go with the ioctl() because the functionality is definitively needed
> > ASAP.
>
> I prefer the ioctl method, since its le
Magnus,
On Mon, 18 Feb 2013, Magnus Damm wrote:
> +static inline unsigned long intc_irqpin_read(struct intc_irqpin_priv *p,
> + int reg)
> +{
> + struct intc_irqpin_iomem *i = &p->iomem[reg];
Newline between variable and code please.
> + return i
CC'ing linux-arch, so the arch folks can scream murder if they have
any objections.
On Tue, 19 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/18 Thomas Gleixner :
> > On Mon, 18 Feb 2013, Frederic Weisbecker wrote:
> >> diff --git a/kernel/softirq.c b/kernel/softirq.c
>
The early console implementations are the same all over the
place. Move the print function to kernel/printk and get rid of the
copies.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Mike Frysinger
Cc: Michal Simek
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: Paul Mundt
Cc: "Da
On Tue, 19 Feb 2013, Magnus Damm wrote:
> On Tue, Feb 19, 2013 at 7:11 PM, Thomas Gleixner wrote:
> >> +static DEFINE_RAW_SPINLOCK(intc_irqpin_lock); /* only used by slow path */
> >
> > Shouldn't the lock be part of struct intc_irqpin_priv ?
>
> Good idea, but
On Tue, 19 Feb 2013, Daniel Lezcano wrote:
> I am working on identifying the different wakeup sources from the
> interrupts and I have a question regarding the timer broadcast.
>
> The broadcast timer is setup to the next event and that will wake up any
> idle cpu belonging to the "broadcast cpuma
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/18/2013 12:35 PM, Thomas Gleixner wrote:
> > On Tue, 5 Feb 2013, John Stultz wrote:
> > > On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > > > But if people are strongly opposed to the clock_gettime() approach, then
&
On Tue, 19 Feb 2013, Thomas Gleixner wrote:
> On Tue, 19 Feb 2013, John Stultz wrote:
> Would be interesting to compare and contrast that. Though you can't do
> that in the kernel as the write hold time of the timekeeper seq is way
> larger than the gtod->seq write hold time. I
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/19/2013 12:15 PM, Thomas Gleixner wrote:
> > Depending on the length of the delay which kept VCPU0 away from
> > executing and depending on the direction of the ntp update of the
> > timekeeping variables __vdso_clock_gettime
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/19/2013 01:50 PM, Thomas Gleixner wrote:
> > 2) Doing #1 will allow to observe the described time going backwards
> > scenario in kernel as well.
> >
> > The reason why we did not get complaints about that scena
On Tue, 19 Feb 2013, Andy Lutomirski wrote:
> On 02/19/2013 10:21 AM, Daniel Lezcano wrote:
> > On 02/19/2013 07:10 PM, Thomas Gleixner wrote:
> >> On Tue, 19 Feb 2013, Daniel Lezcano wrote:
> >>> I am working on identifying the different wakeup sources from the
On Wed, 20 Feb 2013, Jason Liu wrote:
> void arch_idle(void)
> {
>
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>
> enter_the_wait_mode();
>
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> }
>
> when the broadcast timer interrupt arrives(this interrupt just w
On Wed, 20 Feb 2013, Dave Jones wrote:
> On Wed, Feb 20, 2013 at 08:42:46PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, February 20, 2013 02:28:26 PM Dave Jones wrote:
> > > We had two users report hitting a bug that looks like this..
> > >
> > > general protection fault: 8800 [#1] SMP
On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> As it stands, irq_exit() may or may not be called with
> irqs disabled, depending on __ARCH_IRQ_EXIT_IRQS_DISABLED
> that the arch can define.
>
> It makes tick_nohz_irq_exit() unsafe. For example two
> interrupts can race in tick_nohz_stop_sched_
On Wed, 20 Feb 2013, Tejun Heo wrote:
> Recent idr updates make idr_find() trigger WARN_ON_ONCE() before
> returning NULL when a negative ID is specified. Apparently,
> posix-timer::__lock_timer() was depending on idr_find() returning NULL
> on negative ID, thus triggering the new WARN_ON_ONCE().
On Wed, 20 Feb 2013, Tejun Heo wrote:
> Hey, Thomas.
>
> On Wed, Feb 20, 2013 at 10:38:36PM +0100, Thomas Gleixner wrote:
> > I can grumpily accept the patch below as a quick hack fix, which can
> > go to stable as well, but not with such a patently misleading
> &
On Wed, 20 Feb 2013, Armin Steinhoff wrote:
> after a walk through the module "io_apic.c" in
> "/usr/src/linux/arch/x86/kernel/apic" I got the impression that the variable
> "nr_ioapics" is used but isn't initialized !
> Could it be the source of boot problems ?
Well no, unless your compiler is si
On Wed, 20 Feb 2013, Tejun Heo wrote:
> When idr_find() is fed a negative ID, it used to look up the ID
> ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and
> move left MAX_IDR_* into idr.c") patch, and triggers WARN_ON_ONCE()
> after it.
>
> __lock_timer() feeds timer_id from use
On Wed, 20 Feb 2013, Andrew Morton wrote:
> On Wed, 20 Feb 2013 13:37:01 -0800
> Tejun Heo wrote:
> > hopefully with some comments. That said, if I'm grepping it right,
> > all archs define timer_t as int, so maybe we're just being paranoid.
> >
>
> Sure, it's unlikely to cause a problem in pra
On Wed, 20 Feb 2013, Tejun Heo wrote:
> Hello, Thomas.
>
> On Thu, Feb 21, 2013 at 12:01:07AM +0100, Thomas Gleixner wrote:
> > idr_find() should simply return NULL, if "id < 0". Is it that hard?
>
> It already does but w/ WARN_ON_ONCE(). The WARN_ON_ONCE() i
On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/20 Thomas Gleixner :
> > That's not a fix. That's an hack.
>
> I know it looks that way. That's because it's a pure regression fix,
> minimal for backportability.
>
> I'm distinguishing tw
and that they can be removed later.
>
> Signed-off-by: Tejun Heo
Acked-by : Thomas Gleixner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 21 Feb 2013, Jason Liu wrote:
> 2013/2/20 Thomas Gleixner :
> > On Wed, 20 Feb 2013, Jason Liu wrote:
> >> void arch_idle(void)
> >> {
> >>
> >> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> >>
Jason,
On Thu, 21 Feb 2013, Jason Liu wrote:
> 2013/2/21 Thomas Gleixner :
> > Now your explanation makes sense.
> >
> > I have no fast solution for this, but I think that I have an idea how
> > to fix it. Stay tuned.
>
> Thanks Thomas, wait for your fix. :)
On Thu, 21 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/21 Thomas Gleixner :
> > On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> >> 2013/2/20 Thomas Gleixner :
> >> > That's not a fix. That's an hack.
> >>
> >> I know it looks that wa
On Thu, 21 Feb 2013, Linus Torvalds wrote:
> On Wed, Feb 20, 2013 at 1:00 PM, Thomas Gleixner wrote:
> > */
> > void irq_exit(void)
> > {
> > +#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
> > + unsigned long flags;
> > +
> > + local_i
On Thu, 21 Feb 2013, Ian Abbott wrote:
> I'm not sure how useful this would be, but there are a couple of places
> in "serial_core.c" that could usefully call jsleep_interruptible()
> instead of msleep_interruptible().
Oh no. jiffies is such a misconception.
We want to get rid of jiffies in the
On Thu, 21 Feb 2013, Frederic Weisbecker wrote:
> > void irq_exit(void)
> > {
> > +#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > +#else
> > + WARN_ON_ONCE(!irqs_disabled();
>
> Missing closing parenthesis.
Dammit.
--
On Thu, 21 Feb 2013, Santosh Shilimkar wrote:
> On Thursday 21 February 2013 07:18 PM, Thomas Gleixner wrote:
> > find below a completely untested patch, which should address that issue.
> >
> After looking at the thread, I tried to see the issue on OMAP and could
> see th
1 - 100 of 17082 matches
Mail list logo
