1. 10 Dec, 2012 3 commits
    • Jianguo Wu's avatar
      mm/vmemmap: fix wrong use of virt_to_page · 8bec6507
      Jianguo Wu authored
      commit ae64ffca upstream.
      
      I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing
      memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20.
      
      It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is
      only used for kernel direct mapping address, but sparse-vmemmap uses
      vmemmap address, so it is going wrong here.
      
        ------------[ cut here ]------------
        kernel BUG at arch/x86/mm/physaddr.c:20!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
        CPU 39
        Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ #45 QCI QSSC-S4R/QSSC-S4R
        RIP: 0010:[<ffffffff8103c908>]  [<ffffffff8103c908>] __phys_addr+0x88/0x90
        RSP: 0018:ffff8804440d7c08  EFLAGS: 00010006
        RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c
        ...
      Signed-off-by: default avatarJianguo Wu <wujianguo@huawei.com>
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Reviewd-by: default avatarWen Congyang <wency@cn.fujitsu.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8bec6507
    • Russell King - ARM Linux's avatar
      Dove: Fix irq_to_pmu() · 6d62cb39
      Russell King - ARM Linux authored
      commit d356cf5a upstream.
      
      PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1.
      Fix the condition.  (It may have been less likely to occur had the code
      been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier
      to understand notation, and matches the normal way of thinking about
      these things.)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d62cb39
    • Russell King - ARM Linux's avatar
      Dove: Attempt to fix PMU/RTC interrupts · 31a2aa11
      Russell King - ARM Linux authored
      commit 5d3df935 upstream.
      
      Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
      has not been sensibly designed so that interrupts can be handled in a
      race free manner.  The PMU is one such instance.
      
      The pending (aka 'cause') register is a bunch of RW bits, meaning that
      these bits can be both cleared and set by software (confirmed on the
      Armada-510 on the cubox.)
      
      Hardware sets the appropriate bit when an interrupt is asserted, and
      software is required to clear the bits which are to be processed.  If
      we write ~(1 << bit), then we end up asserting every other interrupt
      except the one we're processing.  So, we need to do a read-modify-write
      cycle to clear the asserted bit.
      
      However, any interrupts which occur in the middle of this cycle will
      also be written back as zero, which will also clear the new interrupts.
      
      The upshot of this is: there is _no_ way to safely clear down interrupts
      in this register (and other similarly behaving interrupt pending
      registers on this device.)  The patch below at least stops us creating
      new interrupts.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31a2aa11
  2. 06 Dec, 2012 2 commits
  3. 03 Dec, 2012 35 commits