02 May, 2011

1 commit

  • Merge reason: Pick up the following two fix commits.

    2be19102b7: x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo()
    765af22da8: x86-32, NUMA: Fix ACPI NUMA init broken by recent x86-64 change

    Scheduled NUMA init 32/64bit unification changes depend on these.

    Signed-off-by: Tejun Heo

    Tejun Heo
     

31 Mar, 2011

1 commit


29 Mar, 2011

1 commit


12 Jan, 2011

1 commit


11 Jan, 2011

2 commits


14 Dec, 2010

1 commit

  • Remove deprecated ACPI process procfs I/F for throttling control.

    This is because the t-state control should only be done in kernel,
    when system is in a overheating state.

    Now users can only change the processor t-state indirectly,
    by poking the cooling device sysfs I/F of the processor.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

16 Oct, 2010

1 commit


15 Aug, 2010

1 commit

  • Remove deprecated ACPI processor procfs I/F, including:
    /proc/acpi/processor/CPUX/power
    /proc/acpi/processor/CPUX/limit
    /proc/acpi/processor/CPUX/info

    /proc/acpi/processor/CPUX/throttling still exists,
    as we don't have sysfs I/F available for now.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

15 Mar, 2010

1 commit


16 Feb, 2010

1 commit

  • Dan's list contains:

    drivers/acpi/processor_throttling.c +1139 acpi_processor_get_throttling_info(11) warning: variable derefenced before check 'pr'

    acpi_processor_get_throttling_info() is never called with pr == NULL.

    [ bart: the potential NULL pointer dereference was finally fixed in
    (much later than mine) commit 5cfa245 but my patch is still valid ]

    Reported-by: Dan Carpenter
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Bartlomiej Zolnierkiewicz
     

28 Jan, 2010

1 commit


06 Nov, 2009

1 commit

  • If the NULL test on pr is needed, then the dereference should be after the
    NULL test.

    A simplified version of the semantic match that detects this problem is as
    follows (http://coccinelle.lip6.fr/):

    //
    @match exists@
    expression x, E;
    identifier fld;
    @@

    * x->fld
    ... when != \(x = E\|&x\)
    * x == NULL
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Julia Lawall
     

24 Sep, 2009

1 commit


19 Sep, 2009

1 commit


29 Aug, 2009

1 commit

  • Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
    however, not all ACPI drivers use/want it -- and they
    should not have to #undef PREFIX to define their own.

    Add GPL commment to internal.h while we are there.

    This does not change any actual console output,
    asside from a whitespace fix.

    Signed-off-by: Len Brown

    Len Brown
     

27 Aug, 2009

2 commits

  • This failure is very common on many platforms. Handling it in the ACPI
    processor driver is enough, and we don't need a warning message unless
    CONFIG_ACPI_DEBUG is set.

    Based on a patch from Zhang Rui.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

    Signed-off-by: Frans Pop
    Acked-by: Zhang Rui
    Cc: Len Brown
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frans Pop
     
  • If the BIOS reports an invalid throttling state (which seems to be
    fairly common after system boot), a reset is done to state T0.
    Because of a check in acpi_processor_get_throttling_ptc(), the reset
    never actually gets executed, which results in the error reoccurring
    on every access of for example /proc/acpi/processor/CPU0/throttling.

    Add a 'force' option to acpi_processor_set_throttling() to ensure
    the reset really takes effect.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

    This patch, together with the next one, fixes a regression introduced in
    2.6.30, listed on the regression list. They have been available for 2.5
    months now in bugzilla, but have not been picked up, despite various
    reminders and without any reason given.

    Google shows that numerous people are hitting this issue. The issue is in
    itself relatively minor, but the bug in the code is clear.

    The patches have been in all my kernels and today testing has shown that
    throttling works correctly with the patches applied when the system
    overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

    Signed-off-by: Frans Pop
    Acked-by: Zhang Rui
    Cc: Len Brown
    Cc: "Rafael J. Wysocki"
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frans Pop
     

24 Jun, 2009

1 commit


30 May, 2009

1 commit

  • Commit 4973b22a ("ACPI processor: reset the throttling state once it's
    invalid") introduced a new warning which prints a spurious newline.

    The ACPI_WARNING macro that is used already takes care of adding a
    newline, after adding ACPI_CA_VERSION to the message. Remove the newline
    to avoid the message getting split into two lines.

    Signed-off-by: Frans Pop
    Signed-off-by: Len Brown

    Frans Pop
     

16 May, 2009

2 commits


05 Apr, 2009

1 commit


04 Apr, 2009

2 commits


04 Jan, 2009

1 commit


08 Nov, 2008

1 commit


23 Oct, 2008

2 commits

  • Conflicts:
    drivers/acpi/bay.c
    drivers/acpi/dock.c
    drivers/ata/libata-acpi.c

    Signed-off-by: Len Brown

    Len Brown
     
  • ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core.
    So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...)
    and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...)

    We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see
    -------------------------------------------------------------
    commit 6468463abd7051fcc29f3ee7c931f9bbbb26f5a4
    Author: Len Brown
    Date: Mon Jun 26 23:41:38 2006 -0400

    ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)

    Signed-off-by: Len Brown
    -------------------------------------------------------------

    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Lin Ming
     

