Re: [PATCH] cpuidle/powernv: Enter fastsleep on checking if deep idle states are allowed
On Fri, 2014-09-12 at 16:31 +0530, Preeti U Murthy wrote: > Today the procfs interface /proc/sys/kernel/powersave-nap is used to control > entry into deep idle states beyond snooze. Check for the value of this > parameter before entering fastsleep. We already do this check for nap in > power7_idle(). > > Signed-off-by: Preeti U Murthy > --- > > drivers/cpuidle/cpuidle-powernv.c |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/cpuidle/cpuidle-powernv.c > b/drivers/cpuidle/cpuidle-powernv.c > index a64be57..b8ba52e 100644 > --- a/drivers/cpuidle/cpuidle-powernv.c > +++ b/drivers/cpuidle/cpuidle-powernv.c > @@ -69,6 +69,12 @@ static int fastsleep_loop(struct cpuidle_device *dev, > unsigned long old_lpcr = mfspr(SPRN_LPCR); > unsigned long new_lpcr; > > + /* > + * Verify if snooze is the only valid cpuidle state > + */ > + if (!(powersave_nap > 0)) > + return index; > + > if (unlikely(system_state < SYSTEM_RUNNING)) > return index; Doesn't the above mean we are just going to keep trying to go into fastsleep again and again? Or does the idle code work out that it didn't work based on the fact that we didn't sleep for the right period? We were talking about getting rid of powersave_nap altogether, but I think we decided we couldn't, I forget. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] pseries: Fix endian issues in cpu hot-removal
On Sat, Sep 13, 2014 at 12:41 AM, Thomas Falcon
wrote:
> When removing a cpu, this patch makes sure that values
> gotten from or passed to firmware are in the correct
> endian format.
>
> Signed-off-by: Thomas Falcon
> ---
> Changes in v2:
>
> Followed suggestions from Michael Ellerman:
>Conversion of intserv to cpu endian occurs once.
>Conversion of drc_index to cpu endian occurs once
>using of_property_read_u32.
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 20 +++-
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 10 ++
> 2 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index 9e9f30b2..343dfdf 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -444,7 +444,8 @@ static int dlpar_offline_cpu(struct device_node *dn)
> int rc = 0;
> unsigned int cpu;
> int len, nthreads, i;
> - const u32 *intserv;
> + const __be32 *intserv;
> + u32 thread;
>
> intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
> if (!intserv)
> @@ -454,8 +455,9 @@ static int dlpar_offline_cpu(struct device_node *dn)
>
> cpu_maps_update_begin();
> for (i = 0; i < nthreads; i++) {
> + thread = be32_to_cpu(intserv[i]);
> for_each_present_cpu(cpu) {
> - if (get_hard_smp_processor_id(cpu) != intserv[i])
> + if (get_hard_smp_processor_id(cpu) != thread)
> continue;
>
> if (get_cpu_current_state(cpu) == CPU_STATE_OFFLINE)
> @@ -477,14 +479,14 @@ static int dlpar_offline_cpu(struct device_node *dn)
> * Upgrade it's state to CPU_STATE_OFFLINE.
> */
> set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
> - BUG_ON(plpar_hcall_norets(H_PROD, intserv[i])
> + BUG_ON(plpar_hcall_norets(H_PROD, thread)
> != H_SUCCESS);
> __cpu_die(cpu);
> break;
> }
> if (cpu == num_possible_cpus())
> printk(KERN_WARNING "Could not find cpu to offline "
> - "with physical id 0x%x\n", intserv[i]);
> + "with physical id 0x%x\n", thread);
> }
> cpu_maps_update_done();
>
> @@ -496,15 +498,15 @@ out:
> static ssize_t dlpar_cpu_release(const char *buf, size_t count)
> {
> struct device_node *dn;
> - const u32 *drc_index;
> + const u32 drc_index;
> int rc;
>
> dn = of_find_node_by_path(buf);
> if (!dn)
> return -EINVAL;
>
> - drc_index = of_get_property(dn, "ibm,my-drc-index", NULL);
> - if (!drc_index) {
> + rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
Use of const for drc_index causes compilation problems.
Warning on Fedora 20 BE
arch/powerpc/platforms/pseries/dlpar.c: In function ‘dlpar_cpu_release’:
arch/powerpc/platforms/pseries/dlpar.c:508:2: warning: passing
argument 3 of ‘of_property_read_u32’ discards ‘const’ qualifier from
pointer target type [enabled by default]
rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
^
In file included from arch/powerpc/platforms/pseries/dlpar.c:18:0:
include/linux/of.h:699:19: note: expected ‘u32 *’ but argument is of
type ‘const u32 *’
static inline int of_property_read_u32(const struct device_node *np,
Error on Ubuntu 14.04 LE
arch/powerpc/platforms/pseries/dlpar.c: In function ‘dlpar_cpu_release’:
arch/powerpc/platforms/pseries/dlpar.c:508:2: error: passing argument
3 of ‘of_property_read_u32’ discards ‘const’ qualifier from pointer
target type [-Werror]
rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
^
In file included from arch/powerpc/platforms/pseries/dlpar.c:18:0:
include/linux/of.h:699:19: note: expected ‘u32 *’ but argument is of
type ‘const u32 *’
static inline int of_property_read_u32(const struct device_node *np,
^
cc1: all warnings being treated as errors
Regards,
Bharata.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/numa: add ability to disable and debug topology updates
On Tue, 2014-09-09 at 13:09 -0700, Nishanth Aravamudan wrote:
> We have hit a few customer issues with the topology update code (VPHN
> and PRRN). It would be nice to be able to debug the notifications coming
> from the hypervisor in both cases to the LPAR, as well as to disable
> reacting to the notifications, to narrow down the source of the
> problems. Add a basic level of such functionality, similar to the numa=
> command-line parameter.
>
> Signed-off-by: Nishanth Aravamudan
> ---
> This is pretty rough, but has been useful in the field already. I'm not
> sure if more information would be useful than this basic amount.
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 5ae8608ca9f5..6e3b9e3a2ab4 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3370,6 +3370,13 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> e.g. base its process migration decisions on it.
> Default is on.
>
> + topology_updates= [KNL, PPC, NUMA]
> + Format: {off | debug}
> + Specify if the kernel should ignore (off) or
> + emit more information (debug) when the
> + hypervisor sends NUMA topology updates to an
> + LPAR.
Boot-time parameters are kind of a pain, not least because they require a reboot
to activate.
Does it really need to be a boot param, or could it be a debugfs or sysctl
flag? ie. do we need to disable it immediately at boot or would it be OK if it
was /etc/rc.local or similar that turned it off ?
It looks like arch_update_cpu_topology() is called quite early, from
init_sched_domains(), but in that case I don't see how
cpu_associativity_changes_mask can be non-zero, ie. we'll never do any work
via that path.
As far as the debug goes, we could just use pr_debug() with
CONFIG_DYNAMIC_DEBUG, it's not quite as easy to enable as a kernel parameter
but for the odd bit of debugging it should be fine.
I guess the downside there is you have to do some work before you know if
you're printing anything out. More below ...
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index d7737a542fd7..72c5ad313cbe 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1160,6 +1160,28 @@ static int __init early_numa(char *p)
> }
> early_param("numa", early_numa);
>
> +static int topology_updates_enabled = 1;
> +static int topology_updates_debug = 0;
> +
> +static int __init early_topology_updates(char *p)
> +{
> + if (!p)
> + return 0;
> +
> + if (strstr(p, "off")) {
> + printk(KERN_INFO "Disabling topology updates\n");
> + topology_updates_enabled = 0;
> + }
Can you add a:
#define pr_fmt(fmt) "numa: " fmt
At the top of the file and then use pr_xxx() for these?
> + if (strstr(p, "debug")) {
> + printk(KERN_INFO "Enabling topology updates debug\n");
> + topology_updates_debug = 1;
> + }
> +
> + return 0;
> +}
> +early_param("topology_updates", early_topology_updates);
> +
> #ifdef CONFIG_MEMORY_HOTPLUG
> /*
> * Find the node associated with a hot added memory section for
> @@ -1546,6 +1568,9 @@ int arch_update_cpu_topology(void)
> struct device *dev;
> int weight, new_nid, i = 0;
>
> + if (!topology_updates_enabled)
> + return 0;
> +
> weight = cpumask_weight(&cpu_associativity_changes_mask);
> if (!weight)
> return 0;
> @@ -1610,6 +1635,25 @@ int arch_update_cpu_topology(void)
>*
>* And for the similar reason, we will skip all the following updating.
>*/
The comment should stay attached to the check below of updated_cpus, ie. this
block should preceed the comment.
> + if (topology_updates_debug) {
> + char *buf = kmalloc_array(NR_CPUS*5, sizeof(char), GFP_KERNEL);
> + cpumask_scnprintf(buf, NR_CPUS*5, &updated_cpus);
> + printk(KERN_DEBUG "Topology update for the following CPUs:\n");
> + printk(KERN_DEBUG " %s\n", buf);
> + printk(KERN_DEBUG "cpumask_weight(&updated_cpus)) = %u\n",
> + cpumask_weight(&updated_cpus));
Do we really need to print the cpumask? The same information is available below
right, just in a more verbose form?
Assuming we can skip that we can just use pr_debug() for these I think and drop
the debug flag. Or is this a super hot-path that I'm not aware of?
> + if (cpumask_weight(&updated_cpus)) {
> + for (ud = &updates[0]; ud; ud = ud->next) {
> + printk(KERN_DEBUG "cpu %d moving from node %d "
> + "to %d\n", ud->cpu,
> + ud->old_nid, ud->new_nid);
> +
Re: [PATCH] rtc/tpo: Driver to support rtc and wakeup on PowerNV platform
On Wed, 2014-09-10 at 11:08 +0530, Neelesh Gupta wrote: > The patch implements the OPAL rtc driver that binds with the rtc > driver subsystem. The driver uses the platform device infrastructure > to probe the rtc device and register it to rtc class framework. The > 'wakeup' is supported depending upon the property 'has-tpo' present > in the OF node. It provides a way to load the generic rtc driver in > in the absence of an OPAL driver. > > The patch also moves the existing OPAL rtc get/set time interfaces to the > new driver and exposes the necessary OPAL calls using EXPORT_SYMBOL_GPL. > > Signed-off-by: Neelesh Gupta > --- > > Note: > This patch depends upon the below patch posted on > 'linuxppc-dev@lists.ozlabs.org' > [PATCH 1/4] powerpc/powernv: Add OPAL check token call > Signed-off-by: Michael Neuling > > arch/powerpc/include/asm/opal.h|7 - > arch/powerpc/kernel/time.c |1 > arch/powerpc/platforms/powernv/opal-async.c|3 > arch/powerpc/platforms/powernv/opal-rtc.c | 63 ++ > arch/powerpc/platforms/powernv/opal-wrappers.S |2 > arch/powerpc/platforms/powernv/opal.c |6 + > arch/powerpc/platforms/powernv/setup.c |2 > drivers/rtc/Kconfig| 11 + > drivers/rtc/Makefile |1 > drivers/rtc/rtc-opal.c | 257 > > 10 files changed, 305 insertions(+), 48 deletions(-) > create mode 100644 drivers/rtc/rtc-opal.c Alessandro, given this depends on other things in the powerpc tree do you mind if we take this through the powerpc tree with your Ack? Or I can create a topic branch with the required powerpc changes. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/powernv: Add OPAL check token call
On Mon, 2014-09-15 at 13:10 +1000, Michael Ellerman wrote:
> On Tue, 2014-08-19 at 14:47 +1000, Michael Neuling wrote:
> > Currently there is no way to generically check if an OPAL call exists or not
> > from the host kernel.
> >
> > This adds an OPAL call opal_check_token() which tells you if the given
> > token is
> > present in OPAL or not.
> >
> > Signed-off-by: Michael Neuling
> > ---
> > arch/powerpc/include/asm/opal.h| 7 +++
> > arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/opal.h
> > b/arch/powerpc/include/asm/opal.h
> > index 86055e5..4593a93 100644
> > --- a/arch/powerpc/include/asm/opal.h
> > +++ b/arch/powerpc/include/asm/opal.h
> > @@ -135,6 +135,7 @@ struct opal_sg_list {
> > #define OPAL_FLASH_MANAGE 77
> > #define OPAL_FLASH_UPDATE 78
> > #define OPAL_RESYNC_TIMEBASE 79
> > +#define OPAL_CHECK_TOKEN 80
> > #define OPAL_DUMP_INIT 81
> > #define OPAL_DUMP_INFO 82
> > #define OPAL_DUMP_READ 83
> > @@ -417,6 +418,11 @@ struct opal_msg {
> > __be64 params[8];
> > };
> >
> > +enum OpalCheckTokenStatus {
> > + OPAL_TOKEN_ABSENT = 0,
> > + OPAL_TOKEN_PRESENT = 1
> > +};
>
> I don't see this used anywhere?
>
> And NoCamelCase !
We can probably just delete the enum since we are just doing this in
code anyway:
if (!opal_check_token(OPAL_RTC_READ))
goto out;
OK? Or would you prefer the usage to read:
if (opal_check_token(OPAL_RTC_READ) == OPAL_TOKEN_ABSENT)
goto out;
> Yes I know there's lots in that file, but I didn't merge that :)
Fickle bloody maintainers. I thought I never say this but... I want our
crazy Frenchman back! :-P
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc/powernv: Check OPAL elog calls exist before using
On Tue, 2014-08-19 at 14:48 +1000, Michael Neuling wrote:
> Check that the OPAL_ELOG_READ token exists before initalising the elog
> infrastructure.
>
> This avoids littering the OPAL console with:
> "OPAL: Called with bad token 74"
>
> Signed-off-by: Michael Neuling
> ---
> arch/powerpc/platforms/powernv/opal-elog.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c
> b/arch/powerpc/platforms/powernv/opal-elog.c
> index bbdb3ff..518fe95 100644
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -295,6 +295,10 @@ int __init opal_elog_init(void)
> {
> int rc = 0;
>
> + /* ELOG not supported by firmware */
> + if (!opal_check_token(OPAL_ELOG_READ))
> + return -1;
> +
The only caller does:
/* Setup error log interface */
rc = opal_elog_init();
/* Setup code update interface */
opal_flash_init();
/* Setup platform dump extract interface */
opal_platform_dump_init();
/* Setup system parameters interface */
opal_sys_param_init();
/* Setup message log interface. */
opal_msglog_init();
}
return 0;
}
So we may as well have it return void. Wanna send a follow-up patch for that.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/powernv: Add OPAL check token call
On Tue, 2014-08-19 at 14:47 +1000, Michael Neuling wrote:
> Currently there is no way to generically check if an OPAL call exists or not
> from the host kernel.
>
> This adds an OPAL call opal_check_token() which tells you if the given token
> is
> present in OPAL or not.
>
> Signed-off-by: Michael Neuling
> ---
> arch/powerpc/include/asm/opal.h| 7 +++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 86055e5..4593a93 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -135,6 +135,7 @@ struct opal_sg_list {
> #define OPAL_FLASH_MANAGE77
> #define OPAL_FLASH_UPDATE78
> #define OPAL_RESYNC_TIMEBASE 79
> +#define OPAL_CHECK_TOKEN 80
> #define OPAL_DUMP_INIT 81
> #define OPAL_DUMP_INFO 82
> #define OPAL_DUMP_READ 83
> @@ -417,6 +418,11 @@ struct opal_msg {
> __be64 params[8];
> };
>
> +enum OpalCheckTokenStatus {
> + OPAL_TOKEN_ABSENT = 0,
> + OPAL_TOKEN_PRESENT = 1
> +};
I don't see this used anywhere?
And NoCamelCase !
Yes I know there's lots in that file, but I didn't merge that :)
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] pseries: Fix endian issues in onlining cpu threads
On Fri, 2014-09-12 at 14:11 -0500, Thomas Falcon wrote: > The ibm,ppc-interrupt-server#s property is in big endian format. > These values need to be converted when used by little endian > architectures. > > Signed-off-by: Thomas Falcon > --- > Changes in v2: > > Followed suggestions from Michael Ellerman >conversion of intserv values occur once Thanks Tom. I think I saw that you'd already discussed these with Nathan in another thread, so I'll assume he's OK with them unless he says otherwise. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add macros for the ibm_architecture_vec[] lengths
On Tue, 2014-09-09 at 11:03 +1000, Stewart Smith wrote: > Michael Ellerman writes: > > The encoding of the lengths in the ibm_architecture_vec array is > > "interesting" to say the least. It's non-obvious how the number of bytes > > we provide relates to the length value. > > > > In fact we already got it wrong once, see 11e9ed43ca8a "Fix up > > ibm_architecture_vec definition". > > > > So add some macros to make it (hopefully) clearer. These at least have > > the property that the integer present in the code is equal to the number > > of bytes that follows it. > > > > Signed-off-by: Michael Ellerman > > Seems at least as correct as the code was before... so, > > Reviewed-by: Stewart Smith > > (not actually compiled or tested or anything, but my internal C > preprocesser says it looks okay :) Thanks for the review, it's one of those patches it would be easy to get wrong because it's so simple in theory. As a test I deliberately broke the NUM_VECTORS value, and .. my system booted just fine! So I think I'll give this a bit more scrutiny and work out what's going on there first :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/eeh: Fix kernel crash when passing through VF
On Fri, 2014-09-12 at 15:05 +1000, Gavin Shan wrote:
> On Fri, Sep 12, 2014 at 01:55:23PM +1000, Michael Ellerman wrote:
> >On Thu, 2014-09-11 at 11:42 +0800, Wei Yang wrote:
> >> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> >> index 4a45ba8..403445e 100644
> >> --- a/arch/powerpc/kernel/eeh.c
> >> +++ b/arch/powerpc/kernel/eeh.c
> >> @@ -625,7 +625,7 @@ int eeh_pci_enable(struct eeh_pe *pe, int function)
> >> int pcibios_set_pcie_reset_state(struct pci_dev *dev, enum
> >> pcie_reset_state state)
> >> {
> >>struct eeh_dev *edev = pci_dev_to_eeh_dev(dev);
> >> - struct eeh_pe *pe = edev->pe;
> >> + struct eeh_pe *pe = edev ? edev->pe : NULL;
> >>
> >>if (!pe) {
> >>pr_err("%s: No PE found on PCI device %s\n",
> >
> >
> >We seem to do this or something similar in a few places. Is it worth having a
> >pci_dev_to_eeh_pe() inline?
> >
>
> Yes, maybe we just need a eeh_dev_to_pe() because converting
> pci_dev to eeh_dev is already coverred by pci_dev_to_eeh_dev().
>
> With eeh_dev_to_pe(), it looks like this:
>
> struct pci_dev *pdev;
> struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
> struct eeh_pe *pe = eeh_dev_to_pe(edev);
>
> Or another case:
>
> struct device_node *dn;
> struct eeh_dev *edev = of_node_to_eeh_dev(dn);
> struct eeh_pe *pe = eeh_dev_to_pe(edev);
Yeah I guess.
I saw a few places where we go from pci_dev to eeh_pe via a eeh_dev but then
don't use the eeh_dev at all. So for those it would make sense to have one
macro that does the full conversion from pci_dev to eeh_pe.
But if you think that's not very common then yeah a macro to do each stage is
fine.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] PCI/MSI/PPC: Remove arch_msi_check_device()
On Sun, 2014-09-07 at 20:57 +0200, Alexander Gordeev wrote: > Moving MSI checks from arch_msi_check_device() function to > arch_setup_msi_irqs() function makes code more compact and > allows removing unnecessary hook arch_msi_check_device() > from generic MSI code. > > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Cc: Michael Ellerman I already acked the previous version, but if you didn't want it that's fine :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] sched: BUG when stack end location is over written
On Fri, 2014-09-12 at 12:58 +0200, Mike Galbraith wrote: > On Fri, 2014-09-12 at 10:44 +0100, Aaron Tomlin wrote: > > On Fri, Sep 12, 2014 at 02:06:57PM +1000, Michael Ellerman wrote: > > > On Thu, 2014-09-11 at 16:41 +0100, Aaron Tomlin wrote: > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > > index a285900..2a8280a 100644 > > > > --- a/lib/Kconfig.debug > > > > +++ b/lib/Kconfig.debug > > > > @@ -824,6 +824,18 @@ config SCHEDSTATS > > > > application, you can say N to avoid the very slight overhead > > > > this adds. > > > > > > > > +config SCHED_STACK_END_CHECK > > > > + bool "Detect stack corruption on calls to schedule()" > > > > + depends on DEBUG_KERNEL > > > > + default y > > > > > > Did you really mean default y? > > > > > > Doing so means it will be turned on more or less everywhere, which > > > defeats the > > > purpose of having a config option in the first place. > > > > Only if Kconfig CONFIG_DEBUG_KERNEL is enabled in the first place. > > Which is likely enabled just about everywhere on the planet. Yes, including all distros I'm aware of. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: bit fields && data tearing
> So a problem that no one has ever complained about on _any_ arch is suddenly > a problem on a subset of Alpha cpus, but a problem I know exists on Alpha > isn't important because no one's filed a bug about it? Yes - because if you think about it that tells you that nobody is hitting it with the old code and it probably doesn't matter. > The only Alpha person in this discussion has come out clearly in favor > of dropping EV4/5 support. That's not a statistically valid sample size btw Plus as I pointed out (and you ignored) you are shutting out any future processors with this kind of oddity, and you have not audited all the embedded devices we support or may support in future. > The fact is that the kernel itself is much more parallel than it was > 15 years ago, and that trend is going to continue. Paired with the fact > that the Alpha is the least-parallel-friendly arch, makes improving > parallelism and correctness even harder within kernel subsystems; harder > than it has to be and harder than it should be. > > Linus has repeatedly stated that non-arch code should be as > arch-independent as possible That's why many many years ago we added set_bit() and the other bit functions. On sane processors they are very fast. On insane ones they work. They understand byte tearing, they understand store ordering (which a simple variable does not so you've got to audit all your memory barriers too). In many cases they are faster than using memory barriers to guide the compiler because they invalidate less and allow the compiler more freedom. All this started because I suggested you use set_bit and friends and for some reason you've decided to try and find another way to do it. We have the bit operations for a reason. On x86 they are very very fast, on uniprocessor anything they are very fast, on multiprocessor in general they are very fast, or you are dealing with boxes that have sanity problems of other kinds. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] video: valkyriefb: Fix unused variable warning in set_valkyrie_clock()
If CONFIG_ADB_CUDA=n:
drivers/video/fbdev/valkyriefb.c: In function ‘set_valkyrie_clock’:
drivers/video/fbdev/valkyriefb.c:267: warning: unused variable ‘i’
drivers/video/fbdev/valkyriefb.c:266: warning: unused variable ‘req’
Move the variable declarations inside the existing #ifdef section to fix
this.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/valkyriefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/valkyriefb.c b/drivers/video/fbdev/valkyriefb.c
index 97cb9bd1d1dd..b6ed09f16355 100644
--- a/drivers/video/fbdev/valkyriefb.c
+++ b/drivers/video/fbdev/valkyriefb.c
@@ -263,10 +263,10 @@ static inline int valkyrie_vram_reqd(int video_mode, int
color_mode)
static void set_valkyrie_clock(unsigned char *params)
{
+#ifdef CONFIG_ADB_CUDA
struct adb_request req;
int i;
-#ifdef CONFIG_ADB_CUDA
for (i = 0; i < 3; ++i) {
cuda_request(&req, NULL, 5, CUDA_PACKET, CUDA_GET_SET_IIC,
0x50, i + 1, params[i]);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
