variables (removing 'i')
> - Add comment about the cpu_add_remove_lock protecting the added CPU mask.
> Changes since V1 (no functional changes):
> - update the test's output in the commit's description
> - node_recorded_ids_map should be static
>
> Signed-off-by: Laurent Dufour
Thanks Laurent.
Reviewed-by: Nathan Lynch
Laurent Dufour writes:
> Changes since V2, addressing Nathan's comments:
> - Remove the retry feature
> - Reduce the number of local variables (removing 'i')
I was more interested in not having two variables for NUMA nodes in the
function named 'node' and 'nid', hoping at least one of them coul
Laurent Dufour writes:
> Le 02/04/2021 à 15:34, Nathan Lynch a écrit :
>> Laurent Dufour writes:
>>> When a CPU is hot added, the CPU ids are taken from the available mask from
>>> the lower possible set. If that set of values was previously used for CPU
>>>
Hi Laurent,
Laurent Dufour writes:
> When a CPU is hot added, the CPU ids are taken from the available mask from
> the lower possible set. If that set of values was previously used for CPU
> attached to a different node, this seems to application like if these CPUs
> have migrated from a node to
Geert Uytterhoeven writes:
> On Mon, Oct 26, 2020 at 10:46 AM Geert Uytterhoeven
> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.10-rc1[1] compared to v5.9[2].
>>
>> Summarized:
>> - build errors: +3/-7
>> - build warnings: +26/-28
>>
>> Happy fixing! ;-
Hi Leonardo,
Leonardo Bras writes:
> Hello Nathan, thanks for the feedback!
>
> On Fri, 2020-04-10 at 14:28 -0500, Nathan Lynch wrote:
>> Leonardo Bras writes:
>> > Implement rtas_call_reentrant() for reentrant rtas-calls:
>> > "ibm,int-on", &qu
Hi,
Leonardo Bras writes:
> +/**
> + * rtas_call_reentrant() - Used for reentrant rtas calls
> + * @token: Token for desired reentrant RTAS call
> + * @nargs: Number of Input Parameters
> + * @nret:Number of Output Parameters
> + * @outputs: Array of outputs
> + * @...: Inputs for des
Gautham R Shenoy writes:
> The accounting problem in tools such as lparstat with
> "cede_offline=on" is affecting customers who are using these tools for
> capacity-planning. That problem needs a fix in the short-term, for
> which Patch 1 changes the default behaviour of cede_offline from "on"
> t
Gautham R Shenoy writes:
> On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
>> "Gautham R. Shenoy" writes:
>> > The patchset also defines a new sysfs attribute
>> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
"Gautham R. Shenoy" writes:
> The patchset also defines a new sysfs attribute
> "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> to allow userspace programs to change the state into which the
> offlined CPU need to be put to at runtime.
A boolean sysfs interface will become
Markus Elfring writes:
> From: Markus Elfring
> Date: Tue, 27 Aug 2019 13:37:56 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> Signed-off-by: Markus Elfring
Acked-by: Nathan Lynch
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Acked-by: Nathan Lynch
Christophe Leroy writes:
> Hi,
>
> Le 19/08/2019 à 18:37, Nathan Lynch a écrit :
>> Hi,
>>
>> Christophe Leroy writes:
>>> Benchmark from vdsotest:
>>
>> I assume you also ran the verification/correctness parts of vdsotest...? :-)
>
Hi,
Christophe Leroy writes:
> Benchmark from vdsotest:
I assume you also ran the verification/correctness parts of vdsotest...? :-)
Fuqian Huang writes:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also reduce the chances o
property(struct
> cc_workarea *ccwa)
>
> name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
> prop->name = kstrdup(name, GFP_KERNEL);
> + if (!prop->name) {
> + dlpar_free_cc_property(prop);
> + return NULL;
> + }
Acked-by: Nathan Lynch
ndant. Drop it.
>>
>> Link:
>> https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulni...@google.com
>> Signed-off-by: Nick Desaulniers
>> ---
>
> The patch looks good to me,
>
> Acked-by: Arnd Bergmann
>
> Adding Nathan Lynch to Cc though for further co
declaring the addresses
> as char arrays.
>
> See also: dbbb08f500d6 ("arm64, vdso: Define vdso_{start,end} as array")
>
> Suggested-by: Mark Rutland
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Arnd Bergmann
Acked-by: Nathan Lynch
Thanks!
Will Deacon writes:
> On Tue, May 30, 2017 at 05:34:19PM -0700, Andrew Pinski wrote:
>> Note I noticed a bug in the old implementation of __kernel_clock_getres;
>> it was checking only the lower 32bits of the pointer; this would work
>> for most cases but could fail in a few.
>>
>> Changes from v
Looks fine and nothing goes wrong with my vdso tests. Please send it
through Russell.
Acked-by: Nathan Lynch
On 08/10/2016 01:47 PM, Kees Cook wrote:
> On Wed, Aug 10, 2016 at 2:59 AM, Jisheng Zhang wrote:
>> + Kees
>>
>> On Wed, 10 Aug 2016 17:09:47 +0800 wrote:
>>
>>> vdso_data_mapping is never modified, so mark it as const.
>>>
>>> vdso_data_page and vdso_text_mapping are initialized by vdso_init(),
>
On 10/16/2015 01:38 AM, H. Nikolaus Schaller wrote:
> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
> index aedec81..0cebd98 100644
> --- a/arch/arm/vdso/vdsomunge.c
> +++ b/arch/arm/vdso/vdsomunge.c
> @@ -45,7 +45,6 @@
> * it does.
> */
>
> -#include
> #include
> #in
On 10/15/2015 12:16 PM, H. Nikolaus Schaller wrote:
> Does this mean it is ok now in V3 in all cases? I have switched my patch
> editor
> tool from indirect git imap-send to git send-email (which appears to be more
> compatible).
v3 applied without issue, so yes, in that respect it is fine.
--
T
On 10/15/2015 12:52 AM, H. Nikolaus Schaller wrote:
> Am 14.10.2015 um 16:16 schrieb Nathan Lynch :
>> and it would be easier for me to deal with a patch that isn't
>> whitespace-damaged.
>
> You mean:
>
> ERROR: space prohibited before that close parenthesi
On 10/14/2015 07:47 AM, H. Nikolaus Schaller wrote:
>> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
>> index aedec81..27a9a0b 100644
>> --- a/arch/arm/vdso/vdsomunge.c
>> +++ b/arch/arm/vdso/vdsomunge.c
>> @@ -45,7 +45,18 @@
>> * it does.
>> */
>>
>> -#include
>> +#define swa
On 09/30/2015 12:47 PM, H. Nikolaus Schaller wrote:
>
> Am 30.09.2015 um 19:37 schrieb Nathan Lynch :
>> Why not just use a generic
>> implementation like is found in mips' elf2ecoff?
>
> Do you have a reference?
> I can't find byte swapping in
>
> h
On 09/30/2015 11:17 AM, Ard Biesheuvel wrote:
> On 30 September 2015 at 18:13, H. Nikolaus Schaller
> wrote:
>>
>> Am 30.09.2015 um 18:02 schrieb Ard Biesheuvel :
>>>
>>> Have you tried this?
>>>
>>> #define bswap_16 __builtin_bswap16
>>> #define bswap_32 __builtin_bswap32
>>> #define bswap_64 __
On 09/29/2015 05:14 PM, Yury Norov wrote:
> From: Philipp Tomsich
>
> Adjusted to move the move data page before code pages in sync with
> commit 601255ae3c98fd3a8bb4696425e4f868b4f1
This commit message needs more information about how the ilp32 VDSO uses
the existing arm64 code. I had to r
On 08/28/2015 05:31 AM, Lee Jones wrote:
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
> It's safe to say n here if you
On 08/28/2015 05:31 AM, Lee Jones wrote:
> +static ssize_t rproc_state_write(struct file *filp, const char __user
> *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct rproc *rproc = filp->private_data;
> + char buf[2];
> + int ret;
> +
> + ret =
On 08/27/2015 01:23 PM, Murali Karicheri wrote:
> On 08/27/2015 12:43 PM, Nathan Lynch wrote:
>> On 08/27/2015 10:51 AM, Murali Karicheri wrote:
>>> When using accumulator queue for rx side for network driver, following
>>> warning is seen when doing a reboot comma
On 08/27/2015 10:51 AM, Murali Karicheri wrote:
> When using accumulator queue for rx side for network driver, following
> warning is seen when doing a reboot command from Linux console. This
> is because, affinity value is not reset before calling free_irq(). This
> patch fixes this.
>
> Deconfig
On 08/26/2015 08:08 AM, Lee Jones wrote:
> Signed-off-by: Lee Jones
> ---
> drivers/remoteproc/remoteproc_debugfs.c | 25 +
> 1 file changed, 25 insertions(+)
The commit message should describe why this is needed...
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
On 08/26/2015 08:08 AM, Lee Jones wrote:
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,300 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre
When submitting code y
On 08/26/2015 08:08 AM, Lee Jones wrote:
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 000..6a933c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rp
ent_kernel_time would
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch
---
Changes since v1:
- Add u32 cast to nsec calculation.
arch/arm/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-
ent_kernel_time would
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch
---
arch/arm/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kern
be
bothered if they don't make 4.2 final at this late stage, since only
the (seldom-used?) coarse clocks are affected.
I'd like to collect review/acks for these now and make sure they at
least make it into 4.3-rc1 (and -stable after that).
Nathan Lynch (2):
ARM: VDSO: fix coarse
ent_kernel_time would
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch
---
arch/arm64/kernel/vdso.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm6
On 08/06/2015 05:52 PM, Andy Lutomirski wrote:
> [adding lots of cc's]
>
> On Thu, Aug 6, 2015 at 2:45 PM, Andy Lutomirski wrote:
>> From: Andy Lutomirski
>>
>> Some dynamic loaders may be slightly faster if a GNU hash is
>> available. Strangely, this seems to have no effect at all on the
>> vd
On 07/14/2015 12:18 AM, Yingjoe Chen wrote:
> Add arch timer node to enable arch-timer support. MT8135 firmware
> doesn't correctly setup arch-timer frequency and CNTVOFF, add
> properties to workaround this.
[...]
>
> + timer {
> + compatible = "arm,armv7-timer";
> +
On 04/28/2015 03:32 PM, Andrey Skvortsov wrote:
> After kernel is built 'git status' reports:
>
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> #arch/arm/vdso/vdso.so.raw
> #arch/arm/vdso/vdsomunge
>
> These files are created during b
On 04/27/2015 05:55 AM, Will Deacon wrote:
> On Fri, Apr 24, 2015 at 10:43:20PM +0100, Nathan Lynch wrote:
>> The 32-bit ARM VDSO needs to know whether a generic timer is present
>> and whether it is suitable for use by user space. The VDSO
>> initialization code currently d
the VDSO
init code whether the arch timer is present and usable.
Signed-off-by: Nathan Lynch
---
drivers/clocksource/arm_arch_timer.c | 12
include/clocksource/arm_arch_timer.h | 6 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/clocksource/arm_arch_timer.c
b
Use the facility now provided by the arm_arch_timer driver to
determine whether there's a usable virtual counter for the VDSO.
Signed-off-by: Nathan Lynch
---
arch/arm/kernel/vdso.c | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)
diff --git a/arc
On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
>> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
>>> Hi Russell,
>>>
>>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux
>
On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> Hi Russell,
>
> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux
> wrote:
>>
>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>> it in my tree and keep my tree buildable without dragging in the tip
>> tree.
>
>
On 01/19/2015 04:30 AM, Michal Simek wrote:
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 5e343bab9458..3955f42e9e9c 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -64,4 +64,15 @@ config DA8XX_REMOTEPROC
> It's safe to say
On 10/30/2014 06:35 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 30, 2014 at 07:30:28AM -0400, Steven Rostedt wrote:
>> On Thu, 30 Oct 2014 11:14:41 +
>> Russell King - ARM Linux wrote:
>>
>>
>>> We have always had syscall number range of 0x90 or so. The tracing
>>> design does not e
On 10/10/2014 08:44 PM, Nathan Lynch wrote:
> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
>>
>> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
>> it seems that this has been known about for some time.)
>
> Looking at http://gcc.gn
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
>
> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
> it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3
are affected, as well as 4.9.0.
>
Hi Daniel,
On 09/26/2014 02:04 AM, Daniel Lezcano wrote:
> On 09/18/2014 04:59 PM, Nathan Lynch wrote:
>> The arm and arm64 VDSOs need CP15 access to the architected counter.
>> If this is unavailable (which is allowed by ARM v7), indicate this by
>> changing th
On 09/24/2014 09:50 AM, Russell King - ARM Linux wrote:
> On Wed, Sep 24, 2014 at 09:32:54AM -0500, Nathan Lynch wrote:
>> On 09/24/2014 09:12 AM, Christopher Covington wrote:
>>> Hi Nathan,
>>>
>>> On 09/22/2014 08:28 PM, Nathan Lynch wrote:
>>>
On 09/24/2014 09:12 AM, Christopher Covington wrote:
> Hi Nathan,
>
> On 09/22/2014 08:28 PM, Nathan Lynch wrote:
>> On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote:
>>>> On Thu, Sep 18, 20
On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote:
>> On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote:
>>> This series contains the necessary changes to allow architected timer
>>> access fr
On 09/22/2014 10:39 AM, Will Deacon wrote:
> On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote:
>> This series contains the necessary changes to allow architected timer
>> access from user-space on 32-bit ARM. This allows the VDSO to support
>> high reso
The arch_timer_evtstrm_enable hooks in arm and arm64 are substantially
similar, the only difference being a CONFIG_COMPAT-conditional section
which is relevant only for arm64. Copy the arm64 version to the
driver, removing the arch-specific hooks.
Signed-off-by: Nathan Lynch
---
arch/arm
The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to "arch_mem_counter" before registering
the clocksource.
Suggested by Stephen Boyd.
Signed-off-by: Nathan Lynch
R
cific implementations.
Signed-off-by: Nathan Lynch
---
arch/arm/include/asm/arch_timer.h| 14 --
arch/arm64/include/asm/arch_timer.h | 17 -
drivers/clocksource/arm_arch_timer.c | 17 +
3 files changed, 17 insertions(+), 31 deletions(-)
diff --git a
r with slightly
different names in one patch, then removed the unused functions in
subsequent patches for each of arm and arm64. This seemed kind of
awkward to me, so I've reorganized those changes into two patches
that should be easier to review. Patch #1 is unchanged.
Nathan Lync
On 09/11/2014 10:58 AM, Christopher Covington wrote:
>
> On 09/11/2014 11:52 AM, Doug Anderson wrote:
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 5163ec1..8ca07a9 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/cloc
On 06/30/2014 07:30 AM, Fredrik Noring wrote:
>>
>> On Fri, Jun 27, 2014 at 04:16:57PM +, Fredrik Noring wrote:
>>> Please find below a trace that appeared once with 3.16-rc2. Perhaps it
>>> is of some interest?
>>
>> It's not that serious... I know that the FEC ethernet driver is horrendously
On 04/23/2014 11:30 AM, H. Peter Anvin wrote:
> On 04/21/2014 09:52 AM, Nathan Lynch wrote:
>> Hi x86/vdso people,
>>
>> I've been working on adding a vDSO to 32-bit ARM, and Kees suggested I
>> look at x86_64's algorithm for placing the vDSO at a randomized of
Hi x86/vdso people,
I've been working on adding a vDSO to 32-bit ARM, and Kees suggested I
look at x86_64's algorithm for placing the vDSO at a randomized offset
above the stack VMA. I found that when the stack top occupies the
last slot in the PTE (is that the right term?), the vdso_addr routine
On Wed, 2013-01-23 at 08:07 +, Kim, Milo wrote:
> This patch removes a build warning below.(ARCH=x86_64)
>
> drivers/leds/leds-lp5521.c: In function lp5521_firmware_loaded:
> drivers/leds/leds-lp5521.c:257:4: warning: format %d expects argument of type
> in
> t, but argument 3 has type size_t
On Fri, 2013-01-18 at 00:00 +, Kim, Milo wrote:
> > -Original Message-
> > From: Nathan Lynch [mailto:n...@pobox.com]
> >
> > On Thu, 2013-01-17 at 01:06 +, Kim, Milo wrote:
> > > @@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
>
On Thu, 2013-01-17 at 01:06 +, Kim, Milo wrote:
> @@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
> void led_trigger_event(struct led_trigger *trig,
> enum led_brightness brightness)
> {
> - struct list_head *entry;
> + struct led_classdev *led_c
led_trigger_cpu appears to have no function: it
resides in a per-cpu data structure which never changes after the
trigger is registered. So just remove it.
Reported-by: Miles Lane
Signed-off-by: Nathan Lynch
---
drivers/leds/ledtrig-cpu.c | 21 -
1 file changed, 21 deletions
Hi Bryan,
On Thu, 2012-10-18 at 11:18 -0700, Bryan Wu wrote:
> @@ -117,14 +117,14 @@ static int __init ledtrig_cpu_init(void)
> for_each_possible_cpu(cpu) {
> struct led_trigger_cpu *trig = &per_cpu(cpu_trig, cpu);
>
> - mutex_init(&trig->lock);
> + spi
Greg KH wrote:
> On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote:
> > Jan-Bernd Themann wrote:
> > >
> > > On Thursday 10 January 2008 18:34, Greg KH wrote:
> > > > > The structure device_driver(in device.h) has a member struct
> > &
0b3a90] c000c320 .do_IRQ+0x108/0x1d0
[c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c
The memset() in sym_set_cam_result_error() would appear to be trashing
the scsi_cmnd struct instead of clearing sense_buffer.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Jan-Bernd Themann wrote:
> Hi,
>
> sorry for answering so late, I'm only tracking netdev and ppc mailing list.
>
> On Thursday 10 January 2008 18:34, Greg KH wrote:
> > > The structure device_driver(in device.h) has a member struct
> > > driver_private which
> > > contains the member kobj (accor
27;.' in the
ppc64 ABI. This causes all function text size changes to be accounted
to a single 'static.' entry in the output when comparing ppc64
kernels.
Change getsizes() to ignore the first character of the symbol name
when searching for '.'.
Signed-off-by: Nathan L
Hi Balbir-
Balbir Singh wrote:
>
>
> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
> NUMA nodes can be specified using the following command line option
>
> numa=fake=
>
> node range is of the format ,,...
>
> Each of the rangeX parameters is passed using memparse()
Hi-
B. N. Poornima wrote:
> >On Fri, 2005-06-03 at 14:25 -0500, Nathan Lynch wrote:
> >
> >>Typo in prom_find_machine_type from Ben's recent patch "ppc64: Fix
> >>result code handling in prom_init" prevents pSeries LPAR systems from
> >>bo
(cc'ing linuxppc-dev, see
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg221770.html
for original post and .config)
Elimar Riesebieter wrote:
> On Wed, 24 Oct 2007 the mental interface of
> Elimar Riesebieter told:
>
> [...]
> > The kernel is loaded from firmware but freezes at the m
Gautham R Shenoy wrote:
> > Gautham R Shenoy wrote:
> > > On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> > > > Gautham R Shenoy wrote:
> > > > > > Gautham R Shenoy wrote:
> > > > > > > Replace all lock_cpu
Gautham R Shenoy wrote:
> On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> > Gautham R Shenoy wrote:
> > > Hi Nathan,
> > > > Hi Gautham-
> > > >
> > > > Gautham R Shenoy wrote:
> > > > > Replace all l
Gautham R Shenoy wrote:
> Hi Nathan,
> > Hi Gautham-
> >
> > Gautham R Shenoy wrote:
> > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
> > > get_online_cpus and put_online_cpus instead as it highlights
> > > the refcount semantics in these operations.
> >
> > Somethi
Hi Gautham-
Gautham R Shenoy wrote:
> Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
> get_online_cpus and put_online_cpus instead as it highlights
> the refcount semantics in these operations.
Something other than "get_online_cpus", please? lock_cpu_hotplug()
protects
Hi,
Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
> ---
> drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
> b/drivers/infiniband/hw/ehca/ehca_to
Hi Joachim-
Joachim Fenkes wrote:
> Nathan Lynch <[EMAIL PROTECTED]> wrote on 29.08.2007 20:12:32:
> > Will anything break?
>
> Nope. Userspace programs should not depend on ibmebus' way of naming the
> devices; especially since some overly long loc_codes tende
Hi-
Joachim Fenkes wrote:
> Previously, ibmebus derived a device's bus_id from its location code. The
> location code is not guaranteed to be unique, so we might get bus_id
> collisions if two devices share the same location code. The OFDT full_name,
> however, is unique, so we use that instead.
Hello-
Christian Kujau wrote:
> Hi there,
>
> Since a few days I'm experiencing weird oopses on my iBook/G4 with
> ubuntu's 2.6.22-7-powerpc and also with a vanilla 2.6.22-rc7-git8.
>
> Now for the "weird" part: The oops happens when doing "make install" for
> a piece of software (xine-ui medi
Hi Joachim-
Joachim Fenkes wrote:
>
> idr_init(), when called for the first time, sets up the layer
> cache. idr_get_new() and friends expect the cache to exist. Now, what happens
> if the first call to idr_get_new() targets an idr initialized using
> DEFINE_IDR() before idr_init() has been called
aa95387774039096c11803c04011f1aa42d85758 removed the implementation of
lock_cpu_hotplug_interruptible and all users of it. This stub
definition for !CONFIG_HOTPLUG_CPU was left over -- kill it now.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
include/linux/cpu.h |1 -
1 files c
Hi Gautham-
Gautham R Shenoy wrote:
>
> Looking at the topology_init() code, I observe that the meaning of
> the cpuX/ directory entries in /sys/devices/system/cpu/ might be
> different for different architectures.
>
> Looks like, in case of i386, ia64, m32, mips etc, the cpuX directory entries
Ingo Molnar wrote:
>
> * Nathan Lynch <[EMAIL PROTECTED]> wrote:
>
> > > - raw_notifier_call_chain(&cpu_chain, CPU_LOCK_ACQUIRE, hcpu);
> > > + if (freeze_processes(FE_HOTPLUG_CPU)) {
> > > + thaw_processes(FE_HOTPLUG_CPU);
> > > +
Gautham R Shenoy wrote:
> This patch implements process_freezer based cpu-hotplug
> core.
> The sailent features are:
> o No more (un)lock_cpu_hotplug.
> o No more CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE. Hence no per-subsystem
> hotcpu mutexes.
> o Calls freeze_process/thaw_processes at the begin
Ulrich Drepper wrote:
> Siddha, Suresh B wrote:a
> > Not all of the cpu* directories in /sys/devices/system/cpu may be
> > online.
>
> Apparently this information isn't needed. It's very easy to verify:
>
> $ ls /sys/devices/system/cpu/*/online
> /sys/devices/system/cpu/cpu1/online /sys/devices
Robin Holt wrote:
> On Fri, Mar 09, 2007 at 05:58:59PM -0600, Nathan Lynch wrote:
> > Hello-
> >
> > Cliff Wickman wrote:
> > > This patch would insert a preference to migrate such a task to a cpu
> > > within
> > > its cpuset (and set its cpu
Hi-
Ingo Molnar wrote:
>
> * Cliff Wickman <[EMAIL PROTECTED]> wrote:
>
> > With this patch, migrate the task to:
> > 1) to any cpu on the same node as the disabled cpu, which is both online
> > and among that task's cpus_allowed
> > 2) to any online cpu within the task's cpuset
> > 3) to
Hello-
Cliff Wickman wrote:
> This patch would insert a preference to migrate such a task to a cpu within
> its cpuset (and set its cpus_allowed to its cpuset).
>
> With this patch, migrate the task to:
> 1) to any cpu on the same node as the disabled cpu, which is both online
> and among th
Christoph Hellwig wrote:
> On Thu, Jan 11, 2007 at 08:08:36PM +0100, Hoang-Nam Nguyen wrote:
>
> > spin_lock_irqsave(&ehca_cq_idr_lock, flags);
> > while (my_cq->nr_callbacks)
> > yield();
>
> Calling yield is a very bad idea in general. You should probably
> add a waitqueue
cpus_allowed a subset of cpu_possible_map instead. This
should still preserve the behavior that Nick's change intended.
Thanks to Giuliano Pochini for reporting this and testing the fix:
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.html
Signed-off-by: Nathan Lynch <[EMAIL PROTE
Nathan Lynch wrote:
> Jens Axboe wrote:
> > On Thu, Nov 30 2006, Jens Axboe wrote:
> > > Hi,
> > >
> > > Just got a new notebook (Lenovo X60), setup a custom kernel and then I
> > > noticed that suspend to ram doesn't work anymore. The machine
Jens Axboe wrote:
> On Thu, Nov 30 2006, Jens Axboe wrote:
> > Hi,
> >
> > Just got a new notebook (Lenovo X60), setup a custom kernel and then I
> > noticed that suspend to ram doesn't work anymore. The machine suspends
> > just fine, on resume it brings back the text display but reboots after
>
Protasevich, Natalie wrote:
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > + if (cpu_online(cpu)) {
> > > +#else
> > > if (cpu_online(cpu) || !cpu_present(cpu)) {
> > > +#endif
> > > ret = -EINVAL;
> > > goto out;
> > > }
> >
> > Why this change? I think the cpu_present check is n
[EMAIL PROTECTED] wrote:
> +#ifdef CONFIG_HOTPLUG_CPU
> + if (cpu_online(cpu)) {
> +#else
> if (cpu_online(cpu) || !cpu_present(cpu)) {
> +#endif
> ret = -EINVAL;
> goto out;
> }
Why this change? I think the cpu_present check is needed for ppc64
since
Anton Blanchard wrote:
>
> Hi,
>
> > We need some clarity on how asm-generic/topology.h is intended to be
> > used. I suspect that it's supposed to be unconditionally included at
> > the end of the architecture's topology.h so that any elements which
> > are undefined by the arch have sensible d
1 - 100 of 125 matches
Mail list logo