11 Oct, 2008

1 commit

  • As of version 2.0, ACPI can return 64-bit integers. The current
    acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
    Change the argument to take a pointer to an acpi_integer so we support
    64-bit integers on all platforms.

    lenb: replaced use of "acpi_integer" with "unsigned long long"
    lenb: fixed bug in acpi_thermal_trips_update()

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Len Brown

    Matthew Wilcox
     

26 Jul, 2008

1 commit


19 Jul, 2008

2 commits

  • * This patch replaces the dangerous lvalue version of cpumask_of_cpu
    with new cpumask_of_cpu_ptr macros. These are patterned after the
    node_to_cpumask_ptr macros.

    In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
    the cpumask_of_cpu_map[cpu] entry is used. The cpumask_of_cpu_map
    is provided when there is a large NR_CPUS count, reducing
    greatly the amount of code generated and stack space used for
    cpumask_of_cpu(). The pointer to the cpumask_t value is needed for
    calling set_cpus_allowed_ptr() to reduce the amount of stack space
    needed to pass the cpumask_t value.

    If there isn't a cpumask_of_cpu_map[], then a temporary variable is
    declared and filled in with value from cpumask_of_cpu(cpu) as well as
    a pointer variable pointing to this temporary variable. Afterwards,
    the pointer is used to reference the cpumask value. The compiler
    will optimize out the extra dereference through the pointer as well
    as the stack space used for the pointer, resulting in identical code.

    A good example of the orthogonal usages is in net/sunrpc/svc.c:

    case SVC_POOL_PERCPU:
    {
    unsigned int cpu = m->pool_to[pidx];
    cpumask_of_cpu_ptr(cpumask, cpu);

    *oldmask = current->cpus_allowed;
    set_cpus_allowed_ptr(current, cpumask);
    return 1;
    }
    case SVC_POOL_PERNODE:
    {
    unsigned int node = m->pool_to[pidx];
    node_to_cpumask_ptr(nodecpumask, node);

    *oldmask = current->cpus_allowed;
    set_cpus_allowed_ptr(current, nodecpumask);
    return 1;
    }

    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Mike Travis
     
  • Conflicts:

    drivers/acpi/processor_throttling.c

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

17 Jul, 2008

