1. 03 11月, 2008 1 次提交
  2. 23 10月, 2008 2 次提交
  3. 21 10月, 2008 2 次提交
  4. 20 10月, 2008 1 次提交
  5. 18 10月, 2008 1 次提交
  6. 17 10月, 2008 2 次提交
    • Z
      ACPI: Allow overriding to higher critical trip point. · 22a94d79
      Zhang Rui 提交于
      http://bugzilla.kernel.org/show_bug.cgi?id=9129
      
      lenb: Note that overriding a critical trip point
      may simply fool the user into thinking that they
      have control that they do not actually have.
      For it is EC firmware that decides when the EC
      sends Linux temperature change events, and the
      EC may or may not decide to send Linux these events
      anywhere in the neighborhood of the fake
      override trip points.  Beware.
      
      note also that thermal.nocrt is already available
      to disable crtical trip point actios,
      and thermal.crt=-1 is already available to
      disabled critical trip points entirely.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      22a94d79
    • J
      driver core: basic infrastructure for per-module dynamic debug messages · 346e15be
      Jason Baron 提交于
      Base infrastructure to enable per-module debug messages.
      
      I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
      control of debugging statements on a per-module basis in one /proc file,
      currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
      is not set, debugging statements can still be enabled as before, often by
      defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
      affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.
      
      The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
      is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
      can be dynamically enabled/disabled on a per-module basis.
      
      Future plans include extending this functionality to subsystems, that define 
      their own debug levels and flags.
      
      Usage:
      
      Dynamic debugging is controlled by the debugfs file, 
      <debugfs>/dynamic_printk/modules. This file contains a list of the modules that
      can be enabled. The format of the file is as follows:
      
      	<module_name> <enabled=0/1>
      		.
      		.
      		.
      
      	<module_name> : Name of the module in which the debug call resides
      	<enabled=0/1> : whether the messages are enabled or not
      
      For example:
      
      	snd_hda_intel enabled=0
      	fixup enabled=1
      	driver enabled=0
      
      Enable a module:
      
      	$echo "set enabled=1 <module_name>" > dynamic_printk/modules
      
      Disable a module:
      
      	$echo "set enabled=0 <module_name>" > dynamic_printk/modules
      
      Enable all modules:
      
      	$echo "set enabled=1 all" > dynamic_printk/modules
      
      Disable all modules:
      
      	$echo "set enabled=0 all" > dynamic_printk/modules
      
      Finally, passing "dynamic_printk" at the command line enables
      debugging for all modules. This mode can be turned off via the above
      disable command.
      
      [gkh: minor cleanups and tweaks to make the build work quietly]
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      346e15be
  7. 11 10月, 2008 2 次提交
  8. 09 10月, 2008 1 次提交
  9. 23 9月, 2008 1 次提交
  10. 21 9月, 2008 1 次提交
  11. 19 9月, 2008 1 次提交
  12. 07 9月, 2008 2 次提交
  13. 29 8月, 2008 1 次提交
  14. 22 8月, 2008 2 次提交
  15. 21 8月, 2008 1 次提交
  16. 26 7月, 2008 2 次提交
  17. 25 7月, 2008 6 次提交
  18. 22 7月, 2008 1 次提交
    • K
      netfilter: accounting rework: ct_extend + 64bit counters (v4) · 58401572
      Krzysztof Piotr Oledzki 提交于
      Initially netfilter has had 64bit counters for conntrack-based accounting, but
      it was changed in 2.6.14 to save memory. Unfortunately in-kernel 64bit counters are
      still required, for example for "connbytes" extension. However, 64bit counters
      waste a lot of memory and it was not possible to enable/disable it runtime.
      
      This patch:
       - reimplements accounting with respect to the extension infrastructure,
       - makes one global version of seq_print_acct() instead of two seq_print_counters(),
       - makes it possible to enable it at boot time (for CONFIG_SYSCTL/CONFIG_SYSFS=n),
       - makes it possible to enable/disable it at runtime by sysctl or sysfs,
       - extends counters from 32bit to 64bit,
       - renames ip_conntrack_counter -> nf_conn_counter,
       - enables accounting code unconditionally (no longer depends on CONFIG_NF_CT_ACCT),
       - set initial accounting enable state based on CONFIG_NF_CT_ACCT
       - removes buggy IPCT_COUNTER_FILLING event handling.
      
      If accounting is enabled newly created connections get additional acct extend.
      Old connections are not changed as it is not possible to add a ct_extend area
      to confirmed conntrack. Accounting is performed for all connections with
      acct extend regardless of a current state of "net.netfilter.nf_conntrack_acct".
      Signed-off-by: NKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58401572
  19. 20 7月, 2008 1 次提交
  20. 18 7月, 2008 1 次提交
  21. 17 7月, 2008 2 次提交
  22. 16 7月, 2008 1 次提交
  23. 15 7月, 2008 1 次提交
  24. 12 7月, 2008 3 次提交
  25. 08 7月, 2008 1 次提交
    • P
      x86 boot: only pick up additional EFI memmap if add_efi_memmap flag · 200001eb
      Paul Jackson 提交于
      Applies on top of the previous patch:
        x86 boot: add code to add BIOS provided EFI memory entries to kernel
      
      Instead of always adding EFI memory map entries (if present) to the
      memory map after initially finding either E820 BIOS memory map entries
      and/or kernel command line memmap entries, -instead- only add such
      additional EFI memory map entries if the kernel boot option:
      
          add_efi_memmap
      
      is specified.
      
      Requiring this 'add_efi_memmap' option is backward compatible with
      kernels that didn't load such additional EFI memory map entries in
      the first place, and it doesn't override a configuration that tries
      to replace all E820 or EFI BIOS memory map entries with ones given
      entirely on the kernel command line.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Cc: "Jack Steiner" <steiner@sgi.com>
      Cc: "Mike Travis" <travis@sgi.com>
      Cc: "Huang
      Cc: Ying" <ying.huang@intel.com>
      Cc: "Andi Kleen" <andi@firstfloor.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      200001eb