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
Hi Ben,
I sent it twice, sorry. I haven't seen it applied for a long time and
got no response.
It is already applied.
Kind regards,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
Can only be triggered via CROSS_COMPILE env var.
Detected by cppcheck.
Signed-off-by: Thomas Jarosch
---
tools/perf/arch/common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index 3e975cb..aacef07 100644
--- a/tools/perf/arch/common.c
cppcheck message:
[tools/perf/util/sort.c:277]: (error) Mismatching allocation and deallocation:
fp
Also fix descriptor leak on error and always initialize the "fp" variable.
Signed-off-by: Thomas Jarosch
---
tools/perf/util/sort.c | 5 +++--
1 file changed, 3 insertions(+), 2
cppcheck reported:
[util/event.c:480]: (error) Memory leak: event
Signed-off-by: Thomas Jarosch
---
tools/perf/util/event.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 3cf2c3e..5cd13d7 100644
--- a/tools/perf
cppcheck reported:
[util/header.c:316]: (error) Memory leak: filename
[util/header.c:316]: (error) Memory leak: linkname
Signed-off-by: Thomas Jarosch
---
tools/perf/util/header.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util
cppcheck reported:
[util/header.c:983]: (error) Used file that is not opened.
Signed-off-by: Thomas Jarosch
---
tools/perf/util/header.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 7b24cf3..30745c2 100644
--- a/tools/perf/util
On Friday, 25. January 2013 13:01:51 you wrote:
> Em Fri, Jan 25, 2013 at 11:22:17AM +0100, Thomas Jarosch escreveu:
> > cppcheck reported:
> > [util/header.c:983]: (error) Used file that is not opened.
> >
> > Signed-off-by: Thomas Jarosch
> > ---
> >
>
pclose(NULL) is undefined behavior and crashes.
Signed-off-by: Thomas Jarosch
---
tools/perf/util/sort.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index a83ded2..8333661 100644
--- a/tools/perf/util/sort.c
+++ b
cppcheck reported:
[util/header.c:983]: (error) Used file that is not opened.
Thanks to Arnaldo Carvalho de Melo for pointing out that
fclose(NULL) is undefined behavior -> protect against it.
Signed-off-by: Thomas Jarosch
---
tools/perf/util/header.c | 4 +++-
1 file changed, 3 inserti
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni
Cc: Paul Gortmaker
Cc: Jesse Barnes
Cc: Yinghai Lu
Cc: linux-kernel@vger.kernel.org
---
lib
t.
You would still need to set something from userspace to get the perfect
sampling rate for this platform.
I wonder where the cpufreq driver does get the 1ms latency from?
Is this value valid?
The driver should return the correct latency, then there is no need for
workarounds like this.
Tho
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 Tuesday, February 26, 2013 04:20:07 PM Viresh Kumar wrote:
> On 26 February 2013 16:14, Thomas Renninger wrote:
> > Redefining MIN_LATENCY_MULTIPLIER shouldn't hurt that much, but this looks
> > like a workaround.
> > It only modifies the minimal sampling rate that u
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
Nothing outside of the timekeeping core needs that lock.
Signed-off-by: Thomas Gleixner
---
include/linux/jiffies.h |1 -
kernel/time/tick-internal.h |2 ++
kernel/time/timekeeping.c |1 +
3 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6/include/linux
We want to shorten the seqcount write hold time. So split the seqlock
into a lock and a seqcount.
Open code the seqwrite_lock in the places which matter and drop the
sequence counter update where it's pointless.
Signed-off-by: Thomas Gleixner
---
kernel/time/timekeeping.c |
Calculate the cycle interval shifted value once. No functional change,
just makes the code more readable.
Signed-off-by: Thomas Gleixner
---
kernel/time/timekeeping.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/kernel/time/timekeeping.c
Shorten the seqcount write hold region to the actual update of the
timekeeper and the related data (e.g vsyscall).
On a contemporary x86 system this reduces the maximum latencies on
Preempt-RT from 8us to 4us on the non-timekeeping cores.
Signed-off-by: Thomas Gleixner
---
kernel/time
vsyscall data in the next patch.
Signed-off-by: Thomas Gleixner
---
kernel/time/timekeeping.c | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
Index: linux-3.6/kernel/time/timekeeping.c
For calculating the new timekeeper values store the new cycle_last
value in the timekeeper and update the clock->cycle_last just when we
actually update the new values.
Signed-off-by: Thomas Gleixner
---
kernel/time/timekeeping.c |4 +++-
1 file changed, 3 insertions(+), 1 delet
For implementing a shadow timekeeper and a split calculation/update
region we need to store the cycle_last value in the timekeeper and
update the value in the clocksource struct only in the update region.
Add the extra storage to the timekeeper.
Signed-off-by: Thomas Gleixner
---
include/linux
The vsyscall based timekeeping interfaces for userspace provide the
shortest possible reader side blocking (update of the vsyscall gtod
data structure), but the kernel side interfaces to timekeeping are
blocked over the full code sequence of calculating update_wall_time()
magic which can be rather
Make the lock a separate entity. Preparatory patch for shadow
timekeeper structure.
Signed-off-by: Thomas Gleixner
---
include/linux/timekeeper_internal.h |2
kernel/time/timekeeping.c | 96 +---
2 files changed, 47 insertions(+), 51 deletions
Just booted linus head on one of my old kvm based testing systems and
got the following splat:
[0.531910] BUG: unable to handle kernel NULL pointer dereference at
0024
[0.532173] IP: [] apei_hest_parse+0xd2/0xf0
[0.532173] PGD 0
[0.532173] Oops: [#1] PREEMPT SMP
On Fri, 22 Feb 2013, Rafael J. Wysocki wrote:
> On Friday, February 22, 2013 02:40:58 AM Rafael J. Wysocki wrote:
> > It looks like the hest_tab memory mapping is unmapped between
> > acpi_hest_init()
> > and aer_acpi_firmware_first(), but I have no idea what may be responsible
> > for
> > that.
On Fri, 22 Feb 2013, Santosh Shilimkar wrote:
> BTW, Lorenzo off-list mentioned to me about warning in boot-up
> which I missed while testing your patch. It will take bit more
> time for me to look into it and hence thought of reporting it.
>
> [2.186126] [ cut here ]
>
On Fri, 22 Feb 2013, Santosh Shilimkar wrote:
> On Friday 22 February 2013 04:01 PM, Lorenzo Pieralisi wrote:
> > On Fri, Feb 22, 2013 at 10:24:00AM +0000, Thomas Gleixner wrote:
> > > On Fri, 22 Feb 2013, Santosh Shilimkar wrote:
> > > > BTW, Lorenzo off-list me
not under the HARDIRQ_OFFSET,
> calling raise_softirq() resulted in waking up the ksoftirqd thread.
> This is correct because invoke_softirq() has already been invoked at
> this stage. But with this patch they are now under HARDIRQ_OFFSET and
> raise_softirq() wrongly thinks invoke_softir
ble. Also remove the now useless
> acpi_disabled check from apei_hest_parse().
>
> Reported-by: Thomas Gleixner
> Signed-off-by: Rafael J. Wysocki
Tested-by: Thomas Gleixner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote:
> On Fri, Feb 22, 2013 at 12:07:30PM +0000, Thomas Gleixner wrote:
> > Now we could make use of that and avoid going deep idle just to come
> > back right away via the IPI. Unfortunately the notification thingy has
> > no return
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
> On Fri, Feb 22, 2013 at 03:33:51PM +0100, Thomas Gleixner wrote:
> > The minimal extra check at the end of irq_exit() is way better than
> > any other special cased workaround and the softirq stuff is really the
> > only th
On Fri, 22 Feb 2013, Jacob Pan wrote:
> On Thu, 21 Feb 2013 23:01:23 +0100
> Daniel Lezcano wrote:
>
> > +/*
> > + * Set broadcast interrupt affinity
> > + */
> > +static void tick_broadcast_set_affinity(struct clock_event_device
> > *bc, int cpu) +{
> > + struct cpumask cpumask;
> > +
> > +
On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote:
> On Fri, Feb 22, 2013 at 03:03:02PM +0000, Thomas Gleixner wrote:
> > On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote:
> > > On Fri, Feb 22, 2013 at 12:07:30PM +, Thomas Gleixner wrote:
> > > > Now we could make use of
On Fri, 22 Feb 2013, Prarit Bhargava wrote:
> If I explicitly disable the clocksource watchdog in the x86 Kconfig,
> the x86 kernel will not compile unless this is properly defined.
You shouldn't do that. :)
> Signed-off-by: Prarit Bhargava
> Cc: John Stultz
> Cc: Thom
On Tue, 12 Mar 2013, Oleg Nesterov wrote:
> Hi Thomas,
>
> On 03/11, Thomas Gleixner wrote:
> >
> > On Mon, 11 Mar 2013, Oleg Nesterov wrote:
> > >
> > > But the actual reason for this cleanup is that I do not understand
> > > why park/unp
On Tue, 12 Mar 2013, Uwe Kleine-König wrote:
> +static struct nvic_chip_data nvic_data __read_mostly;
What the heck is this? You have a static struct which you set in
irqdata.chip_data?
> +static inline void __iomem *nvic_dist_base(struct irq_data *d)
> +{
> + struct nvic_chip_data *nvic_data
On Tue, 12 Mar 2013, Uwe Kleine-König wrote:
> Hello Thomas,
>
> On Tue, Mar 12, 2013 at 08:57:34PM +0100, Thomas Gleixner wrote:
> > On Tue, 12 Mar 2013, Uwe Kleine-König wrote:
> > > +static struct nvic_chip_data nvic_data __read_mostly;
> >
> > What the he
stuff used is totally
irrelevant.
Stop trying to resolve your companys or your companys customers legal
issues by false claims.
The GPL is there for a reason.
Aside of that the whole attempt to export stuff which has been not
exported before without the _GPL extension is also:
Nacked-by: Tho
Hi,
-*- Early printk
help text says:
"You should normally N here, unless you want to debug such a crash.
(Depends on: EXPERT [=n])"
How to normally N here?
kind regards
thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wed, 13 Mar 2013, Lorenzo Pieralisi wrote:
> > + /* Take care of enforced broadcast requests */
> > + cpumask_or(tmpmask, tmpmask, tick_broadcast_force_mask);
> > + cpumask_clear(tick_broadcast_force_mask);
>
> I tested the set and it works fine on a dual cluster big.LITTLE testchip
> usi
, remove the "samsung,vbus-gpio"
property from the usb2.0 node in dts files (this property is optional)
for Arndale board. Then, during the machine_init, perform the reset
sequencing as required.
Ideally, the reset sequencing for the on-board AX88760 usb hub should
have been handled in th
On 14 March 2013 17:31, Alexander Graf wrote:
>
> On 14.03.2013, at 05:19, Thomas Abraham wrote:
>
>> On 14 March 2013 05:29, Alexander Graf wrote:
>>> On my Exynos 5 based Arndale system, I need to pull the reset line down
>>> and then let it go up again to
101 - 200 of 21533 matches
Mail list logo