3 commits

  • Fix printk format warning:

    linux-next-20080617/drivers/acpi/processor_throttling.c:1258: warning: format '%d' expects type 'int', but argument 4 has type 'size_t'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Len Brown
    Signed-off-by: Andi Kleen

    Randy Dunlap
     
  • http://bugzilla.kernel.org/show_bug.cgi?id=9704

    When echo some invalid values to /proc/acpi/processor/*/throttling,
    there isn't any error info returned, on the contray, it sets
    throttling value to some T* successfully, obviously, this is incorrect,
    a correct way should be to let it fail and return error info.

    This patch fixed the aforementioned issue, it also enables
    /proc/acpi/processor/*/throttling to accept such values as 't0' and 'T0',
    it also strictly limits /proc/acpi/processor/*/throttling only to accept
    "*", "t*" and "T*", "*" is the throttling state value the processor can
    support, current, it is 0 - 7.

    Before applying this patch, the test result is below:

    [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T1
    state available: T0 to T7
    states:
    T0: 100%
    *T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost acpi]# echo "1xxxxxx" > /proc/acpi/processor/CPU0/throttling
    [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T1
    state available: T0 to T7
    states:
    T0: 100%
    *T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost acpi]# echo "0" > /proc/acpi/processor/CPU0/throttling
    [root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost acpi]# cd /
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "T0" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "T7" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "T100" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "xxx" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "2xxxx" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T2
    state available: T0 to T7
    states:
    T0: 100%
    T1: 87%
    *T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost /]# echo "7777" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost /]# echo "7xxx" > /proc/acpi/processor/CPU0/throttling
    [root@localhost /]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T7
    state available: T0 to T7
    states:
    T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    *T7: 12%
    [root@localhost /]#

    After applying this patch, the test result is below:

    [root@localhost linux-2.6.24-rc6]# echo > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "0" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo "t0" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo "T0" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T0
    state available: T0 to T7
    states:
    *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
    [root@localhost linux-2.6.24-rc6]# echo "T7" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T7
    state available: T0 to T7
    states:
    T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    *T7: 12%
    [root@localhost linux-2.6.24-rc6]# echo "T8" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# vi drivers/acpi/processor_throttling.c
    [root@localhost linux-2.6.24-rc6]# echo "T8" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "t7" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo "t70" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "70" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "7000" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "70" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo "xxx" > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo -n > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo $?
    0
    [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T7
    state available: T0 to T7
    states:
    T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    *T7: 12%
    [root@localhost linux-2.6.24-rc6]# echo -n "" > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# cat /proc/acpi/processor/CPU0/throttling
    state count: 8
    active state: T7
    state available: T0 to T7
    states:
    T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    *T7: 12%
    [root@localhost linux-2.6.24-rc6]# echo t0 > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo T0 > /proc/acpi/processor/CPU0/throttling
    [root@localhost linux-2.6.24-rc6]# echo Tt0 > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]# echo T > /proc/acpi/processor/CPU0/throttling
    -bash: echo: write error: Invalid argument
    [root@localhost linux-2.6.24-rc6]#

    Signed-off-by: Yi Yang
    Signed-off-by: Len Brown
    Signed-off-by: Andi Kleen

    Yi Yang
     
  • Change processors from an array sized by NR_CPUS to a per_cpu variable.

    Signed-off-by: Mike Travis
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown
    Signed-off-by: Andi Kleen

    Mike Travis
     

24 May, 2008

1 commit


29 Apr, 2008

1 commit

  • Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data
    be setup before gluing PDE to main tree.

    Add correct ->owner to proc_fops to fix reading/module unloading race.

    Signed-off-by: Denis V. Lunev
    Cc: Len Brown
    Cc: Alexey Dobriyan
    Cc: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis V. Lunev
     

20 Apr, 2008

1 commit

  • * Use new set_cpus_allowed_ptr() function added by previous patch,
    which instead of passing the "newly allowed cpus" cpumask_t arg
    by value, pass it by pointer:

    -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
    +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)

    * Modify CPU_MASK_ALL

    Depends on:
    [sched-devel]: sched: add new set_cpus_allowed_ptr function

    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Mike Travis