1. 04 8月, 2010 1 次提交
    • F
      x86, hwmon: Package Level Thermal/Power: pkgtemp hwmon driver · cb84b194
      Fenghua Yu 提交于
      This patch adds a hwmon driver for package level thermal control. The driver
      dumps package level thermal information through sysfs interface so that upper
      level application (e.g. lm_sensor) can retrive the information.
      
      Instead of having the package level hwmon code in coretemp, I write a seperate
      driver pkgtemp because:
      
      First, package level thermal sensors include not only sensors for each core,
      but also sensors for uncore, memory controller or other components in the
      package. Logically it will be clear to have a seperate hwmon driver for package
      level hwmon to monitor wider range of sensors in a package. Merging package
      thermal driver into core thermal driver doesn't make sense and may mislead.
      
      Secondly, merging the two drivers together may cause coding mess. It's easier
      to include various package level sensors info if more sensor information is
      implemented. Coretemp code needs to consider a lot of legacy machine cases.
      Pkgtemp code only considers platform starting from Sandy Bridge.
      
      On a 1Sx4Cx2T Sandy Bridge platform, lm-sensors dumps the pkgtemp and coretemp:
      
      pkgtemp-isa-0000
      Adapter: ISA adapter
      physical id 0: +33.0°C  (high = +79.0°C, crit = +99.0°C)
      
      coretemp-isa-0000
      Adapter: ISA adapter
      Core 0:      +32.0°C  (high = +79.0°C, crit = +99.0°C)
      
      coretemp-isa-0001
      Adapter: ISA adapter
      Core 1:      +32.0°C  (high = +79.0°C, crit = +99.0°C)
      
      coretemp-isa-0002
      Adapter: ISA adapter
      Core 2:      +32.0°C  (high = +79.0°C, crit = +99.0°C)
      
      coretemp-isa-0003
      Adapter: ISA adapter
      Core 3:      +32.0°C  (high = +79.0°C, crit = +99.0°C)
      
      [ hpa: folded v3 patch removing improper global variable "SHOW" ]
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      LKML-Reference: <1280448826-12004-3-git-send-email-fenghua.yu@intel.com>
      Reviewed-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      cb84b194
  2. 31 7月, 2010 1 次提交
  3. 29 7月, 2010 4 次提交
  4. 26 7月, 2010 8 次提交
  5. 25 7月, 2010 1 次提交
  6. 23 7月, 2010 9 次提交
  7. 22 7月, 2010 4 次提交
  8. 21 7月, 2010 2 次提交
    • D
      Input: twl40300-keypad - fix handling of "all ground" rows · 3fea6026
      Dmitry Torokhov 提交于
      The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c)
      defines a key map for the matrix keypad keyboard. The hardware seems to
      use all of the 8 rows and 8 columns of the keypad, although not all
      possible locations are used.
      
      The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys
      are defined with a row and column number between 0 and 7, except
      
              KEY(0xff, 2, KEY_F9),
              KEY(0xff, 4, KEY_F10),
              KEY(0xff, 5, KEY_F11),
      
      which represent keycodes that should be emitted when entire row is
      connected to the ground.  since the driver handles this case as if we
      had an extra column in the key matrix. Unfortunately we do not allocate
      enough space and end up owerwriting some random memory.
      Reported-and-tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: stable@kernel.org
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3fea6026
    • Y
      x86, numa: fix boot without RAM on node0 again · 9aebbdb6
      Yinghai Lu 提交于
      Commit e534c7c5 ("numa: x86_64: use generic percpu var
      numa_node_id() implementation") broke numa systems that don't have ram
      on node0 when MEMORY_HOTPLUG is enabled, because cpu_up() will call
      cpu_to_node() before per_cpu(numa_node) is setup for APs.
      
      When Node0 doesn't have RAM, on x86, cpus already round it to nearest
      node with RAM in x86_cpu_to_node_map.  and per_cpu(numa_node) is not set
      up until in c_init for APs.
      
      When later cpu_up() calling cpu_to_node() will get 0 again, and make it
      online even there is no RAM on node0.  so later all APs can not booted up,
      and later will have panic.
      
      [    1.611101] On node 0 totalpages: 0
      .........
      [    2.608558] On node 0 totalpages: 0
      [    2.612065] Brought up 1 CPUs
      [    2.615199] Total of 1 processors activated (3990.31 BogoMIPS).
      ...
         93.225341] calling  loop_init+0x0/0x1a4 @ 1
      [   93.229314] PERCPU: allocation failed, size=80 align=8, failed to populate
      [   93.246539] Pid: 1, comm: swapper Tainted: G        W   2.6.35-rc4-tip-yh-04371-gd64e6c4-dirty #354
      [   93.264621] Call Trace:
      [   93.266533]  [<ffffffff81125e43>] pcpu_alloc+0x83a/0x8e7
      [   93.270710]  [<ffffffff81125f15>] __alloc_percpu+0x10/0x12
      [   93.285849]  [<ffffffff8140786c>] alloc_disk_node+0x94/0x16d
      [   93.291811]  [<ffffffff81407956>] alloc_disk+0x11/0x13
      [   93.306157]  [<ffffffff81503e51>] loop_alloc+0xa7/0x180
      [   93.310538]  [<ffffffff8277ef48>] loop_init+0x9b/0x1a4
      [   93.324909]  [<ffffffff8277eead>] ? loop_init+0x0/0x1a4
      [   93.329650]  [<ffffffff810001f2>] do_one_initcall+0x57/0x136
      [   93.345197]  [<ffffffff827486d0>] kernel_init+0x184/0x20e
      [   93.348146]  [<ffffffff81034954>] kernel_thread_helper+0x4/0x10
      [   93.365194]  [<ffffffff81c7cc3c>] ? restore_args+0x0/0x30
      [   93.369305]  [<ffffffff8274854c>] ? kernel_init+0x0/0x20e
      [   93.386011]  [<ffffffff81034950>] ? kernel_thread_helper+0x0/0x10
      [   93.392047] loop: out of memory
      ...
      
      Try to assign per_cpu(numa_node) early
      
      [akpm@linux-foundation.org: tidy up code comment]
      Signed-off-by: NYinghai <yinghai@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Acked-by: NLee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9aebbdb6
  9. 20 7月, 2010 5 次提交
  10. 19 7月, 2010 2 次提交
  11. 17 7月, 2010 3 次提交
    • J
      x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chain · f82c3d71
      Jacob Pan 提交于
      The fixed bar capability structure is searched in PCI extended
      configuration space.  We need to make sure there is a valid capability
      ID to begin with otherwise, the search code may stuck in a infinite
      loop which results in boot hang.  This patch adds additional check for
      cap ID 0, which is also invalid, and indicates end of chain.
      
      End of chain is supposed to have all fields zero, but that doesn't
      seem to always be the case in the field.
      Suggested-by: N"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      f82c3d71
    • Y
      x86: Fix x2apic preenabled system with kexec · fd19dce7
      Yinghai Lu 提交于
      Found one x2apic system kexec loop test failed
      when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip)
      
      first kernel can kexec second kernel, but second kernel can not kexec third one.
      
      it can be duplicated on another system with BIOS preenabled x2apic.
      First kernel can not kexec second kernel.
      
      It turns out, when kernel boot with pre-enabled x2apic, it will not execute
      disable_local_APIC on shutdown path.
      
      when init_apic_mappings() is called in setup_arch, it will skip setting of
      apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic())
      Then later, disable_local_APIC() will bail out early because !apic_phys.
      
      So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys.
      
      another solution could be updating init_apic_mappings() to set apic_phys even
      for preenabled x2apic system. Actually even for x2apic system, that lapic
      address is mapped already in early stage.
      
      BTW: is there any x2apic preenabled system with apicid of boot cpu > 255?
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4C3EB22B.3000701@kernel.org>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fd19dce7
    • B
      PCI: fall back to original BIOS BAR addresses · 58c84eda
      Bjorn Helgaas 提交于
      If we fail to assign resources to a PCI BAR, this patch makes us try the
      original address from BIOS rather than leaving it disabled.
      
      Linux tries to make sure all PCI device BARs are inside the upstream
      PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
      Windows does similar reassignment.
      
      Before this patch, if we could not move a BAR into an aperture, we left
      the resource unassigned, i.e., at address zero.  Windows leaves such BARs
      at the original BIOS addresses, and this patch makes Linux do the same.
      
      This is a bit ugly because we disable the resource long before we try to
      reassign it, so we have to keep track of the BIOS BAR address somewhere.
      For lack of a better place, I put it in the struct pci_dev.
      
      I think it would be cleaner to attempt the assignment immediately when the
      claim fails, so we could easily remember the original address.  But we
      currently claim motherboard resources in the middle, after attempting to
      claim PCI resources and before assigning new PCI resources, and changing
      that is a fairly big job.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263Reported-by: NAndrew <nitr0@seti.kr.ua>
      Tested-by: NAndrew <nitr0@seti.kr.ua>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      58c84eda
反馈
建议
客服 返回
顶部