Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
* Hector Marco Gisbert wrote:
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + return (ret > base) ? ret : base;
> +}
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + return (ret > base) ? ret : base;
> +}
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + brk_rnd();
> + return (ret > base) ? ret : base;
> +}
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + return (ret > base) ? ret : base;
> +}
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + return (ret > base) ? ret : base;
> +}
That pointless repetition should be avoided.
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}
* Ingo Molnar wrote:
>
> * Anton Blanchard wrote:
>
> > +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> > +static int die_owner = -1;
> > +static unsigned int die_nest_count;
> > +
> > +unsigned long __die_spin_lock_irqsave(void)
> > +{
> > + unsigned long flags;
> > + int cpu;
> > +
> > + /* racy, but better than risking deadlock. */
> > + raw_local_irq_save(flags);
> > +
> > + cpu = smp_processor_id();
> > + if (!arch_spin_trylock(&die_lock)) {
> > + if (cpu != die_owner)
> > + arch_spin_lock(&die_lock);
>
> So why not trylock and time out here after a few seconds,
> instead of indefinitely supressing some potentially vital
> output due to some other CPU crashing/locking with the lock
> held?
[...]
> If we fix the deadlock potential, and get a true global
> ordering of various oopses/warnings as they triggered (or
> at least timestamping them), [...]
If we had a global 'trouble counter' we could use that to
refine the spin-looping timeout: instead of using a pure
timeout of a few seconds, we could say 'a timeout of a few
seconds while the counter does not increase'.
I.e. only override the locking/ordering if the owner CPU
does not seem to be able to make progress with printing the
oops/warning.
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/smp: Wait until secondaries are active & online
Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:
BUG_ON(td->cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:
CPU: 0
Comm: watchdog/130
The problem is that we aren't ensuring the CPU active bit is set for the
secondary before allowing the master to continue on. The master unparks
the secondary CPU's kthreads and the scheduler looks for a CPU to run
on. It calls select_task_rq() and realises the suggested CPU is not in
the cpus_allowed mask. It then ends up in select_fallback_rq(), and
since the active bit isnt't set we choose some other CPU to run on.
This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug
vs. set_cpus_allowed_ptr()", which changed from setting active before
online to setting active after online. However that was in turn fixing a
bug where other code assumed an active CPU was also online, so we can't
just revert that fix.
The simplest fix is just to spin waiting for both active & online to be
set. We already have a barrier prior to set_cpu_online() (which also
sets active), to ensure all other setup is completed before online &
active are set.
Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Signed-off-by: Michael Ellerman
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/smp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 6e19afa35a15..ec9ec2058d2d 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -541,8 +541,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
if (smp_ops->give_timebase)
smp_ops->give_timebase();
- /* Wait until cpu puts itself in the online map */
- while (!cpu_online(cpu))
+ /* Wait until cpu puts itself in the online & active maps */
+ while (!cpu_online(cpu) || !cpu_active(cpu))
cpu_relax();
return 0;
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}
* Anton Blanchard wrote:
> +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> +static int die_owner = -1;
> +static unsigned int die_nest_count;
> +
> +unsigned long __die_spin_lock_irqsave(void)
> +{
> + unsigned long flags;
> + int cpu;
> +
> + /* racy, but better than risking deadlock. */
> + raw_local_irq_save(flags);
> +
> + cpu = smp_processor_id();
> + if (!arch_spin_trylock(&die_lock)) {
> + if (cpu != die_owner)
> + arch_spin_lock(&die_lock);
So why not trylock and time out here after a few seconds,
instead of indefinitely supressing some potentially vital
output due to some other CPU crashing/locking with the lock
held?
> + }
> + die_nest_count++;
> + die_owner = cpu;
> +
> + return flags;
I suspect this would work in most cases.
If we fix the deadlock potential, and get a true global
ordering of various oopses/warnings as they triggered (or
at least timestamping them), then I'm sold on this I guess,
it will likely improve things.
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/7] Serialise oopses, BUGs, WARNs, dump_stack, soft lockups and hard lockups
* Anton Blanchard wrote: > Every now and then I end up with an undebuggable issue > because multiple CPUs hit something at the same time and > everything is interleaved: > > CR: 4882 XER: > ,RI > c003dc72fd10 > ,LE > d65b84e8 > Instruction dump: > MSR: 800100029033 > > Very annoying. > > Some architectures already have their own recursive > locking for oopses and we have another version for > serialising dump_stack. > > Create a common version and use it everywhere (oopses, > BUGs, WARNs, dump_stack, soft lockups and hard lockups). Dunno. I've had cases where the simultaneity of the oopses (i.e. their garbled nature) gave me the clue about the type of race to expect. To still get that information: instead of taking a serializing spinlock (or in addition to it), it would be nice to at least preserve the true time order of the incidents, at minimum by generating a global count for oopses/warnings (a bit like the oops count # currently), and to gather it first - before taking any spinlocks. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist
On Fri, 2015-02-20 at 16:07 +0100, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/platforms/powernv/opal-sensor.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c
> b/arch/powerpc/platforms/powernv/opal-sensor.c
> index 4ab67ef7abc9..544292f2020f 100644
> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
> struct platform_device *pdev;
> struct device_node *sensor;
>
> + if (!opal_check_token(OPAL_SENSOR_READ))
> + return -ENODEV;
> +
> sensor = of_find_node_by_path("/ibm,opal/sensors");
> if (!sensor) {
> pr_err("Opal node 'sensors' not found\n");
Are you actually seeing this in practice?
It's a bit annoying that we have to check for the token, and then also check
the device tree. It would be nice if one implied the presence of the other.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.0-rc1
On Mon, 2015-02-23 at 09:45 +0100, Geert Uytterhoeven wrote: > On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven > wrote: > > Below is the list of build error/warning regressions/improvements in > > v4.0-rc1[1] compared to v3.19[2]. > > > > Summarized: > > - build errors: +11/-10 > > > [1] http://kisskb.ellerman.id.au/kisskb/head/8494/ (256 out of 257 configs) > > [2] http://kisskb.ellerman.id.au/kisskb/head/8427/ (255 out of 257 configs) ... > > + error: book3s_64_vio_hv.c: undefined reference to `power7_wakeup_loss': > > => .text+0x408) > > pseries_defconfig This one is actually from pseries_defconfig+POWERNV=n, so I think I broke your script with the + notation in the config name :) http://kisskb.ellerman.id.au/kisskb/buildresult/12372031/ cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/mpic: remove unused functions
On Fri, 2015-02-20 at 11:40 +0700, Arseny Solokha wrote: > > If I just get a patch saying "removed unused foo()", I have to go and dig > > and > > find out: > > - was it recently added and will be used soon? > > - is it ancient and never used, if so can we work out why, ie. feature X > > never landed so this code is no longer needed. > > - is it old code that *was* used but isn't now because commit ... removed > > the > > last user. > > - is it code that *should* be used, but isn't for some odd reason? > > > > > > So if you can provide that sort of detail for me, that really adds value to > > the > > patch. Otherwise the patch is basically just a TODO for me, to go and work > > out > > why the code is unused. > > Got it. Will resend the whole series one of these days. Thanks. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] pseries/iommu: remove iommu device references via bus notifier
On Mon, 2015-02-23 at 10:54 -0800, Nishanth Aravamudan wrote:
> On 23.02.2015 [13:27:24 +1100], Michael Ellerman wrote:
> > On Sat, 2015-21-02 at 19:00:50 UTC, Nishanth Aravamudan wrote:
> > > On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > > > On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> > > > > After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"),
> > > > > the
> > > > > refcnt on the kobject backing the IOMMU group for a PCI device is
> > > > > elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
> > > > > set_iommu_table_base_and_group). When we go to dlpar a multi-function
> > > > > PCI device out:
> > > > >
> > > > > iommu_reconfig_notifier ->
> > > > > iommu_free_table ->
> > > > > iommu_group_put
> > > > > BUG_ON(tbl->it_group)
> > > > >
> > > > > We trip this BUG_ON, because there are still references on the table,
> > > > > so
> > > > > it is not freed. Fix this by also adding a bus notifier identical to
> > > > > PowerNV for pSeries.
> > > >
> > > > Please put it somewhere common, arch/powerpc/kernel/iommu.c perhaps,
> > > > and just
> > > > add a second machine_init_call() for pseries.
> > >
> > > How does this look? Only compile-tested with CONFIG_IOMMU_API on/off so
> > > far, waiting for access to the test LPAR (should have it on Monday).
> >
> > Yeah that looks better, thanks.
> >
> > It probably doesn't build with CONFIG_PCI=n though, but I don't think
> > CONFIG_PCI=n builds anyway.
>
> Indeed it doesn't. Started looking at CONFIG_PCI=n and immediately hit
> the following:
>
> PCI_MSI depends on PCI
>
> PCI can be manually turned off
>
> PSERIES (and a bunch of other platforms) select PCI_MSI
>
> So you end up with PCI_MSI on and PCI off and the build breaks.
>
> Should the platforms depend on PCI_MSI instead?
No, they don't depend on it, they would just like it if PCI is enabled.
That can be fixed fairly easily by making it:
config PSERIES
select PCI_MSI if PCI
But you then discover that there are ten other places where the build breaks
for PCI=n.
I'm starting to think we should just force PCI on for PSERIES and be done with
it, we could all spend less of our time chasing build breaks for configurations
no one actually cares about in practice (ie. PSERIES=y PCI=n).
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] cxl: Add explicit precision specifiers
Excerpts from Joe Perches's message of 2015-02-24 01:59:45 +1100: > On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote: > > 24 of the %.16llx > > matches are in drivers/misc/cxl/, so internal consistency wins. > > I think that's more an argument for changing all of the > cx1 uses to "%016llx". I would not object if someone submitted a patch that makes this change across the whole driver. Cheers, -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] cxl: Add explicit precision specifiers
Acked-by: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Export __spin_yield
On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote: > Export __spin_yield so that the arch_spin_unlock() function > can be invoked from a module. Make it EXPORT_SYMBOL_GPL. Also explain why a module might need it > Signed-off-by: Suresh Warrier > --- > arch/powerpc/lib/locks.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c > index bb7cfec..d100de8 100644 > --- a/arch/powerpc/lib/locks.c > +++ b/arch/powerpc/lib/locks.c > @@ -41,6 +41,7 @@ void __spin_yield(arch_spinlock_t *lock) > plpar_hcall_norets(H_CONFER, > get_hard_smp_processor_id(holder_cpu), yield_count); > } > +EXPORT_SYMBOL(__spin_yield); > > /* > * Waiting for a read lock or a write lock on a rwlock... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] powerpc: Serialise BUG and WARNs with die_spin_lock_{irqsave, irqrestore}
A simple kernel module was used to create concurrent WARNs and BUGs:
http://ozlabs.org/~anton/junkcode/warnstorm.tar.gz
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/traps.c | 44
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4cc1e72..f779557 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1114,6 +1114,39 @@ static int emulate_math(struct pt_regs *regs)
static inline int emulate_math(struct pt_regs *regs) { return -1; }
#endif
+static bool __report_bug(unsigned long bugaddr, struct pt_regs *regs)
+{
+ const struct bug_entry *bug;
+ unsigned long flags;
+ int err;
+
+ if (!is_valid_bugaddr(bugaddr))
+ return false;
+
+ bug = find_bug(bugaddr);
+ if (!bug)
+ return false;
+
+ if (is_warning_bug(bug)) {
+ die_spin_lock_irqsave(flags);
+ report_bug(bugaddr, regs);
+ die_spin_unlock_irqrestore(flags);
+
+ regs->nip += 4;
+
+ return true;
+ }
+
+ flags = oops_begin(regs);
+ report_bug(bugaddr, regs);
+ err = SIGTRAP;
+ if (__die("Exception in kernel mode", regs, err))
+ err = 0;
+ oops_end(flags, regs, err);
+
+ return true;
+}
+
void __kprobes program_check_exception(struct pt_regs *regs)
{
enum ctx_state prev_state = exception_enter();
@@ -1138,11 +1171,9 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
== NOTIFY_STOP)
goto bail;
- if (!(regs->msr & MSR_PR) && /* not user-mode */
- report_bug(regs->nip, regs) == BUG_TRAP_TYPE_WARN) {
- regs->nip += 4;
+ if (!user_mode(regs) && __report_bug(regs->nip, regs))
goto bail;
- }
+
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
goto bail;
}
@@ -1157,11 +1188,8 @@ void __kprobes program_check_exception(struct pt_regs
*regs)
* - A tend is illegally attempted.
* - writing a TM SPR when transactional.
*/
- if (!user_mode(regs) &&
- report_bug(regs->nip, regs) == BUG_TRAP_TYPE_WARN) {
- regs->nip += 4;
+ if (!user_mode(regs) && __report_bug(regs->nip, regs))
goto bail;
- }
/* If usermode caused this, it's done something illegal and
* gets a SIGILL slap on the wrist. We call it an illegal
* operand to distinguish from the instruction just being bad
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/7] dump_stack: Serialise dump_stack with die_spin_lock_{irqsave, irqrestore}
Remove another version of a recursive lock in dump_stack.
Signed-off-by: Anton Blanchard
---
lib/dump_stack.c | 40
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 6745c62..f64ee3c 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
static void __dump_stack(void)
{
@@ -20,44 +20,12 @@ static void __dump_stack(void)
*
* Architectures can override this implementation by implementing its own.
*/
-#ifdef CONFIG_SMP
-static atomic_t dump_lock = ATOMIC_INIT(-1);
-
asmlinkage __visible void dump_stack(void)
{
- int was_locked;
- int old;
- int cpu;
-
- /*
-* Permit this cpu to perform nested stack dumps while serialising
-* against other CPUs
-*/
- preempt_disable();
-
-retry:
- cpu = smp_processor_id();
- old = atomic_cmpxchg(&dump_lock, -1, cpu);
- if (old == -1) {
- was_locked = 0;
- } else if (old == cpu) {
- was_locked = 1;
- } else {
- cpu_relax();
- goto retry;
- }
-
- __dump_stack();
+ unsigned long flags;
- if (!was_locked)
- atomic_set(&dump_lock, -1);
-
- preempt_enable();
-}
-#else
-asmlinkage __visible void dump_stack(void)
-{
+ die_spin_lock_irqsave(flags);
__dump_stack();
+ die_spin_unlock_irqrestore(flags);
}
-#endif
EXPORT_SYMBOL(dump_stack);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] watchdog: Serialise soft lockup errors with die_spin_lock_{irqsave, irqrestore}
A simple kernel module was used to create concurrent soft and
hard lockups:
http://ozlabs.org/~anton/junkcode/badguy.tar.gz
Signed-off-by: Anton Blanchard
---
kernel/watchdog.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 70bf118..dd161e3 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -313,6 +314,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
struct pt_regs *regs = get_irq_regs();
int duration;
int softlockup_all_cpu_backtrace = sysctl_softlockup_all_cpu_backtrace;
+ unsigned long flags;
/* kick the hardlockup detector */
watchdog_interrupt_count();
@@ -384,6 +386,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
}
}
+ die_spin_lock_irqsave(flags);
pr_emerg("BUG: soft lockup - CPU#%d stuck for %us! [%s:%d]\n",
smp_processor_id(), duration,
current->comm, task_pid_nr(current));
@@ -394,6 +397,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
show_regs(regs);
else
dump_stack();
+ die_spin_unlock_irqrestore(flags);
if (softlockup_all_cpu_backtrace) {
/* Avoid generating two back traces for current
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/7] x86: Use die_spin_lock_{irqsave,irqrestore}
Replace the x86 specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/x86/kernel/dumpstack.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index b74ebc7..b635f73 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -196,28 +197,12 @@ void show_stack(struct task_struct *task, unsigned long
*sp)
show_stack_log_lvl(task, NULL, sp, bp, "");
}
-static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
-static int die_owner = -1;
-static unsigned int die_nest_count;
-
unsigned long oops_begin(void)
{
- int cpu;
unsigned long flags;
oops_enter();
-
- /* racy, but better than risking deadlock. */
- raw_local_irq_save(flags);
- cpu = smp_processor_id();
- if (!arch_spin_trylock(&die_lock)) {
- if (cpu == die_owner)
- /* nested oops. should stop eventually */;
- else
- arch_spin_lock(&die_lock);
- }
- die_nest_count++;
- die_owner = cpu;
+ die_spin_lock_irqsave(flags);
console_verbose();
bust_spinlocks(1);
return flags;
@@ -231,13 +216,8 @@ void oops_end(unsigned long flags, struct pt_regs *regs,
int signr)
crash_kexec(regs);
bust_spinlocks(0);
- die_owner = -1;
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
- die_nest_count--;
- if (!die_nest_count)
- /* Nest count reaches zero, release the lock. */
- arch_spin_unlock(&die_lock);
- raw_local_irq_restore(flags);
+ die_spin_unlock_irqrestore(flags);
oops_exit();
if (!signr)
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] arm: Use die_spin_lock_{irqsave,irqrestore}
Replace the ARM specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/arm/kernel/traps.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 788e23f..3e3469d 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -263,28 +264,12 @@ static int __die(const char *str, int err, struct pt_regs
*regs)
return 0;
}
-static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
-static int die_owner = -1;
-static unsigned int die_nest_count;
-
static unsigned long oops_begin(void)
{
- int cpu;
unsigned long flags;
oops_enter();
-
- /* racy, but better than risking deadlock. */
- raw_local_irq_save(flags);
- cpu = smp_processor_id();
- if (!arch_spin_trylock(&die_lock)) {
- if (cpu == die_owner)
- /* nested oops. should stop eventually */;
- else
- arch_spin_lock(&die_lock);
- }
- die_nest_count++;
- die_owner = cpu;
+ die_spin_lock_irqsave(flags);
console_verbose();
bust_spinlocks(1);
return flags;
@@ -296,13 +281,8 @@ static void oops_end(unsigned long flags, struct pt_regs
*regs, int signr)
crash_kexec(regs);
bust_spinlocks(0);
- die_owner = -1;
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
- die_nest_count--;
- if (!die_nest_count)
- /* Nest count reaches zero, release the lock. */
- arch_spin_unlock(&die_lock);
- raw_local_irq_restore(flags);
+ die_spin_unlock_irqrestore(flags);
oops_exit();
if (in_interrupt())
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] powerpc: Use die_spin_lock_{irqsave,irqrestore}
Replace the powerpc specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/traps.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 19e4744..4cc1e72 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -109,14 +110,10 @@ static void pmac_backlight_unblank(void)
static inline void pmac_backlight_unblank(void) { }
#endif
-static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
-static int die_owner = -1;
-static unsigned int die_nest_count;
static int die_counter;
static unsigned __kprobes long oops_begin(struct pt_regs *regs)
{
- int cpu;
unsigned long flags;
if (debugger(regs))
@@ -124,17 +121,7 @@ static unsigned __kprobes long oops_begin(struct pt_regs
*regs)
oops_enter();
- /* racy, but better than risking deadlock. */
- raw_local_irq_save(flags);
- cpu = smp_processor_id();
- if (!arch_spin_trylock(&die_lock)) {
- if (cpu == die_owner)
- /* nested oops. should stop eventually */;
- else
- arch_spin_lock(&die_lock);
- }
- die_nest_count++;
- die_owner = cpu;
+ die_spin_lock_irqsave(flags);
console_verbose();
bust_spinlocks(1);
if (machine_is(powermac))
@@ -146,15 +133,10 @@ static void __kprobes oops_end(unsigned long flags,
struct pt_regs *regs,
int signr)
{
bust_spinlocks(0);
- die_owner = -1;
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
- die_nest_count--;
oops_exit();
printk("\n");
- if (!die_nest_count)
- /* Nest count reaches zero, release the lock. */
- arch_spin_unlock(&die_lock);
- raw_local_irq_restore(flags);
+ die_spin_unlock_irqrestore(flags);
crash_fadump(regs, "die oops");
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}
Many architectures have their own oops locking code that allows
the lock to be taken recursively. Create a common version.
Avoid creating generic locking functions, so they can't be
abused in other parts of the kernel.
Signed-off-by: Anton Blanchard
---
include/linux/die_lock.h | 23 +++
lib/Makefile | 1 +
lib/die_lock.c | 43 +++
3 files changed, 67 insertions(+)
create mode 100644 include/linux/die_lock.h
create mode 100644 lib/die_lock.c
diff --git a/include/linux/die_lock.h b/include/linux/die_lock.h
new file mode 100644
index 000..540d09d
--- /dev/null
+++ b/include/linux/die_lock.h
@@ -0,0 +1,23 @@
+#ifndef __LINUX_DIE_LOCK_H
+#define __LINUX_DIE_LOCK_H
+
+#include
+
+/**
+ * die_spin_lock_irqsave - lock die spinlock
+ * @flags: interrupt state is saved here
+ *
+ * The die spinlock is used to serialise output during oopses, BUGs and
+ * WARNs. It can be taken recursively so that nested oopses will not
+ * lock up.
+ */
+unsigned long __die_spin_lock_irqsave(void);
+#define die_spin_lock_irqsave(flags) \
+ do {\
+ typecheck(unsigned long, flags);\
+ flags = __die_spin_lock_irqsave(); \
+ } while (0)
+
+void die_spin_unlock_irqrestore(unsigned long flags);
+
+#endif /* __LINUX_DIE_LOCK_H */
diff --git a/lib/Makefile b/lib/Makefile
index 3c3b30b..7d87a80 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -28,6 +28,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o
debug_locks.o random32.o \
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o
obj-y += string_helpers.o
+obj-y += die_lock.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += kstrtox.o
obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
diff --git a/lib/die_lock.c b/lib/die_lock.c
new file mode 100644
index 000..5d2de2e
--- /dev/null
+++ b/lib/die_lock.c
@@ -0,0 +1,43 @@
+#include
+#include
+
+static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int die_owner = -1;
+static unsigned int die_nest_count;
+
+unsigned long __die_spin_lock_irqsave(void)
+{
+ unsigned long flags;
+ int cpu;
+
+ /* racy, but better than risking deadlock. */
+ raw_local_irq_save(flags);
+
+ cpu = smp_processor_id();
+ if (!arch_spin_trylock(&die_lock)) {
+ if (cpu != die_owner)
+ arch_spin_lock(&die_lock);
+ }
+ die_nest_count++;
+ die_owner = cpu;
+
+ return flags;
+}
+
+/**
+ * die_spin_unlock_irqrestore - Unlock die spinlock
+ * @flags: interrupt state to restore
+ *
+ * Unlock die spinlock and restore interrupt state. This must be
+ * paired with die_spin_lock_irqsave.
+ */
+void die_spin_unlock_irqrestore(unsigned long flags)
+{
+ die_nest_count--;
+ if (!die_nest_count) {
+ die_owner = -1;
+ /* Nest count reaches zero, release the lock. */
+ arch_spin_unlock(&die_lock);
+ }
+ raw_local_irq_restore(flags);
+}
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/7] Serialise oopses, BUGs, WARNs, dump_stack, soft lockups and hard lockups
Every now and then I end up with an undebuggable issue because multiple
CPUs hit something at the same time and everything is interleaved:
CR: 4882 XER:
,RI
c003dc72fd10
,LE
d65b84e8
Instruction dump:
MSR: 800100029033
Very annoying.
Some architectures already have their own recursive locking for oopses
and we have another version for serialising dump_stack.
Create a common version and use it everywhere (oopses, BUGs, WARNs,
dump_stack, soft lockups and hard lockups). A few testcases were
used to verify the series:
A trivial module to create concurrent WARNs, BUGs and oopses:
http://ozlabs.org/~anton/junkcode/warnstorm.tar.gz
And one to create concurrent soft and hard lockups:
http://ozlabs.org/~anton/junkcode/badguy.tar.gz
Anton Blanchard (7):
Add die_spin_lock_{irqsave,irqrestore}
powerpc: Use die_spin_lock_{irqsave,irqrestore}
arm: Use die_spin_lock_{irqsave,irqrestore}
x86: Use die_spin_lock_{irqsave,irqrestore}
watchdog: Serialise soft lockup errors with
die_spin_lock_{irqsave,irqrestore}
dump_stack: Serialise dump_stack with
die_spin_lock_{irqsave,irqrestore}
powerpc: Serialise BUG and WARNs with
die_spin_lock_{irqsave,irqrestore}
arch/arm/kernel/traps.c | 26 ++---
arch/powerpc/kernel/traps.c | 68 ++---
arch/x86/kernel/dumpstack.c | 26 ++---
include/linux/die_lock.h| 23 +++
kernel/watchdog.c | 4 +++
lib/Makefile| 1 +
lib/die_lock.c | 43
lib/dump_stack.c| 40 +++---
8 files changed, 120 insertions(+), 111 deletions(-)
create mode 100644 include/linux/die_lock.h
create mode 100644 lib/die_lock.c
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On Fri, 2015-02-20 at 15:25 -0400, Julian Margetson wrote: > On 2/18/2015 11:25 PM, Julian Margetson wrote: > re PPC4XX PCI(E) MSI support. > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087273.html Hmm, I think all those comments were addressed before it was merged. I tried to get a 4xx board going here last week, but it doesn't seem happy. I can get a bit of uboot but then it hangs, might be overheating. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Export __spin_yield
Export __spin_yield so that the arch_spin_unlock() function can be invoked from a module. Signed-off-by: Suresh Warrier --- arch/powerpc/lib/locks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c index bb7cfec..d100de8 100644 --- a/arch/powerpc/lib/locks.c +++ b/arch/powerpc/lib/locks.c @@ -41,6 +41,7 @@ void __spin_yield(arch_spinlock_t *lock) plpar_hcall_norets(H_CONFER, get_hard_smp_processor_id(holder_cpu), yield_count); } +EXPORT_SYMBOL(__spin_yield); /* * Waiting for a read lock or a write lock on a rwlock... -- 1.8.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] cxl: Add explicit precision specifiers
On Mon, 2015-02-23 at 06:59 -0800, Joe Perches wrote: > On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote: > > 24 of the %.16llx > > matches are in drivers/misc/cxl/, so internal consistency wins. > > I think that's more an argument for changing all of the > cx1 uses to "%016llx". +1 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update all configs using savedefconfig
On Mon, 2015-02-23 at 10:59 +0100, Geert Uytterhoeven wrote: > Hi Michael, > > On Tue, Jan 20, 2015 at 8:05 AM, Michael Ellerman wrote: > > It looks like it's ~4 years since we updated some of these, so do a bulk > > update. > > > > Verified that the before and after generated configs are exactly the > > same. > > Yep, that's guaranteed by the tool (modulo bugs). > > > Which begs the question why update them? The answer is that it can be > > confusing when the stored defconfig drifts too far from the generated > > result. > > And it becomes hard to update them, e.g. for enabling or disabling a single > option. > > Now the big question is: do they still work? > Plainly ignoring any bugs introduced in the code, there are probably several > "select" statements that have been removed. 4 years ago, they automatically > selected some critical options, while now, they're no longer selected, causing > breakage. Yeah true. So far no one has yelled at me, so perhaps we got lucky :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On Fri, 2015-02-20 at 15:54 +0100, Sebastian Andrzej Siewior wrote:
> On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
> >> Thomas, what is the usual approach for patches like this? Do you take
> >> them into your rt tree or should they get integrated to upstream?
> >
> > Patch 1 is definitely suitable for upstream, that's the reason why we
> > have raw_spin_lock vs. raw_spin_unlock.
>
> raw_spin_lock were introduced in c2f21ce2e31286a0a32 ("locking:
> Implement new raw_spinlock). They are used in context which runs with
> IRQs off - especially on -RT. This includes usually interrupt
> controllers and related core-code pieces.
>
> Usually you see "scheduling while atomic" on -RT and convert them to
> raw locks if it is appropriate.
>
> Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
> not cause a DoS and large latencies in the host. I haven't seen an
> answer to my why question. Because if the conversation leads to
> large latencies in the host then it does not look right.
>
> Each host PIC has a rawlock and does mostly just mask/unmask and the
> raw lock makes sure the value written is not mixed up due to
> preemption.
> This hardly increase latencies because the "locked" path is very short.
> If this conversation leads to higher latencies then the locked path is
> too long and hardly suitable to become a rawlock.
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a rawlock (in particular, openpic_update_irq
which loops on the number of vcpus, with a loop body that calls
IRQ_check() which loops over all pending IRQs). The vcpu limits are a
temporary bandaid to avoid the worst latencies, but I'm still skeptical
about this being upstream material.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v3] powerpc/mpc85xx: Add FMan platform support
Hello Scott,
On 02/23/2015 04:01 PM, Scott Wood wrote:
> On Wed, 2015-02-18 at 16:04 +0200, Igal.Liberman wrote:
>> From: Igal Liberman
>>
>> Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
>>
>> Signed-off-by: Igal Liberman
>> ---
>> arch/powerpc/platforms/85xx/common.c |1 +
>> arch/powerpc/platforms/85xx/corenet_generic.c |3 +++
>> 2 files changed, 4 insertions(+)
>
> What changed from v2?
v1,2 were based on an internal tree/branch and had some reference to
'fsl,dpaa':
> { .compatible = "fsl,dpaa", },
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
On Fri, 2015-02-20 at 14:45 +0100, Alexander Graf wrote: > > On 18.02.15 10:32, Bogdan Purcareata wrote: > > Due to the introduction of the raw_spinlock for the KVM openpic, guests > > with a > > high number of VCPUs may induce great latencies on the underlying RT Linux > > system (e.g. cyclictest reports latencies of ~15ms for guests with 24 > > VCPUs). > > This can be further aggravated by sending a lot of external interrupts to > > the > > guest. > > > > A malicious app can abuse this scenario, causing a DoS of the host Linux. > > Until the KVM openpic code is refactored to use finer lock granularity, > > impose > > a limitation on the number of VCPUs a guest can have when running on a > > PREEMPT_RT_FULL system with KVM_MPIC emulation. > > > > Signed-off-by: Mihai Caraman > > Signed-off-by: Bogdan Purcareata > > Reviewed-by: Scott Wood > > I don't think this patch is reasonable to take upstream. I agree (or at least, I don't think the raw lock conversion should be separated from the vcpu limitation that makes it clear that it's a temporary hack), because it ought to be fixed properly. > If we have a > latency issue, whoever spawned KVM VMs made a decision to spawn such big > VMs. I disagree. The point of PREEMPT_RT is to prevent the majority of kernel code from excessively impacting latency. When you start using raw locks you're stepping outside those bounds and need to ensure that you don't hand things within those bounds (which includes userspace) the ability to excessively impact latency. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/kvm: Convert openpic lock to raw_spinlock
On Wed, 2015-02-18 at 09:32 +, Bogdan Purcareata wrote: > This patch enables running intensive I/O workloads, e.g. netperf, in a guest > deployed on a RT host. It also enable guests to be SMP. > > The openpic spinlock becomes a sleeping mutex on a RT system. This no longer > guarantees that EPR is atomic with exception delivery. The guest VCPU thread > fails due to a BUG_ON(preemptible()) when running netperf. > > In order to make the kvmppc_mpic_set_epr() call safe on RT from non-atomic > context, convert the openpic lock to a raw_spinlock. A similar approach can > be seen for x86 platforms in the following commit [1]. > > Here are some comparative cyclitest measurements run inside a high priority RT > guest run on a RT host. The guest has 1 VCPU and the test has been run for 15 > minutes. The guest runs ~750 hackbench processes as background stress. > > spinlock raw_spinlock > Min latency (us) 4 4 > Avg latency (us) 1519 > Max latency (us) 7062 > > [1] https://lkml.org/lkml/2010/1/11/289 > > Signed-off-by: Bogdan Purcareata > Reviewed-by: Scott Wood Where did that Reviewed-by: come from? A +1 in Gerrit on an internal tree does not translate into an upstream Reviewed-by. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v3] powerpc/mpc85xx: Add FMan platform support
On Wed, 2015-02-18 at 16:04 +0200, Igal.Liberman wrote: > From: Igal Liberman > > Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed > > Signed-off-by: Igal Liberman > --- > arch/powerpc/platforms/85xx/common.c |1 + > arch/powerpc/platforms/85xx/corenet_generic.c |3 +++ > 2 files changed, 4 insertions(+) What changed from v2? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/mpic: remove unused functions
On Thu, 2015-02-19 at 19:26 +0700, Arseny Solokha wrote: > + fsl_mpic_primary_get_version() is just a safe wrapper around > fsl_mpic_get_version() for SMP configurations. While the latter is > called explicitly for handling PIC initialization and setting up error > interrupt vector depending on PIC hardware version, the former isn't > used for anything. It was meant to be used by http://patchwork.ozlabs.org/patch/233211/ which never got respun. Hongtao, do you plan to revisit that patch? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1]: thermal driver therm_adt746.c
Hi ! Please try sending patches inline rather than as attachments, it
makes replying a bit easier... Also don't CC stable, we can shoot to
stable later on if we think it's justified but first we need to get the
patch upstream
A few comments:
On Mon, 2015-02-23 at 12:58 +0100, Thomas Haschka wrote:
> --- linux/drivers/macintosh/therm_adt746x.c.orig2015-02-23
> 12:19:03.98400 +0100
> +++ linux/drivers/macintosh/therm_adt746x.c 2015-02-23 12:22:34.98000
> +0100
> @@ -1,7 +1,8 @@
> /*
> * Device driver for the i2c thermostat found on the iBook G4, Albook G4
> *
> - * Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
> + * Copyright (C) 2003, 2004, 2015
> + * Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt, Thomas Haschka
> *
> * Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
> * http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
> @@ -45,7 +46,7 @@ static u8 REM_CONTROL[2] = {0x00, 0x40};
> static u8 FAN_SPEED[2] = {0x28, 0x2a};
> static u8 FAN_SPD_SET[2] = {0x30, 0x31};
>
> -static u8 default_limits_local[3] = {70, 50, 70};/* local, sensor1,
> sensor2 */
> +static u8 default_limits_local[3] = {45, 50, 70};/* local, sensor1,
> sensor2 */
Here you change the limit for the local sensor for existing machines,
care to explain ? I *think* that got adjusted a while back due to
a bunch of bogus error on some machines.
> static u8 default_limits_chip[3] = {80, 65, 80};/* local, sensor1,
> sensor2 */
> static const char *sensor_location[3] = { "?", "?", "?" };
>
> @@ -225,59 +226,123 @@ static void display_stats(struct thermos
>
> static void update_fans_speed (struct thermostat *th)
> {
> - int lastvar = 0; /* last variation, for iBook */
> - int i = 0;
> -
> - /* we don't care about local sensor, so we start at sensor 1 */
> - for (i = 1; i < 3; i++) {
> - int started = 0;
> - int fan_number = (th->type == ADT7460 && i == 2);
> - int var = th->temps[i] - th->limits[i];
> -
> - if (var > -1) {
> - int step = (255 - fan_speed) / 7;
> - int new_speed = 0;
> +
> + /* Multfan Laptops */
> + if ( th->type == ADT7460 ) {
> +int lastvar = 0; /* last variation, for iBook */
> + int i = 0;
> +/* we don't care about local sensor, so we start at sensor 1
> */
> + for (i = 1; i < 3; i++) {
> + int started = 0;
> + int fan_number = (th->type == ADT7460 && i == 2);
> + int var = th->temps[i] - th->limits[i];
> +
> + if (var > -1) {
> + int step = (255 - fan_speed) / 7;
> + int new_speed = 0;
The function is too big, please break it down into two sub functions,
one for multifan and one for single fan.
It is also unclear due to the indentation changes whether you changed
the behaviour on "other" laptops. makes the review a bit harder.
> /* hysteresis : change fan speed only if variation is
> * more than two degrees */
> - if (abs(var - th->last_var[fan_number]) < 2)
> - continue;
> -
> - started = 1;
> - new_speed = fan_speed + ((var-1)*step);
> + if (abs(var - th->last_var[fan_number]) < 2)
> + continue;
>
> - if (new_speed < fan_speed)
> - new_speed = fan_speed;
> - if (new_speed > 255)
> - new_speed = 255;
> + started = 1;
> + new_speed = fan_speed + ((var-1)*step);
>
> - if (verbose)
> - printk(KERN_DEBUG "adt746x: Setting fans
> speed to %d "
> -"(limit exceeded by %d on
> %s)\n",
> - new_speed, var,
> -
> sensor_location[fan_number+1]);
> - write_both_fan_speed(th, new_speed);
> - th->last_var[fan_number] = var;
> - } else if (var < -2) {
> + if (new_speed < fan_speed)
> + new_speed = fan_speed;
> + if (new_speed > 255)
> + new_speed = 255;
> +
> + if (verbose)
> + printk(KERN_DEBUG "adt746x: Setting
> fans speed to %d "
> +"(limit exceeded by
> %d on %s)\n",
> +
Re: [PATCH v2] pseries/iommu: remove iommu device references via bus notifier
On 21.02.2015 [11:00:50 -0800], Nishanth Aravamudan wrote:
> On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> > > After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
> > > refcnt on the kobject backing the IOMMU group for a PCI device is
> > > elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
> > > set_iommu_table_base_and_group). When we go to dlpar a multi-function
> > > PCI device out:
> > >
> > > iommu_reconfig_notifier ->
> > > iommu_free_table ->
> > > iommu_group_put
> > > BUG_ON(tbl->it_group)
> > >
> > > We trip this BUG_ON, because there are still references on the table, so
> > > it is not freed. Fix this by also adding a bus notifier identical to
> > > PowerNV for pSeries.
> >
> > Please put it somewhere common, arch/powerpc/kernel/iommu.c perhaps, and
> > just
> > add a second machine_init_call() for pseries.
>
> How does this look? Only compile-tested with CONFIG_IOMMU_API on/off so
> far, waiting for access to the test LPAR (should have it on Monday).
>
>
> After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
> refcnt on the kobject backing the IOMMU group for a PCI device is
> elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
> set_iommu_table_base_and_group). When we go to dlpar a multi-function
> PCI device out:
>
> iommu_reconfig_notifier ->
> iommu_free_table ->
> iommu_group_put
> BUG_ON(tbl->it_group)
>
> We trip this BUG_ON, because there are still references on the table, so
> it is not freed. Fix this by moving the PowerNV bus notifier to common
> code and calling it for both PowerNV and pSeries.
Survived a remove -> add -> remove cycle, which always resulted in the
BUG_ON without the change.
> Fixes: d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier")
> Signed-off-by: Nishanth Aravamudan
> Cc: sta...@kernel.org (3.13+)
Tested-by: Nishanth Aravamudan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
[PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
The issue appears on PIE linked executables when all memory areas of a
process are randomized. In this case, the attack "offset2lib" de-randomizes
all library areas on 64 bit Linux systems in less than one second.
Further details of the PoC attack at:
http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
This patch loads the PIE linked executable in a different area than the
libraries. The successful fix can be tested with a simple pie compiled
application:
$ ./show_mmaps_pie
54859ccd6000-54859ccd7000 r-xp ... /tmp/show_mmaps_pie
54859ced6000-54859ced7000 r--p ... /tmp/show_mmaps_pie
54859ced7000-54859ced8000 rw-p ... /tmp/show_mmaps_pie
7f75be764000-7f75be91f000 r-xp ... /lib/x86_64-linux-gnu/libc.so.6
7f75be91f000-7f75beb1f000 ---p ... /lib/x86_64-linux-gnu/libc.so.6
7f75beb1f000-7f75beb23000 r--p ... /lib/x86_64-linux-gnu/libc.so.6
7f75beb23000-7f75beb25000 rw-p ... /lib/x86_64-linux-gnu/libc.so.6
7f75beb25000-7f75beb2a000 rw-p ...
7f75beb2a000-7f75beb4d000 r-xp ... /lib64/ld-linux-x86-64.so.2
7f75bed45000-7f75bed46000 rw-p ...
7f75bed46000-7f75bed47000 r-xp ...
7f75bed47000-7f75bed4c000 rw-p ...
7f75bed4c000-7f75bed4d000 r--p ... /lib64/ld-linux-x86-64.so.2
7f75bed4d000-7f75bed4e000 rw-p ... /lib64/ld-linux-x86-64.so.2
7f75bed4e000-7f75bed4f000 rw-p ...
7fffb3741000-7fffb3762000 rw-p ... [stack]
7fffb377b000-7fffb377d000 r--p ... [vvar]
7fffb377d000-7fffb377f000 r-xp ... [vdso]
Once corrected, the PIE linked application is loaded in a different area.
We updated the "Fixing Offset2lib weakness" page:
http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html
Signed-off-by: Hector Marco-Gisbert
Signed-off-by: Ismael Ripoll
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..ee7ea7e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
config ARM
bool
default y
- select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index afb9caf..6755cd8 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -115,7 +115,8 @@ int dump_task_regs(struct task_struct *t,
elf_gregset_t *elfregs);
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE(2 * TASK_SIZE / 3)
+extern unsigned long randomize_et_dyn(unsigned long base);
+#define ELF_ET_DYN_BASE(randomize_et_dyn(2 * TASK_SIZE / 3))
/* When the program starts, a1 contains a pointer to a function to be
registered with atexit, as per the SVR4 ABI. A value of 0 means we
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 5e85ed3..9177100 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -30,6 +30,17 @@ static int mmap_is_legacy(void)
return sysctl_legacy_va_layout;
}
+static unsigned long mmap_rnd(void)
+{
+ unsigned long rnd = 0;
+
+ /* 8 bits of randomness in 20 address space bits */
+ if (current->flags & PF_RANDOMIZE)
+ rnd = (long)get_random_int() % (1 << 8);
+
+ return rnd << PAGE_SHIFT;
+}
+
static unsigned long mmap_base(unsigned long rnd)
{
unsigned long gap = rlimit(RLIMIT_STACK);
@@ -230,3 +241,13 @@ int devmem_is_allowed(unsigned long pfn)
}
#endif
+
+unsigned long randomize_et_dyn(unsigned long base)
+{
+ unsigned long ret;
+ if ((current->personality & ADDR_NO_RANDOMIZE) ||
+ !(current->flags & PF_RANDOMIZE))
+ return base;
+ ret = base + mmap_rnd();
+ return (ret > base) ? ret : base;
+}
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1f9a20..5580d90 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1,6 +1,5 @@
config ARM64
def_bool y
- select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_SG_CHAIN
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 1f65be3..01d3aab 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -126,7 +126,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
* that it will "exec", and that there is sufficient room for the brk.
*/
extern unsigned long randomize_et_dyn(unsigned long base);
-#define ELF_ET_DYN_BASE(2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE(randomize_et_dyn(2 * TASK_SIZE_64 / 3))
/*
* When the program starts, a1 contains a pointer to a function to be
@@ -169,7 +169,7 @@ extern unsigned long arch_randomize_brk(struct
mm_struct *mm);
#define COMPAT_ELF_PLATFORM("v8l")
#endif
-#define COMPAT_ELF_ET_DYN_BASE (2 * TASK
Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
(I've added some additional CCs to make sure the arch maintainers
notice this patch.)
This patch seems white-space damaged to me. I had to do a lot of
manual editing to get it to apply. Please use "git format-patch", if
you're not already. What version of the kernel was this based on?
On Mon, Feb 23, 2015 at 10:37 AM, Hector Marco wrote:
> [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
>
> The issue appears on PIE linked executables when all memory areas of a
> process are randomized. In this case, the attack "offset2lib" de-randomizes
> all library areas on 64 bit Linux systems in less than one second.
>
>
> Further details of the PoC attack at:
> http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
>
>
> This patch loads the PIE linked executable in a different area than the
> libraries. The successful fix can be tested with a simple pie compiled
> application:
>
>
> $ ./show_mmaps_pie
> 54859ccd6000-54859ccd7000 r-xp ... /tmp/show_mmaps_pie
> 54859ced6000-54859ced7000 r--p ... /tmp/show_mmaps_pie
> 54859ced7000-54859ced8000 rw-p ... /tmp/show_mmaps_pie
> 7f75be764000-7f75be91f000 r-xp ... /lib/x86_64-linux-gnu/libc.so.6
> 7f75be91f000-7f75beb1f000 ---p ... /lib/x86_64-linux-gnu/libc.so.6
> 7f75beb1f000-7f75beb23000 r--p ... /lib/x86_64-linux-gnu/libc.so.6
> 7f75beb23000-7f75beb25000 rw-p ... /lib/x86_64-linux-gnu/libc.so.6
> 7f75beb25000-7f75beb2a000 rw-p ...
> 7f75beb2a000-7f75beb4d000 r-xp ... /lib64/ld-linux-x86-64.so.2
> 7f75bed45000-7f75bed46000 rw-p ...
> 7f75bed46000-7f75bed47000 r-xp ...
> 7f75bed47000-7f75bed4c000 rw-p ...
> 7f75bed4c000-7f75bed4d000 r--p ... /lib64/ld-linux-x86-64.so.2
> 7f75bed4d000-7f75bed4e000 rw-p ... /lib64/ld-linux-x86-64.so.2
> 7f75bed4e000-7f75bed4f000 rw-p ...
> 7fffb3741000-7fffb3762000 rw-p ... [stack]
> 7fffb377b000-7fffb377d000 r--p ... [vvar]
> 7fffb377d000-7fffb377f000 r-xp ... [vdso]
>
>
> Once corrected, the PIE linked application is loaded in a different area.
Thanks for working on this!
>
> We updated the "Fixing Offset2lib weakness" page:
> http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html
>
>
> Signed-off-by: Hector Marco-Gisbert
> Signed-off-by: Ismael Ripoll
Acked-by: Kees Cook
>
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 97d07ed..ee7ea7e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,7 +1,6 @@
> config ARM
> bool
> default y
> - select ARCH_BINFMT_ELF_RANDOMIZE_PIE
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAVE_CUSTOM_GPIO_H
> diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
> index afb9caf..6755cd8 100644
> --- a/arch/arm/include/asm/elf.h
> +++ b/arch/arm/include/asm/elf.h
> @@ -115,7 +115,8 @@ int dump_task_regs(struct task_struct *t, elf_gregset_t
> *elfregs);
> the loader. We need to make sure that it is out of the way of the
> program
> that it will "exec", and that there is sufficient room for the brk. */
>
> -#define ELF_ET_DYN_BASE(2 * TASK_SIZE / 3)
> +extern unsigned long randomize_et_dyn(unsigned long base);
> +#define ELF_ET_DYN_BASE(randomize_et_dyn(2 * TASK_SIZE / 3))
>
> /* When the program starts, a1 contains a pointer to a function to be
> registered with atexit, as per the SVR4 ABI. A value of 0 means we
> diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
> index 5e85ed3..9177100 100644
> --- a/arch/arm/mm/mmap.c
> +++ b/arch/arm/mm/mmap.c
> @@ -30,6 +30,17 @@ static int mmap_is_legacy(void)
> return sysctl_legacy_va_layout;
> }
>
> +static unsigned long mmap_rnd(void)
> +{
> + unsigned long rnd = 0;
> +
> + /* 8 bits of randomness in 20 address space bits */
> + if (current->flags & PF_RANDOMIZE)
> + rnd = (long)get_random_int() % (1 << 8);
> +
> + return rnd << PAGE_SHIFT;
> +}
> +
> static unsigned long mmap_base(unsigned long rnd)
> {
> unsigned long gap = rlimit(RLIMIT_STACK);
> @@ -230,3 +241,13 @@ int devmem_is_allowed(unsigned long pfn)
> }
>
> #endif
> +
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + return (ret > base) ? ret : base;
> +}
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b1f9a20..5580d90 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1,6 +1,5 @@
> config ARM64
> def_bool y
> - select ARCH_BINFMT_ELF_RANDOMIZE_PIE
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_HAS_SG_CHAIN
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 1f65be3..01d3aab 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch
[PATCH RFC] powerpc/powernv: Introduce kernel param to control fastsleep workaround behavior
Fastsleep is one of the idle state which cpuidle subsystem currently
uses on power8 machines. In this state L2 cache is brought down to a
threshold voltage. Therefore when the core is in fastsleep, the
communication between L2 and L3 needs to be fenced. But there is a bug
in the current power8 chips surrounding this fencing. OPAL provides an
interface to workaround this bug, and in the current implementation,
every time before a core enters fastsleep OPAL call is made to 'apply'
the workarond and when the core wakes up from fastsleep OPAL call is
made to 'undo' the workaround. These OPAL calls account for roughly
4000 cycles everytime the core has to enter or wakeup from fastsleep.
The other alternative is to apply this workaround once at boot, and not
undo it at all. While this would quicken fastsleep entry/wakeup path,
running with workaround applied always can delay L2 fault detection.
This patch adds a new kernel paramerter
pnv_fastsleep_workaround_once, which can be used to override
the default behavior and apply the workaround once at boot and not undo
it.
Signed-off-by: Shreyas B. Prabhu
CC: Michael Ellerman
CC: Paul Mackerras
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@lists.ozlabs.org
---
Documentation/kernel-parameters.txt| 4 +++
arch/powerpc/include/asm/opal.h| 8 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/setup.c | 45 +-
4 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index bfcb1a6..006863b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2857,6 +2857,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
autoconfiguration.
Ranges are in pairs (memory base and size).
+ pnv_fastsleep_workaround_once=
+ [BUGS=ppc64] Tells kernel to apply fastsleep workaround
+ once at boot.
+
ports= [IP_VS_FTP] IPVS ftp helper module
Default is 21.
Up to 8 (IP_VS_APP_MAX_PORTS) ports
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9ee0a30..8bea8fc 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -180,6 +180,13 @@ struct opal_sg_list {
#define OPAL_PM_WINKLE_ENABLED 0x0004
#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008
+/*
+ * OPAL_CONFIG_CPU_IDLE_STATE parameters
+ */
+#define OPAL_CONFIG_IDLE_FASTSLEEP 1
+#define OPAL_CONFIG_IDLE_UNDO 0
+#define OPAL_CONFIG_IDLE_APPLY 1
+
#ifndef __ASSEMBLY__
#include
@@ -924,6 +931,7 @@ int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
int64_t opal_slw_set_reg(uint64_t cpu_pir, uint64_t sprn, uint64_t val);
+int64_t opal_config_cpu_idle_state(uint64_t state, uint64_t flag);
int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t msg_len);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 0509bca..84a20bb 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -283,6 +283,7 @@ OPAL_CALL(opal_sensor_read,
OPAL_SENSOR_READ);
OPAL_CALL(opal_get_param, OPAL_GET_PARAM);
OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
OPAL_CALL(opal_handle_hmi, OPAL_HANDLE_HMI);
+OPAL_CALL(opal_config_cpu_idle_state, OPAL_CONFIG_CPU_IDLE_STATE);
OPAL_CALL(opal_slw_set_reg,OPAL_SLW_SET_REG);
OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index d2de7d5..21dde6c 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -405,6 +406,20 @@ u32 pnv_get_supported_cpuidle_states(void)
}
EXPORT_SYMBOL_GPL(pnv_get_supported_cpuidle_states);
+u8 pnv_apply_fastsleep_workaround_once;
+
+static int __init pnv_fastsleep_workaround_once(char *str)
+{
+ pnv_apply_fastsleep_workaround_once = 1;
+ return 0;
+}
+early_param("pnv_fastsleep_workaround_once", pnv_fastsleep_workaround_once);
+
+static void __init pnv_fastsleep_workaround_apply(void *info)
+{
+ opal_config_cpu_idle_state(OPAL_CONFIG_IDLE_FASTSLEEP,
+ OPAL_CONFIG_IDLE_AP
Re: [v2] pseries/iommu: remove iommu device references via bus notifier
On 23.02.2015 [13:27:24 +1100], Michael Ellerman wrote:
> On Sat, 2015-21-02 at 19:00:50 UTC, Nishanth Aravamudan wrote:
> > On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > > On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> > > > After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
> > > > refcnt on the kobject backing the IOMMU group for a PCI device is
> > > > elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
> > > > set_iommu_table_base_and_group). When we go to dlpar a multi-function
> > > > PCI device out:
> > > >
> > > > iommu_reconfig_notifier ->
> > > > iommu_free_table ->
> > > > iommu_group_put
> > > > BUG_ON(tbl->it_group)
> > > >
> > > > We trip this BUG_ON, because there are still references on the table, so
> > > > it is not freed. Fix this by also adding a bus notifier identical to
> > > > PowerNV for pSeries.
> > >
> > > Please put it somewhere common, arch/powerpc/kernel/iommu.c perhaps, and
> > > just
> > > add a second machine_init_call() for pseries.
> >
> > How does this look? Only compile-tested with CONFIG_IOMMU_API on/off so
> > far, waiting for access to the test LPAR (should have it on Monday).
>
> Yeah that looks better, thanks.
>
> It probably doesn't build with CONFIG_PCI=n though, but I don't think
> CONFIG_PCI=n builds anyway.
Indeed it doesn't. Started looking at CONFIG_PCI=n and immediately hit
the following:
PCI_MSI depends on PCI
PCI can be manually turned off
PSERIES (and a bunch of other platforms) select PCI_MSI
So you end up with PCI_MSI on and PCI off and the build breaks.
Should the platforms depend on PCI_MSI instead?
Per the Documentation:
"select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set."
Thanks,
Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC/RFT][RESEND] powerpc: move cacheinfo sysfs to generic cacheinfo infrastructure
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e ("drivers: base: support cpu cache information
interface to userspace via sysfs")
Signed-off-by: Sudeep Holla
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Anshuman Khandual
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/cacheinfo.c | 811 +---
arch/powerpc/kernel/cacheinfo.h | 8 -
arch/powerpc/kernel/sysfs.c | 12 +-
3 files changed, 91 insertions(+), 740 deletions(-)
delete mode 100644 arch/powerpc/kernel/cacheinfo.h
Hi,
This patch is not tested. Last time Anshuman tested, he had seen issues.
The core driver has changed a lot after that. Since PPC depends a lot
on DT for cache information, there might be issues in the core later
which I could not identify with ARM/ARM64. It would be much appreciable
if someone help me in testing and fixing those so that PPC can migrate
to new/common cacheinfo infrastructure. This resend is rebased on v4.0-rc1
Regards,
Sudeep
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index ae77b7e59889..6845eb7fcc18 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -10,38 +10,10 @@
* 2 as published by the Free Software Foundation.
*/
+#include
#include
-#include
#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-
-#include "cacheinfo.h"
-
-/* per-cpu object for tracking:
- * - a "cache" kobject for the top-level directory
- * - a list of "index" objects representing the cpu's local cache hierarchy
- */
-struct cache_dir {
- struct kobject *kobj; /* bare (not embedded) kobject for cache
- * directory */
- struct cache_index_dir *index; /* list of index objects */
-};
-
-/* "index" object: each cpu's cache directory has an index
- * subdirectory corresponding to a cache object associated with the
- * cpu. This object's lifetime is managed via the embedded kobject.
- */
-struct cache_index_dir {
- struct kobject kobj;
- struct cache_index_dir *next; /* next index in parent directory */
- struct cache *cache;
-};
/* Template for determining which OF properties to query for a given
* cache type */
@@ -60,11 +32,6 @@ struct cache_type_info {
const char *nr_sets_prop;
};
-/* These are used to index the cache_type_info array. */
-#define CACHE_TYPE_UNIFIED 0
-#define CACHE_TYPE_INSTRUCTION 1
-#define CACHE_TYPE_DATA2
-
static const struct cache_type_info cache_type_info[] = {
{
/* PowerPC Processor binding says the [di]-cache-*
@@ -92,231 +59,82 @@ static const struct cache_type_info cache_type_info[] = {
},
};
-/* Cache object: each instance of this corresponds to a distinct cache
- * in the system. There are separate objects for Harvard caches: one
- * each for instruction and data, and each refers to the same OF node.
- * The refcount of the OF node is elevated for the lifetime of the
- * cache object. A cache object is released when its shared_cpu_map
- * is cleared (see cache_cpu_clear).
- *
- * A cache object is on two lists: an unsorted global list
- * (cache_list) of cache objects; and a singly-linked list
- * representing the local cache hierarchy, which is ordered by level
- * (e.g. L1d -> L1i -> L2 -> L3).
- */
-struct cache {
- struct device_node *ofnode;/* OF node for this cache, may be cpu */
- struct cpumask shared_cpu_map; /* online CPUs using this cache */
- int type; /* split cache disambiguation */
- int level; /* level not explicit in device tree */
- struct list_head list; /* global list of cache objects */
- struct cache *next_local; /* next cache of >= level */
-};
-
-static DEFINE_PER_CPU(struct cache_dir *, cache_dir_pcpu);
-
-/* traversal/modification of this list occurs only at cpu hotplug time;
- * access is serialized by cpu hotplug locking
- */
-static LIST_HEAD(cache_list);
-
-static struct cache_index_dir *kobj_to_cache_index_dir(struct kobject *k)
-{
- return container_of(k, struct cache_index_dir, kobj);
-}
-
-static const char *cache_type_string(const struct cache *cache)
+static inline int get_cacheinfo_idx(enum cache_type type)
{
- return cache_type_info[cache->type].name;
-}
-
-static void cache_init(struct cache *cache, int type, int level,
- struct device_node *ofnode)
-{
- cache->type = type;
- cache->level = level;
- cache->ofnode = of_node_get(ofnode);
- INIT_LIST_HEAD(&cache->list);
- list_add(&cache->list, &cache_list);
-}
-
-static struct cache *new_cache(int type, int level, struct device_node *ofnode)
-{
- struct cache *cache;
-
- cache = kzalloc(sizeof(*cache), GFP_KERNEL);
- if (cache)
-
[PATCH] Changes in therm_adt746x.c in order to support all three sensors. This should avoid overheating of components such as the harddisk inside singe fan driven powerbooks/ibooks such as the 12inch
Signed-off-by: Thomas Haschka
---
drivers/macintosh/therm_adt746x.c | 158 +-
1 file changed, 121 insertions(+), 37 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c
b/drivers/macintosh/therm_adt746x.c
index f433521..a29f15d 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -1,7 +1,8 @@
/*
* Device driver for the i2c thermostat found on the iBook G4, Albook G4
*
- * Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
+ * Copyright (C) 2003, 2004, 2015
+ * Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt, Thomas Haschka
*
* Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
* http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
@@ -45,8 +46,8 @@ static u8 REM_CONTROL[2] = {0x00, 0x40};
static u8 FAN_SPEED[2] = {0x28, 0x2a};
static u8 FAN_SPD_SET[2] = {0x30, 0x31};
-static u8 default_limits_local[3] = {70, 50, 70};/* local, sensor1,
sensor2 */
-static u8 default_limits_chip[3] = {80, 65, 80};/* local, sensor1, sensor2
*/
+static u8 default_limits_local[3] = {45, 50, 70}; /* local, sensor1, sensor2 */
+static u8 default_limits_chip[3] = {80, 65, 80}; /* local, sensor1, sensor2 */
static const char *sensor_location[3] = { "?", "?", "?" };
static int limit_adjust;
@@ -225,47 +226,114 @@ static void display_stats(struct thermostat *th)
static void update_fans_speed (struct thermostat *th)
{
- int lastvar = 0; /* last variation, for iBook */
- int i = 0;
+
+ /* Multfan Laptops */
+ if ( th->type == ADT7460 ) {
+ int lastvar = 0; /* last variation, for iBook */
+ int i = 0;
+ /* we don't care about local sensor, so we start at sensor 1 */
+ for (i = 1; i < 3; i++) {
+ int started = 0;
+ int fan_number = (th->type == ADT7460 && i == 2);
+ int var = th->temps[i] - th->limits[i];
+
+ if (var > -1) {
+ int step = (255 - fan_speed) / 7;
+ int new_speed = 0;
- /* we don't care about local sensor, so we start at sensor 1 */
- for (i = 1; i < 3; i++) {
- int started = 0;
- int fan_number = (th->type == ADT7460 && i == 2);
- int var = th->temps[i] - th->limits[i];
+ /* hysteresis : change fan speed only if variation is
+* more than two degrees */
+ if (abs(var - th->last_var[fan_number]) < 2)
+ continue;
+
+ started = 1;
+ new_speed = fan_speed + ((var-1)*step);
+
+ if (new_speed < fan_speed)
+ new_speed = fan_speed;
+ if (new_speed > 255)
+ new_speed = 255;
+
+ if (verbose)
+ printk(KERN_DEBUG
+ "adt746x: Setting fans speed"
+ " to %d "
+ "(limit exceeded by %d on %s)\n",
+ new_speed, var,
+ sensor_location[fan_number+1]);
+ write_both_fan_speed(th, new_speed);
+ th->last_var[fan_number] = var;
+ } else if (var < -2) {
+/* don't stop fan if sensor2 is cold and sensor1 is not
+* so cold (lastvar >= -1) */
+ if (i == 2 && lastvar < -1) {
+ if (th->last_speed[fan_number] != 0)
+ if (verbose)
+ printk(KERN_DEBUG
+ "adt746x:"
+ " Stopping "
+ "fans.\n");
+ write_both_fan_speed(th, 0);
+ }
+ }
+ lastvar = var;
+
+ if (started)
+ return; /* we don't want to re-stop the fan
+* if sensor1 is heating and sensor2
+* is not */
+ }
+ } else {
+/*single fan laptops i.e. 12 inch powerbook/ibook*/
+ int lastvar = 0; /* last variation, for iBook */
+ int i = 0;
+ int var = 0;
+
Re: Problems with DRI on Acube Sam460 AMCC 460ex board
On 2/23/2015 9:03 AM, Julian Margetson wrote:
On 2/18/2015 10:56 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( -> 0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail mapping
irq
[6.487530] Unable to handle kernel paging request for data at address
0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94 (unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon>
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
So the bug is in the 4xx MSI code, and has always been there, in fact I don't
see how that code has *ever* worked. The commit you bisected to just caused the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
list_for_each_entry(entry, &dev->msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
- if (int_no >= 0)
- break;
if (int_no < 0) {
- pr_debug("%s: fail allocating msi interrupt\n",
- __func__);
+ pr_warn("%s: fail allocating msi interrupt\n",
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
if (virq == NO_IRQ) {
Thanks.
This works with 3.17-rc1. Will try with the 3.18 Branch .
OK great.
Any ideas why drm is not working ? (It never worked) .
No sorry. You might have more luck if you post a new thread to the dri list.
[5.809802] Linux agpgart interface v0.103
[6.137893] [drm] Initialized drm 1.1.0 20060810
[6.439872] snd_hda_intel 0001:81:00.1: enabling device ( -> 0002)
[6.508544] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
I'm curious why it's failing to allocate MSIs. Possibly it's just run out.
Can you post the output of 'cat /proc/interrupts'?
cheers
cat /proc/interrupts
CPU0
18: 0 UIC 11 Edge L2C
19: 0 UIC 12 Level snd_ice1724
20: 1 UIC 16 Level
21:306 UIC 17 Level snd_hda_intel
22: 12212 UIC 0 Level 0002:00:04.0
25:619 UIC 6 Level MAL TX EOB
26:937 UIC 7 Level MAL RX EOB
27: 0 UIC 3 Level MAL SERR
28: 0 UIC 4 Level MAL TX DE
31: 0 UIC 5 Level MAL RX DE
32: 6607 UIC 29 Level ehci_hcd:usb1
33: 1 UIC 30 Level ohci_hcd:usb2
38: 19 UIC 2 Level IBM IIC
39: 0 UIC 3 Level IBM IIC
40: 0 UIC 16 Level EMAC
44: 0 UIC 0 Edge aerdrv
45: 0 UIC 2 Edge aerdrv
LOC: 117318 Local timer interrupts for timer event device
LOC: 53 Local timer interrupts for others
SPU: 0 Spurious interru
Re: [PATCH 1/1]: thermal driver therm_adt746.c
On 02/23/2015 12:58 PM, Thomas Haschka wrote: > Hi everyone, > > The current driver linux/drivers/macintosh/therm_adt746x.c does not take the > HDD BUTTOMSIDE sensor into account. It actually should as the 12" Powerbooks > and IBooks are build in a way that the airflow cools the harddrive and > components around it. Actually there are air intake openings just beneath the > Harddrive. If you experiance hot enviromental temperatures as I did in summer > on certain occations, you will find out that in MacOSX the fan spins up while > it doesn't in linux. As this probably causes harddrives, and maybe other > components to fail early I think this should be regarded as a fix to a severe > bug. > > Hence, I created this patch for single fan 12" Albooks, Ibooks etc. I would happy to give it a try on the "brand new" iBook G4 I just got this week-end but I would need you to reformat your patch. Could you please send it again to the mailing using : git send-email --to linuxppc-dev@lists.ozlabs.org my.patch You might want to run the script ./scripts/checkpatch.pl on the patch file before sending. Cheers, C. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 5/5] selftests, powerpc: Add test for VPHN
The goal is to verify vphn_unpack_associativity() parses VPHN numbers
correctly. We feed it with a variety of input values and compare with
expected results.
PAPR+ does not say much about VPHN parsing: I came up with a list of
tests that check many simple cases and some corner ones. I wouldn't
dare to say the list is exhaustive though.
Signed-off-by: Greg Kurz
---
tools/testing/selftests/powerpc/Makefile |2
tools/testing/selftests/powerpc/utils.h |1
tools/testing/selftests/powerpc/vphn/.gitignore |1
tools/testing/selftests/powerpc/vphn/Makefile | 15 +
tools/testing/selftests/powerpc/vphn/parse-vphn.c | 403 +
tools/testing/selftests/powerpc/vphn/vphn.c |1
tools/testing/selftests/powerpc/vphn/vphn.h |1
7 files changed, 423 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/vphn/.gitignore
create mode 100644 tools/testing/selftests/powerpc/vphn/Makefile
create mode 100644 tools/testing/selftests/powerpc/vphn/parse-vphn.c
create mode 12 tools/testing/selftests/powerpc/vphn/vphn.c
create mode 12 tools/testing/selftests/powerpc/vphn/vphn.h
diff --git a/tools/testing/selftests/powerpc/Makefile
b/tools/testing/selftests/powerpc/Makefile
index 1d5e7ad..476b8dd 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -13,7 +13,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror
-DGIT_VERSION='"$(GIT_VERSION)"' -I$(CUR
export CC CFLAGS
-TARGETS = pmu copyloops mm tm primitives stringloops
+TARGETS = pmu copyloops mm tm primitives stringloops vphn
endif
diff --git a/tools/testing/selftests/powerpc/utils.h
b/tools/testing/selftests/powerpc/utils.h
index a93777a..2ec455e 100644
--- a/tools/testing/selftests/powerpc/utils.h
+++ b/tools/testing/selftests/powerpc/utils.h
@@ -15,6 +15,7 @@ typedef signed long long s64;
/* Just for familiarity */
typedef uint32_t u32;
+typedef uint16_t u16;
typedef uint8_t u8;
diff --git a/tools/testing/selftests/powerpc/vphn/.gitignore
b/tools/testing/selftests/powerpc/vphn/.gitignore
new file mode 100644
index 000..dd3039a
--- /dev/null
+++ b/tools/testing/selftests/powerpc/vphn/.gitignore
@@ -0,0 +1 @@
+parse-vphn
diff --git a/tools/testing/selftests/powerpc/vphn/Makefile
b/tools/testing/selftests/powerpc/vphn/Makefile
new file mode 100644
index 000..f1f7bd5
--- /dev/null
+++ b/tools/testing/selftests/powerpc/vphn/Makefile
@@ -0,0 +1,15 @@
+PROGS := parse-vphn
+
+all: $(PROGS)
+
+$(PROGS): ../harness.c
+
+run_tests: all
+ @-for PROG in $(PROGS); do \
+ ./$$PROG; \
+ done;
+
+clean:
+ rm -f $(PROGS) *.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/vphn/parse-vphn.c
b/tools/testing/selftests/powerpc/vphn/parse-vphn.c
new file mode 100644
index 000..49b6c43
--- /dev/null
+++ b/tools/testing/selftests/powerpc/vphn/parse-vphn.c
@@ -0,0 +1,403 @@
+#include
+#include
+#include "utils.h"
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define cpu_to_be32(x) bswap_32(x)
+#define be32_to_cpu(x) bswap_32(x)
+#define be16_to_cpup(x)bswap_16(*x)
+#define cpu_to_be64(x) bswap_64(x)
+#else
+#define cpu_to_be32(x) (x)
+#define be32_to_cpu(x) (x)
+#define be16_to_cpup(x)(*x)
+#define cpu_to_be64(x) (x)
+#endif
+
+#include "vphn.c"
+
+static struct test {
+ char *descr;
+ long input[VPHN_REGISTER_COUNT];
+ u32 expected[VPHN_ASSOC_BUFSIZE];
+} all_tests[] = {
+ {
+ "vphn: no data",
+ {
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ },
+ {
+ 0x
+ }
+ },
+ {
+ "vphn: 1 x 16-bit value",
+ {
+ 0x8001,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ },
+ {
+ 0x0001,
+ 0x0001
+ }
+ },
+ {
+ "vphn: 2 x 16-bit values",
+ {
+ 0x80018002,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ },
+ {
+ 0x0002,
+ 0x0001,
+ 0x0002
+ }
+
[PATCH v3 4/5] powerpc/vphn: parsing code rewrite
The current VPHN parsing logic has some flaws that this patch aims to fix:
1) when the value 0x is read, the value 0x gets added to the
the output list and its element count isn't incremented. This is wrong.
According to PAPR+ the domain identifiers are packed into a sequence
terminated by the "reserved value of all ones". This means that 0x
is a stream terminator.
2) the combination of byteswaps and casts make the code hardly readable.
Let's parse the stream one 16-bit field at a time instead.
3) it is assumed that the hypercall returns 12 32-bit values packed into
6 64-bit registers. According to PAPR+, the domain identifiers may be
streamed as 16-bit values. Let's increase the number of expected numbers
to 24.
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/vphn.c | 54 +---
arch/powerpc/mm/vphn.h |6 +++--
2 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/mm/vphn.c b/arch/powerpc/mm/vphn.c
index c49ed51..5f8ef50 100644
--- a/arch/powerpc/mm/vphn.c
+++ b/arch/powerpc/mm/vphn.c
@@ -2,44 +2,64 @@
#include "vphn.h"
/*
- * Convert the associativity domain numbers returned from the hypervisor
- * to the sequence they would appear in the ibm,associativity property.
+ * The associativity domain numbers are returned from the hypervisor as a
+ * stream of mixed 16-bit and 32-bit fields. The stream is terminated by the
+ * special value of "all ones" (aka. 0x) and its size may not exceed 48
+ * bytes.
+ *
+ *--- 16-bit fields -->
+ * _
+ * | 0 | 1 | 2 | 3 | be_packed[0]
+ * --+-+-+--
+ * _
+ * | 4 | 5 | 6 | 7 | be_packed[1]
+ * -
+ *...
+ * _
+ * | 20 | 21 | 22 | 23 | be_packed[5]
+ * -
+ *
+ * Convert to the sequence they would appear in the ibm,associativity property.
*/
int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
{
__be64 be_packed[VPHN_REGISTER_COUNT];
int i, nr_assoc_doms = 0;
const __be16 *field = (const __be16 *) be_packed;
+ u16 last = 0;
+ bool is_32bit = false;
#define VPHN_FIELD_UNUSED (0x)
#define VPHN_FIELD_MSB (0x8000)
#define VPHN_FIELD_MASK(~VPHN_FIELD_MSB)
- /* Let's recreate the original stream. */
+ /* Let's fix the values returned by plpar_hcall9() */
for (i = 0; i < VPHN_REGISTER_COUNT; i++)
be_packed[i] = cpu_to_be64(packed[i]);
for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
- if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
- /* All significant fields processed, and remaining
-* fields contain the reserved value of all 1's.
-* Just store them.
+ u16 new = be16_to_cpup(field++);
+
+ if (is_32bit) {
+ /* Let's concatenate the 16 bits of this field to the
+* 15 lower bits of the previous field
*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- } else if (be16_to_cpup(field) & VPHN_FIELD_MSB) {
+ unpacked[++nr_assoc_doms] =
+ cpu_to_be32(last << 16 | new);
+ is_32bit = false;
+ } else if (new == VPHN_FIELD_UNUSED)
+ /* This is the list terminator */
+ break;
+ else if (new & VPHN_FIELD_MSB) {
/* Data is in the lower 15 bits of this field */
- unpacked[i] = cpu_to_be32(
- be16_to_cpup(field) & VPHN_FIELD_MASK);
- field++;
- nr_assoc_doms++;
+ unpacked[++nr_assoc_doms] =
+ cpu_to_be32(new & VPHN_FIELD_MASK);
} else {
/* Data is in the lower 15 bits of this field
* concatenated with the next 16 bit field
*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- nr_assoc_doms++;
+ last = new;
+ is_32bit = true;
}
}
diff --git a/arch/powerpc/mm/vphn.h b/arch/powerpc/mm/vphn.h
index 96af9a4..fe8b780 100644
--- a/arch/powerpc/mm/vphn.h
+++ b/arch/powerpc/mm/vphn.h
@@ -6,10 +6,10 @@
#define VPHN_REGISTER_COUNT 6
/*
- * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
- * the complete property we have to add the length in the first cell.
+ * 6 64-bit registers unpacked into up to 24 be32 associativity values. To
+ * form the complete property we have to
[PATCH v3 3/5] powerpc/vphn: move VPHN parsing logic to a separate file
The goal behind this patch is to be able to write userland tests for the
VPHN parsing code.
Suggested-by: Michael Ellerman
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/Makefile |1 +
arch/powerpc/mm/numa.c | 61 ++
arch/powerpc/mm/vphn.c | 50 ++
arch/powerpc/mm/vphn.h | 16
4 files changed, 70 insertions(+), 58 deletions(-)
create mode 100644 arch/powerpc/mm/vphn.c
create mode 100644 arch/powerpc/mm/vphn.h
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 438dcd3..9c8770b 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_40x) += 40x_mmu.o
obj-$(CONFIG_44x) += 44x_mmu.o
obj-$(CONFIG_PPC_FSL_BOOK3E) += fsl_booke_mmu.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
+obj-$(CONFIG_PPC_SPLPAR) += vphn.o
obj-$(CONFIG_PPC_MM_SLICES)+= slice.o
obj-y += hugetlbpage.o
ifeq ($(CONFIG_HUGETLB_PAGE),y)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 59196c5..c68471c 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1177,6 +1177,9 @@ u64 memory_hotplug_max(void)
/* Virtual Processor Home Node (VPHN) support */
#ifdef CONFIG_PPC_SPLPAR
+
+#include "vphn.h"
+
struct topology_update_data {
struct topology_update_data *next;
unsigned int cpu;
@@ -1247,64 +1250,6 @@ static int update_cpu_associativity_changes_mask(void)
return cpumask_weight(changes);
}
-/* The H_HOME_NODE_ASSOCIATIVITY h_call returns 6 64-bit registers.
- */
-#define VPHN_REGISTER_COUNT 6
-
-/*
- * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
- * the complete property we have to add the length in the first cell.
- */
-#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)
-
-/*
- * Convert the associativity domain numbers returned from the hypervisor
- * to the sequence they would appear in the ibm,associativity property.
- */
-static int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
-{
- __be64 be_packed[VPHN_REGISTER_COUNT];
- int i, nr_assoc_doms = 0;
- const __be16 *field = (const __be16 *) be_packed;
-
-#define VPHN_FIELD_UNUSED (0x)
-#define VPHN_FIELD_MSB (0x8000)
-#define VPHN_FIELD_MASK(~VPHN_FIELD_MSB)
-
- /* Let's recreate the original stream. */
- for (i = 0; i < VPHN_REGISTER_COUNT; i++)
- be_packed[i] = cpu_to_be64(packed[i]);
-
- for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
- if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
- /* All significant fields processed, and remaining
-* fields contain the reserved value of all 1's.
-* Just store them.
-*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- } else if (be16_to_cpup(field) & VPHN_FIELD_MSB) {
- /* Data is in the lower 15 bits of this field */
- unpacked[i] = cpu_to_be32(
- be16_to_cpup(field) & VPHN_FIELD_MASK);
- field++;
- nr_assoc_doms++;
- } else {
- /* Data is in the lower 15 bits of this field
-* concatenated with the next 16 bit field
-*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- nr_assoc_doms++;
- }
- }
-
- /* The first cell contains the length of the property */
- unpacked[0] = cpu_to_be32(nr_assoc_doms);
-
- return nr_assoc_doms;
-}
-
/*
* Retrieve the new associativity information for a virtual processor's
* home node.
diff --git a/arch/powerpc/mm/vphn.c b/arch/powerpc/mm/vphn.c
new file mode 100644
index 000..c49ed51
--- /dev/null
+++ b/arch/powerpc/mm/vphn.c
@@ -0,0 +1,50 @@
+#include
+#include "vphn.h"
+
+/*
+ * Convert the associativity domain numbers returned from the hypervisor
+ * to the sequence they would appear in the ibm,associativity property.
+ */
+int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
+{
+ __be64 be_packed[VPHN_REGISTER_COUNT];
+ int i, nr_assoc_doms = 0;
+ const __be16 *field = (const __be16 *) be_packed;
+
+#define VPHN_FIELD_UNUSED (0x)
+#define VPHN_FIELD_MSB (0x8000)
+#define VPHN_FIELD_MASK(~VPHN_FIELD_MSB)
+
+ /* Let's recreate the original stream. */
+ for (i = 0; i < VPHN_REGISTER_COUNT; i++)
+ be_packed[i] = cpu_to_be64(packed[i]);
+
+ for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
+ if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
+ /* All significant fields processe
[PATCH v3 2/5] powerpc/vphn: move endianness fixing to vphn_unpack_associativity()
The first argument to vphn_unpack_associativity() is a const long *, but the
parsing code expects __be64 values actually. Let's move the endian fixing
down for consistency.
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/numa.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 7a5bc21..59196c5 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1263,13 +1263,18 @@ static int update_cpu_associativity_changes_mask(void)
*/
static int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
{
+ __be64 be_packed[VPHN_REGISTER_COUNT];
int i, nr_assoc_doms = 0;
- const __be16 *field = (const __be16 *) packed;
+ const __be16 *field = (const __be16 *) be_packed;
#define VPHN_FIELD_UNUSED (0x)
#define VPHN_FIELD_MSB (0x8000)
#define VPHN_FIELD_MASK(~VPHN_FIELD_MSB)
+ /* Let's recreate the original stream. */
+ for (i = 0; i < VPHN_REGISTER_COUNT; i++)
+ be_packed[i] = cpu_to_be64(packed[i]);
+
for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
/* All significant fields processed, and remaining
@@ -1310,11 +1315,8 @@ static long hcall_vphn(unsigned long cpu, __be32
*associativity)
long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
u64 flags = 1;
int hwcpu = get_hard_smp_processor_id(cpu);
- int i;
rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu);
- for (i = 0; i < VPHN_REGISTER_COUNT; i++)
- retbuf[i] = cpu_to_be64(retbuf[i]);
vphn_unpack_associativity(retbuf, associativity);
return rc;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/5] VPHN parsing fixes
Michael, As suggested in... https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-February/124647.html ... I repost the whole series with an extra patch to implement selftests for VPHN (this is the only change between v2 and v3). Please review. --- Greg Kurz (5): powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API powerpc/vphn: move endianness fixing to vphn_unpack_associativity() powerpc/vphn: move VPHN parsing logic to a separate file powerpc/vphn: parsing code rewrite selftests, powerpc: Add test for VPHN arch/powerpc/mm/Makefile |1 arch/powerpc/mm/numa.c| 55 --- arch/powerpc/mm/vphn.c| 70 arch/powerpc/mm/vphn.h| 16 + tools/testing/selftests/powerpc/Makefile |2 tools/testing/selftests/powerpc/utils.h |1 tools/testing/selftests/powerpc/vphn/.gitignore |1 tools/testing/selftests/powerpc/vphn/Makefile | 15 + tools/testing/selftests/powerpc/vphn/parse-vphn.c | 403 + tools/testing/selftests/powerpc/vphn/vphn.c |1 tools/testing/selftests/powerpc/vphn/vphn.h |1 11 files changed, 513 insertions(+), 53 deletions(-) create mode 100644 arch/powerpc/mm/vphn.c create mode 100644 arch/powerpc/mm/vphn.h create mode 100644 tools/testing/selftests/powerpc/vphn/.gitignore create mode 100644 tools/testing/selftests/powerpc/vphn/Makefile create mode 100644 tools/testing/selftests/powerpc/vphn/parse-vphn.c create mode 12 tools/testing/selftests/powerpc/vphn/vphn.c create mode 12 tools/testing/selftests/powerpc/vphn/vphn.h -- Greg ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/5] powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API
The number of values returned by the H_HOME_NODE_ASSOCIATIVITY h_call deserves to be explicitly defined, for a better understanding of the code. Signed-off-by: Greg Kurz --- arch/powerpc/mm/numa.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 0257a7d..7a5bc21 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -1247,11 +1247,15 @@ static int update_cpu_associativity_changes_mask(void) return cpumask_weight(changes); } +/* The H_HOME_NODE_ASSOCIATIVITY h_call returns 6 64-bit registers. + */ +#define VPHN_REGISTER_COUNT 6 + /* * 6 64-bit registers unpacked into 12 32-bit associativity values. To form * the complete property we have to add the length in the first cell. */ -#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32) + 1) +#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1) /* * Convert the associativity domain numbers returned from the hypervisor @@ -1309,7 +1313,7 @@ static long hcall_vphn(unsigned long cpu, __be32 *associativity) int i; rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu); - for (i = 0; i < 6; i++) + for (i = 0; i < VPHN_REGISTER_COUNT; i++) retbuf[i] = cpu_to_be64(retbuf[i]); vphn_unpack_associativity(retbuf, associativity); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] cxl: Add explicit precision specifiers
On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote: > 24 of the %.16llx > matches are in drivers/misc/cxl/, so internal consistency wins. I think that's more an argument for changing all of the cx1 uses to "%016llx". ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1]: thermal driver therm_adt746.c
Hi everyone,
The current driver linux/drivers/macintosh/therm_adt746x.c does not take
the HDD BUTTOMSIDE sensor into account. It actually should as the 12"
Powerbooks and IBooks are build in a way that the airflow cools the
harddrive and components around it. Actually there are air intake openings
just beneath the Harddrive. If you experiance hot enviromental temperatures
as I did in summer on certain occations, you will find out that in MacOSX
the fan spins up while it doesn't in linux. As this probably causes
harddrives, and maybe other components to fail early I think this should be
regarded as a fix to a severe bug.
Hence, I created this patch for single fan 12" Albooks, Ibooks etc.
Further I changed the output /sys/devices/temperatures so that all 3
sensors are readable from this locations. The output is furhter multiplied
by 1000 in order correspond to the ranges printed by other sensor readings.
( This also makes the readings monitorable with tools such as xosview )
I sign this contribution as demanded, and hope that it will help keeping
several Powerbooks and Ibooks out there running a bit longer:
(a) The contribution was created in whole by me and I
have the right to submit it under the GPLv2
(Gnu Public License version 2)
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Thomas Haschka (hasc...@gmail.com)
--- linux/drivers/macintosh/therm_adt746x.c.orig 2015-02-23 12:19:03.98400 +0100
+++ linux/drivers/macintosh/therm_adt746x.c 2015-02-23 12:22:34.98000 +0100
@@ -1,7 +1,8 @@
/*
* Device driver for the i2c thermostat found on the iBook G4, Albook G4
*
- * Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
+ * Copyright (C) 2003, 2004, 2015
+ * Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt, Thomas Haschka
*
* Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
* http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
@@ -45,7 +46,7 @@ static u8 REM_CONTROL[2] = {0x00, 0x40};
static u8 FAN_SPEED[2] = {0x28, 0x2a};
static u8 FAN_SPD_SET[2] = {0x30, 0x31};
-static u8 default_limits_local[3] = {70, 50, 70};/* local, sensor1, sensor2 */
+static u8 default_limits_local[3] = {45, 50, 70};/* local, sensor1, sensor2 */
static u8 default_limits_chip[3] = {80, 65, 80};/* local, sensor1, sensor2 */
static const char *sensor_location[3] = { "?", "?", "?" };
@@ -225,59 +226,123 @@ static void display_stats(struct thermos
static void update_fans_speed (struct thermostat *th)
{
- int lastvar = 0; /* last variation, for iBook */
- int i = 0;
-
- /* we don't care about local sensor, so we start at sensor 1 */
- for (i = 1; i < 3; i++) {
- int started = 0;
- int fan_number = (th->type == ADT7460 && i == 2);
- int var = th->temps[i] - th->limits[i];
-
- if (var > -1) {
- int step = (255 - fan_speed) / 7;
- int new_speed = 0;
+
+ /* Multfan Laptops */
+ if ( th->type == ADT7460 ) {
+int lastvar = 0; /* last variation, for iBook */
+ int i = 0;
+/* we don't care about local sensor, so we start at sensor 1 */
+ for (i = 1; i < 3; i++) {
+ int started = 0;
+ int fan_number = (th->type == ADT7460 && i == 2);
+ int var = th->temps[i] - th->limits[i];
+
+ if (var > -1) {
+ int step = (255 - fan_speed) / 7;
+ int new_speed = 0;
/* hysteresis : change fan speed only if variation is
* more than two degrees */
- if (abs(var - th->last_var[fan_number]) < 2)
-continue;
-
- started = 1;
- new_speed = fan_speed + ((var-1)*step);
+ if (abs(var - th->last_var[fan_number]) < 2)
+continue;
- if (new_speed < fan_speed)
-new_speed = fan_speed;
- if (new_speed > 255)
-new_speed = 255;
+ started = 1;
+ new_speed = fan_speed + ((var-1)*step);
- if (verbose)
-printk(KERN_DEBUG "adt746x: Setting fans speed to %d "
- "(limit exceeded by %d on %s)\n",
- new_speed, var,
- sensor_location[fan_number+1]);
- write_both_fan_speed(th, new_speed);
- th->last_var[fan_number] = var;
- } else if (var < -2) {
+ if (new_speed < fan_speed)
+new_speed = fan_speed;
+ if (new_speed > 255)
+new_speed = 255;
+
+
Re: Build regressions/improvements in v4.0-rc1
On Monday 23 February 2015 11:28:12 Geert Uytterhoeven wrote: > On Mon, Feb 23, 2015 at 11:24 AM, Arnd Bergmann wrote: > > On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote: > >> On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote: > >> >> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of > >> >> > function 'copy_user_page' [-Werror=implicit-function-declaration]: > >> >> > => 266:2 > > > I checked the other architectures, and found that the same is missing on > > ARC, so we should add both: > > > > diff --git a/fs/Kconfig b/fs/Kconfig > > index ec35851e5b71..a24d496787d6 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -36,7 +36,7 @@ source "fs/nilfs2/Kconfig" > > config FS_DAX > > bool "Direct Access (DAX) support" > > depends on MMU > > - depends on !(ARM || MIPS || SPARC) > > + depends on !(ARC || ARM || MIPS || SH || SPARC) > > help > > Direct Access (DAX) can be used on memory-backed block devices. > > If the block device supports DAX and the filesystem supports DAX, > > > > > > It's also not implemented on c6x and blackfin, but both of them have > > MMU=n, so they are already excluded. > > Exactly. > > Acked-by: Geert Uytterhoeven Thanks, let me submit that as a proper patch with a changelog then. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] cxl: Add explicit precision specifiers
C99 says that a precision given as simply '.' with no following digits
or * should be interpreted as 0. The kernel's printf implementation,
however, treats this case as if the precision was omitted. C99 also
says that if both the precision and value are 0, no digits should be
printed. Even if the kernel followed C99 to the letter, I don't think
that would be particularly useful in these cases. For consistency with
most other format strings in the file, use an explicit precision of 16
and add a 0x prefix.
Signed-off-by: Rasmus Villemoes
---
What Joe said is of course technically true, but 24 of the %.16llx
matches are in drivers/misc/cxl/, so internal consistency wins.
drivers/misc/cxl/irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
index c8929c526691..4b73f4b9e7f1 100644
--- a/drivers/misc/cxl/irq.c
+++ b/drivers/misc/cxl/irq.c
@@ -147,7 +147,7 @@ static irqreturn_t cxl_irq(int irq, void *data, struct
cxl_irq_info *irq_info)
if (dsisr & CXL_PSL_DSISR_An_PE)
return handle_psl_slice_error(ctx, dsisr, irq_info->errstat);
if (dsisr & CXL_PSL_DSISR_An_AE) {
- pr_devel("CXL interrupt: AFU Error %.llx\n", irq_info->afu_err);
+ pr_devel("CXL interrupt: AFU Error 0x%.16llx\n",
irq_info->afu_err);
if (ctx->pending_afu_err) {
/*
@@ -158,7 +158,7 @@ static irqreturn_t cxl_irq(int irq, void *data, struct
cxl_irq_info *irq_info)
* probably best that we log them somewhere:
*/
dev_err_ratelimited(&ctx->afu->dev, "CXL AFU Error "
- "undelivered to pe %i: %.llx\n",
+ "undelivered to pe %i: 0x%.16llx\n",
ctx->pe, irq_info->afu_err);
} else {
spin_lock(&ctx->lock);
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support
On 02/21/2015 12:03 PM, Guenter Roeck wrote: > On 02/20/2015 11:14 PM, Cedric Le Goater wrote: >> On 02/21/2015 12:52 AM, Guenter Roeck wrote: >>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote: On 02/20/2015 05:52 PM, Guenter Roeck wrote: > On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote: >> Hello ! >> >> These patches rework the ibmpowernv driver to support the new device >> tree as proposed by this patchset on the skiboot mailing list : >> >> https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html >> >> They are based on Linux 3.19 and were tested on IBM Power and Open Power >> systems running trusty. >> >> The main issue is that the new device tree is incompatible with the >> previous ibmpowernv drivers. The consequence is no powernv sensors >> on systems with such a opal/linux configuration. >> > I don't think that would be acceptable. There must be lots of such > systems out there. Why does it have to be incompatible ? > Can't it support both the old and new versions ? I should have provided more explanation in the Linux patchset. Sorry for that. Here is the rationale behind this brutal code change. The initial ibmpowernv driver was designed in the early days of the powernv platform and the device tree it is using to expose the sensors has some limitations that makes it difficult to add new ones. The current layout of the device tree is also tightly coupled to IBM Power systems and their service processor (FSP). Open Power systems are different and need a different solution. It is to get more sensors out the P8 (and there are quite a few) that the OPAL patchset [1] proposes a new device tree. On the Linux side, it feels simpler to make a jump forward and break the compatibility than to maintain multiple branches of code just to keep alive an early v1 of the ibmpowernv driver. >>> >>> Would it possibly be appropriate to write a different driver for the new >>> device tree ? >> >> Sure. That is an option. >> >> There are no conflicts between the trees so we can live with two drivers >> using the same sensors/ root node. With time we will deprecate the initial >> one. >> > You lost me a bit. Are you saying you are going to replace the devicetree > properties with something that is incompatible but retain the same > compatible properties ? If so, how do you expect this to work ? > How do you expect to be able to determine which version of devicetree > is loaded, and thus which driver is needed ? > > I'll have to understand this way better. The link above doesn't explain > what the differences are, nor how the driver is supposed to know what > to do. Sure. My bad. I did not provide enough information in this RFC. Thanks for your patience ! The current hwmon driver ibmpowernv relies on a device tree provided by the OPAL firmware. Today, this tree has the following layout : ibm,opal/sensors/ |-- amb-temp#1-data | |-- compatible | |-- linux,phandle | |-- name | |-- phandle | `-- sensor-id |-- amb-temp#1-thrs | |-- compatible | |-- linux,phandle | |-- name | |-- phandle | `-- sensor-id |-- cooling-fan#10-data | |-- compatible | |-- linux,phandle | |-- name | |-- phandle | `-- sensor-id |-- cooling-fan#10-faulted | |-- compatible | |-- linux,phandle | |-- name | |-- phandle | `-- sensor-id |-- cooling-fan#10-thrs | |-- compatible | |-- linux,phandle | |-- name | |-- phandle | `-- sensor-id ... It has some limitations and we want to change it to something more flexible, giving us the ability to add new sensors. The new device tree layout is described here : https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html Both layouts use the same root node "ibm,opal/sensors" but the underlying nodes have nothing in common, which means that the current driver ibmpowernv will not 'see' any sensors on a system with an OPAL firmware exposing the new device tree. One will need new code for it. We have a few options to add support for this new tree : 1. modify the current driver to parse the two trees. It seems overly complex and the resulting code will be a pain to maintain. 2. add a new driver. As the two drivers can cohabitate, it is a viable solution. We will let the old driver rot in its corner and deprecate it one day. Kind of ugly to keep this code around. 3. replace the current driver with a new one. The simplest and most brutal but it also means we loose sensor support for IBM P8 systems running the old OPAL firmware. I don't think it is a problem as these
Re: Build regressions/improvements in v4.0-rc1
On Mon, Feb 23, 2015 at 11:24 AM, Arnd Bergmann wrote:
> On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote:
>> On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
>> >> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of
>> >> > function 'copy_user_page' [-Werror=implicit-function-declaration]: =>
>> >> > 266:2
> I checked the other architectures, and found that the same is missing on
> ARC, so we should add both:
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index ec35851e5b71..a24d496787d6 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -36,7 +36,7 @@ source "fs/nilfs2/Kconfig"
> config FS_DAX
> bool "Direct Access (DAX) support"
> depends on MMU
> - depends on !(ARM || MIPS || SPARC)
> + depends on !(ARC || ARM || MIPS || SH || SPARC)
> help
> Direct Access (DAX) can be used on memory-backed block devices.
> If the block device supports DAX and the filesystem supports DAX,
>
>
> It's also not implemented on c6x and blackfin, but both of them have
> MMU=n, so they are already excluded.
Exactly.
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.0-rc1
On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote: > On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote: > >> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of > >> > function 'copy_user_page' [-Werror=implicit-function-declaration]: => > >> > 266:2 > > > > DAX support was merged with 'depends on !(ARM || MIPS || SPARC)', so I don't > > see how this could happen. > > sh is not ARM, not MIPS, not SPARC, so...? I misread your email and thought this was still under arm-randconfig. I checked the other architectures, and found that the same is missing on ARC, so we should add both: diff --git a/fs/Kconfig b/fs/Kconfig index ec35851e5b71..a24d496787d6 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -36,7 +36,7 @@ source "fs/nilfs2/Kconfig" config FS_DAX bool "Direct Access (DAX) support" depends on MMU - depends on !(ARM || MIPS || SPARC) + depends on !(ARC || ARM || MIPS || SH || SPARC) help Direct Access (DAX) can be used on memory-backed block devices. If the block device supports DAX and the filesystem supports DAX, It's also not implemented on c6x and blackfin, but both of them have MMU=n, so they are already excluded. > >> sh-randconfig > > >> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > >> > declaration of function 'devm_gpiod_get' > >> > [-Werror=implicit-function-declaration]: => 55:2 > >> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > >> > declaration of function 'gpiod_direction_output' > >> > [-Werror=implicit-function-declaration]: => 61:2 > >> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > >> > declaration of function 'gpiod_set_value' > >> > [-Werror=implicit-function-declaration]: => 30:3 > > > > Something wrong in arch/sh/include/asm/gpio.h? the codec is only > > selectable when gpiolib is enabled, but the consumer.h header > > apparently does not get included here. > > I think it's an bad select, for which a patch has been available since > about 2 weeks. Ah, right. I was looking at linux-next, which has the fix, so I did not see the problem at first. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update all configs using savedefconfig
Hi Michael,
On Tue, Jan 20, 2015 at 8:05 AM, Michael Ellerman wrote:
> It looks like it's ~4 years since we updated some of these, so do a bulk
> update.
>
> Verified that the before and after generated configs are exactly the
> same.
Yep, that's guaranteed by the tool (modulo bugs).
> Which begs the question why update them? The answer is that it can be
> confusing when the stored defconfig drifts too far from the generated
> result.
And it becomes hard to update them, e.g. for enabling or disabling a single
option.
Now the big question is: do they still work?
Plainly ignoring any bugs introduced in the code, there are probably several
"select" statements that have been removed. 4 years ago, they automatically
selected some critical options, while now, they're no longer selected, causing
breakage.
I'm afraid the only safe way is (for all 108 defconfig files):
- start from the full .config file, as generated from the minimal defconfig
file in a source tree from 4 years ago,
- run "make oldconfig" (boring),
- run "make savedefconfig",
- update the minimal defconfig.
The boring step can be made a little bit less boring by making a diff between
the .config versions before and after running the first "make oldconfig",
and applying that to the later .config files first, but it's still a tedious
task, especially after 4 years. That's why I do this (for m68k) on every rc
release.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.0-rc1
On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
>> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of
>> > function 'copy_user_page' [-Werror=implicit-function-declaration]: =>
>> > 266:2
>
> DAX support was merged with 'depends on !(ARM || MIPS || SPARC)', so I don't
> see how this could happen.
sh is not ARM, not MIPS, not SPARC, so...?
>> sh-randconfig
>> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
>> > declaration of function 'devm_gpiod_get'
>> > [-Werror=implicit-function-declaration]: => 55:2
>> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
>> > declaration of function 'gpiod_direction_output'
>> > [-Werror=implicit-function-declaration]: => 61:2
>> > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
>> > declaration of function 'gpiod_set_value'
>> > [-Werror=implicit-function-declaration]: => 30:3
>
> Something wrong in arch/sh/include/asm/gpio.h? the codec is only
> selectable when gpiolib is enabled, but the consumer.h header
> apparently does not get included here.
I think it's an bad select, for which a patch has been available since
about 2 weeks.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.0-rc1
On Monday 23 February 2015 09:45:43 Geert Uytterhoeven wrote: > On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven > wrote: > > Below is the list of build error/warning regressions/improvements in > > v4.0-rc1[1] compared to v3.19[2]. > > > > Summarized: > > - build errors: +11/-10 > > > [1] http://kisskb.ellerman.id.au/kisskb/head/8494/ (256 out of 257 configs) > > [2] http://kisskb.ellerman.id.au/kisskb/head/8427/ (255 out of 257 configs) > > > > > > *** ERRORS *** > > > > 11 regressions: > > + /home/kisskb/slave/src/arch/arm/include/asm/atomic.h: error: #error SMP > > not supported on pre-ARMv6 CPUs: => 137:2 > > + /home/kisskb/slave/src/arch/arm/include/asm/cmpxchg.h: error: #error > > "SMP is not supported on this platform": => 114:2 > > arm-randconfig > > SMP does depend on CPU_V6K || CPU_V7 and on HAVE_SMP... strange... V6/V7 and the earlier V4/V5 are normally mutually exclusive, but we sometimes screw up the dependencies for some platform, in which case you can end up with a config that includes both and gives the above error. I'll have a look. I thought I'd fixed all the bugs we introduced in the merge window in yesterday's fixes branch. There is one known problem for mach-realview in this area, for which I have a fix. > > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of > > function 'copy_user_page' [-Werror=implicit-function-declaration]: => 266:2 DAX support was merged with 'depends on !(ARM || MIPS || SPARC)', so I don't see how this could happen. > sh-randconfig > > > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > > declaration of function 'devm_gpiod_get' > > [-Werror=implicit-function-declaration]: => 55:2 > > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > > declaration of function 'gpiod_direction_output' > > [-Werror=implicit-function-declaration]: => 61:2 > > + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit > > declaration of function 'gpiod_set_value' > > [-Werror=implicit-function-declaration]: => 30:3 Something wrong in arch/sh/include/asm/gpio.h? the codec is only selectable when gpiolib is enabled, but the consumer.h header apparently does not get included here. > s390-allyesconfig > s390-allmodconfig > parisc-allmodconfig > sh-allmodconfig > sh-allyesconfig > cris-allyesconfig > cris-allmodconfig > mips-allmodconfig > > > + error: asm9260_timer.c: undefined reference to `of_io_request_and_map': > > => .init.text+0x4014), .init.text+0x5c84) asm9260 is arm-specific, we probably need to refine the dependencies here to ensure that OF_ADDRESS is set. Need to think about what the best set of dependencies is. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.0-rc1
On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven
wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.0-rc1[1] compared to v3.19[2].
>
> Summarized:
> - build errors: +11/-10
> [1] http://kisskb.ellerman.id.au/kisskb/head/8494/ (256 out of 257 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/8427/ (255 out of 257 configs)
>
>
> *** ERRORS ***
>
> 11 regressions:
> + /home/kisskb/slave/src/arch/arm/include/asm/atomic.h: error: #error SMP
> not supported on pre-ARMv6 CPUs: => 137:2
> + /home/kisskb/slave/src/arch/arm/include/asm/cmpxchg.h: error: #error "SMP
> is not supported on this platform": => 114:2
arm-randconfig
SMP does depend on CPU_V6K || CPU_V7 and on HAVE_SMP... strange...
> + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of function
> 'copy_user_page' [-Werror=implicit-function-declaration]: => 266:2
sh-randconfig
> + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
> declaration of function 'devm_gpiod_get'
> [-Werror=implicit-function-declaration]: => 55:2
> + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
> declaration of function 'gpiod_direction_output'
> [-Werror=implicit-function-declaration]: => 61:2
> + /home/kisskb/slave/src/sound/soc/codecs/max98357a.c: error: implicit
> declaration of function 'gpiod_set_value'
> [-Werror=implicit-function-declaration]: => 30:3
s390-allyesconfig
s390-allmodconfig
parisc-allmodconfig
sh-allmodconfig
sh-allyesconfig
cris-allyesconfig
cris-allmodconfig
mips-allmodconfig
> + error: asm9260_timer.c: undefined reference to `of_io_request_and_map':
> => .init.text+0x4014), .init.text+0x5c84)
sparc64-allmodconfig
sparc-allmodconfig
> + error: book3s_64_vio_hv.c: undefined reference to `power7_wakeup_loss':
> => .text+0x408)
pseries_defconfig
> + error: smp.c: undefined reference to `.__flush_disable_L1': =>
> .text+0xb24)
powerpc-randconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20.02.2015 17:17, Sebastian Andrzej Siewior wrote: On 02/20/2015 04:10 PM, Paolo Bonzini wrote: On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote: On 02/20/2015 03:57 PM, Paolo Bonzini wrote: Yes, but large latencies just mean the code has to be rewritten (x86 doesn't anymore do event injection in an atomic regions for example). Until it is, using raw_spin_lock is correct. It does not sound like it. It sounds more like disabling interrupts to get things run faster and then limit it on a different corner to not blow up everything. "This patchset enables running KVM SMP guests with external interrupts on an underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel MPIC emulation could easily panic the kernel due to preemption when delivering IPIs and external interrupts, because of the openpic spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux". Max latencies was decreased "Max latency (us) 7062" and that is why this is done? For 8 us and possible DoS in case there are too many cpus? My understanding is that: 1) netperf can get you a BUG KVM, and raw_spinlock fixes that Actually, it's not just netperf. The bug triggers in the following scenarios: - running CPU intensive task (while true; do date; done) in SMP guest (even with 2 VCPUs) - running netperf in guest - running cyclictest in SMP guest May I please see a backtrace with context tracking which states where the interrupts / preemption gets disabled and where the lock was taken? Will do, I will get back to you as soon as I have it available. I will try and capture it using function trace. I'm not totally against this patch I just want to make sure this is not a blind raw conversation to shup up the warning the kernel throws. 2) cyclictest did not trigger the BUG, and you can also get reduced latency from using raw_spinlock. I think we agree that (2) is not a factor in accepting the patch. good :) Paolo Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
