23 Dec, 2011

1 commit

  • This silently was working for many years and stopped working on
    Niagara-T3 machines.

    We need to set the MSIQ to VALID before we can set it's state to IDLE.

    On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
    errors. The hypervisor documentation says, rather ambiguously, that
    the MSIQ must be "initialized" before one can set the state.

    I previously understood this to mean merely that a successful setconf()
    operation has been performed on the MSIQ, which we have done at this
    point. But it seems to also mean that it has been set VALID too.

    Signed-off-by: David S. Miller

    David S. Miller
     

22 Dec, 2011

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
    net: Add a flow_cache_flush_deferred function
    ipv4: reintroduce route cache garbage collector
    net: have ipconfig not wait if no dev is available
    sctp: Do not account for sizeof(struct sk_buff) in estimated rwnd
    asix: new device id
    davinci-cpdma: fix locking issue in cpdma_chan_stop
    sctp: fix incorrect overflow check on autoclose
    r8169: fix Config2 MSIEnable bit setting.
    llc: llc_cmsg_rcv was getting called after sk_eat_skb.
    net: bpf_jit: fix an off-one bug in x86_64 cond jump target
    iwlwifi: update SCD BC table for all SCD queues
    Revert "Bluetooth: Revert: Fix L2CAP connection establishment"
    Bluetooth: Clear RFCOMM session timer when disconnecting last channel
    Bluetooth: Prevent uninitialized data access in L2CAP configuration
    iwlwifi: allow to switch to HT40 if not associated
    iwlwifi: tx_sync only on PAN context
    mwifiex: avoid double list_del in command cancel path
    ath9k: fix max phy rate at rate control init
    nfc: signedness bug in __nci_request()
    iwlwifi: do not set the sequence control bit is not needed

    Linus Torvalds
     

21 Dec, 2011

4 commits


20 Dec, 2011

3 commits

  • When printing the code bytes in show_registers(), the markers around the
    byte at the fault address could make the printk() format string look
    like a valid log level and facility code. This would prevent this byte
    from being printed and result in a spurious newline:

    [ 7555.765589] Code: 8b 32 e9 94 00 00 00 81 7d 00 ff 00 00 00 0f 87 96 00 00 00 48 8b 83 c0 00 00 00 44 89 e2 44 89 e6 48 89 df 48 8b 80 d8 02 00 00
    [ 7555.765683] 8b 48 28 48 89 d0 81 e2 ff 0f 00 00 48 c1 e8 0c 48 c1 e0 04

    Add KERN_CONT where needed, and elsewhere in show_registers() for
    consistency.

    Signed-off-by: Clemens Ladisch
    Link: http://lkml.kernel.org/r/4EEFA7AE.9020407@ladisch.de
    Signed-off-by: H. Peter Anvin

    Clemens Ladisch
     
  • x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6
    bytes.

    In case a conditional jump is followed by a long jump, conditional jump
    target is one byte past the start of target instruction.

    Signed-off-by: Markus Kötter
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Markus Kötter
     
  • If oprofilefs_ulong_from_user() is called with count equals
    zero, *val remains unchanged. Depending on the implementation it
    might be uninitialized.

    Change oprofilefs_ulong_from_user()'s interface to return count
    on success. Thus, we are able to return early if count equals
    zero which avoids using *val uninitialized. Fixing all users of
    oprofilefs_ulong_ from_user().

    This follows write syscall implementation when count is zero:
    "If count is zero ... [and if] no errors are detected, 0 will be
    returned without causing any other effect." (man 2 write)

    Reported-By: Mike Waychison
    Signed-off-by: Robert Richter
    Cc: Andrew Morton
    Cc:
    Cc: oprofile-list
    Link: http://lkml.kernel.org/r/20111219153830.GH16765@erda.amd.com
    Signed-off-by: Ingo Molnar

    Robert Richter
     

17 Dec, 2011

2 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
    sparc32: Be less strict in matching %lo part of relocation.
    sbus: convert drivers/sbus/char/* to use module_platform_driver()
    bbc_i2c: Remove unneeded err variable
    sparc: Use kmemdup rather than duplicating its implementation

    Linus Torvalds
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
    ARM: OMAP: rx51: fix USB
    ARM: OMAP: mcbsp: Fix possible memory corruption
    arm/imx: fix power button on imx51 babbage board
    ARM: imx: fix cpufreq build errors
    ARM: mx5: add __initconst for fec pdata
    MXC PWM: should active during DOZE/WAIT/DBG mode
    ARM: EXYNOS: Fix build error without CONFIG_LOCAL_TIMERS
    ARM: EXYNOS: Fix for stall in case of cpu hotplug or sleep
    ARM: S5PV210: Set 1000ns as PWM backlight period on SMDKV210
    ARM: SAMSUNG: remove duplicated header include

    Linus Torvalds
     

16 Dec, 2011

5 commits

  • …kgene/linux-samsung into fixes

    Olof Johansson
     
  • Olof Johansson
     
  • The bisection implemented in unwind_find_origin() stopped to early. If
    there is only a single entry left to check the original code just took
    the end point as origin which might be wrong.

    This was introduced in commit de66a979012d ("ARM: 7187/1: fix unwinding
    for XIP kernels").

    Reported-and-tested-by: Nick Bowler
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     
  • …kernel/git/konrad/xen

    * 'stable/for-linus-fixes-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
    xen/swiotlb: Use page alignment for early buffer allocation.
    xen: only limit memory map to maximum reservation for domain 0.

    Linus Torvalds
     
  • d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
    clamped the total amount of RAM to the current maximum reservation. This is
    correct for dom0 but is not correct for guest domains. In order to boot a guest
    "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
    future memory expansion the guest must derive max_pfn from the e820 provided by
    the toolstack and not the current maximum reservation (which can reflect only
    the current maximum, not the guest lifetime max). The existing algorithm
    already behaves this correctly if we do not artificially limit the maximum
    number of pages for the guest case.

    For a guest booted with maxmem=512, memory=128 this results in:
    [ 0.000000] BIOS-provided physical RAM map:
    [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
    [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
    -[ 0.000000] Xen: 0000000000100000 - 0000000008100000 (usable)
    -[ 0.000000] Xen: 0000000008100000 - 0000000020800000 (unusable)
    +[ 0.000000] Xen: 0000000000100000 - 0000000020800000 (usable)
    ...
    [ 0.000000] NX (Execute Disable) protection: active
    [ 0.000000] DMI not present or invalid.
    [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
    [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
    -[ 0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
    +[ 0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
    [ 0.000000] initial memory mapped : 0 - 027ff000
    [ 0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
    -[ 0.000000] init_memory_mapping: 0000000000000000-0000000008100000
    -[ 0.000000] 0000000000 - 0008100000 page 4k
    -[ 0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
    +[ 0.000000] init_memory_mapping: 0000000000000000-0000000020800000
    +[ 0.000000] 0000000000 - 0020800000 page 4k
    +[ 0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
    [ 0.000000] xen: setting RW the range 27e8000 - 27ff000
    [ 0.000000] 0MB HIGHMEM available.
    -[ 0.000000] 129MB LOWMEM available.
    -[ 0.000000] mapped low ram: 0 - 08100000
    -[ 0.000000] low ram: 0 - 08100000
    +[ 0.000000] 520MB LOWMEM available.
    +[ 0.000000] mapped low ram: 0 - 20800000
    +[ 0.000000] low ram: 0 - 20800000

    With this change "xl mem-set 512M" will successfully increase the
    guest RAM (by reducing the balloon).

    There is no change for dom0.

    Reported-and-Tested-by: George Shuklin
    Signed-off-by: Ian Campbell
    Cc: stable@kernel.org
    Reviewed-by: David Vrabel
    Signed-off-by: Konrad Rzeszutek Wilk

    Ian Campbell
     

15 Dec, 2011

1 commit


14 Dec, 2011

4 commits


13 Dec, 2011

2 commits

  • Commits 09d28d ("ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src")
    and 7bc0c4 ("ARM: OMAP: mcbsp: Start generalize signal muxing functions")
    incorrectly set two struct omap_mcbsp_platform_data fields after
    omap_device_build_ss and kfree calls.

    Fix this by moving these pdata assignments before those calls.

    Signed-off-by: Jarkko Nikula
    Reported-by: NeilBrown
    Signed-off-by: Tony Lindgren

    Jarkko Nikula
     
  • This hangs my MacBook Air at boot time; I get no console
    messages at all. I reverted this on top of -rc5 and my machine
    boots again.

    This reverts commit e8c7106280a305e1ff2a3a8a4dfce141469fb039.

    Signed-off-by: Matt Fleming
    Signed-off-by: Keith Packard
    Acked-by: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console
    Signed-off-by: Ingo Molnar

    Keith Packard
     

12 Dec, 2011

1 commit


10 Dec, 2011

4 commits

  • efi_call_phys_prelog() sets up a 1:1 mapping of the physical address
    range in swapper_pg_dir. Instead of replacing then restoring entries
    in swapper_pg_dir we should be using initial_page_table which already
    contains the 1:1 mapping.

    It's safe to blindly switch back to swapper_pg_dir in the epilog
    because the physical EFI routines are only called before
    efi_enter_virtual_mode(), e.g. before any user processes have been
    forked. Therefore, we don't need to track which pgd was in %cr3 when
    we entered the prelog.

    The previous code actually contained a bug because it assumed that the
    kernel was loaded at a physical address within the first 8MB of ram,
    usually at 0x100000. However, this isn't the case with a
    CONFIG_RELOCATABLE=y kernel which could have been loaded anywhere in
    the physical address space.

    Also delete the ancient (and bogus) comments about the page table
    being restored after the lock is released. There is no locking.

    Cc: Matthew Garrett
    Cc: Darrent Hart
    Signed-off-by: Matt Fleming
    Link: http://lkml.kernel.org/r/1323346250.3894.74.camel@mfleming-mobl1.ger.corp.intel.com
    Signed-off-by: H. Peter Anvin

    Matt Fleming
     
  • * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86, efi: Calling __pa() with an ioremap()ed address is invalid
    x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked
    x86/intel_mid: Kconfig select fix
    x86/intel_mid: Fix the Kconfig for MID selection

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
    arch/tile: use new generic {enable,disable}_percpu_irq() routines
    drivers/net/ethernet/tile: use skb_frag_page() API
    asm-generic/unistd.h: support new process_vm_{readv,write} syscalls
    arch/tile: fix double-free bug in homecache_free_pages()
    arch/tile: add a few #includes and an EXPORT to catch up with kernel changes.

    Linus Torvalds
     
  • * 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
    MAINTAINERS: Update amd-iommu F: patterns
    iommu/amd: Fix typo in kernel-parameters.txt
    iommu/msm: Fix compile error in mach-msm/devices-iommu.c
    Fix comparison using wrong pointer variable in dma debug code

    Linus Torvalds
     

09 Dec, 2011

8 commits

  • With the 3.2-rc kernel, IOMMU 2M pages in KVM works. But when I tried
    to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page
    failed to be used.

    The root cause is that 1GB page allocation calls gup_huge_pud() while 2M
    page calls gup_huge_pmd. If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that.

    So when the mapped page is relesed, it will result in kernel oops
    because the page is not marked mapped.

    This patch add tail process for compound page in 1GB huge page which
    keeps the same process as 2M page.

    Reproduce like:
    1. Add grub boot option: hugepagesz=1G hugepages=8
    2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages
    3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages
    -net none -device pci-assign,host=07:00.1

    kernel BUG at mm/swap.c:114!
    invalid opcode: 0000 [#1] SMP
    Call Trace:
    put_page+0x15/0x37
    kvm_release_pfn_clean+0x31/0x36
    kvm_iommu_put_pages+0x94/0xb1
    kvm_iommu_unmap_memslots+0x80/0xb6
    kvm_assign_device+0xba/0x117
    kvm_vm_ioctl_assigned_device+0x301/0xa47
    kvm_vm_ioctl+0x36c/0x3a2
    do_vfs_ioctl+0x49e/0x4e4
    sys_ioctl+0x5a/0x7c
    system_call_fastpath+0x16/0x1b
    RIP put_compound_page+0xd4/0x168

    Signed-off-by: Youquan Song
    Reviewed-by: Andrea Arcangeli
    Cc: Andi Kleen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Youquan Song
     
  • Since commit 6571534 (plat-mxc: iomux-v3.h: implicitly enable
    pull-up/down when that's desired) was in, the power button on imx51
    babbage board stopped working because it's pulled up by mistake.
    The patch removes the pull-up setting from the pad configuration for
    that gpio to make the power button back to work.

    Signed-off-by: Shawn Guo
    Signed-off-by: Sascha Hauer

    Shawn Guo
     
  • CC arch/arm/plat-mxc/cpufreq.o
    arch/arm/plat-mxc/cpufreq.c:203: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:203: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:203: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
    arch/arm/plat-mxc/cpufreq.c:203: warning: function declaration isn't a prototype
    arch/arm/plat-mxc/cpufreq.c:204: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:204: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:204: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
    arch/arm/plat-mxc/cpufreq.c:204: warning: function declaration isn't a prototype
    arch/arm/plat-mxc/cpufreq.c:205: error: expected declaration specifiers or '...' before string constant
    arch/arm/plat-mxc/cpufreq.c:205: warning: data definition has no type or storage class
    arch/arm/plat-mxc/cpufreq.c:205: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
    arch/arm/plat-mxc/cpufreq.c:205: warning: function declaration isn't a prototype
    make[1]: *** [arch/arm/plat-mxc/cpufreq.o] Error 1
    make: *** [arch/arm/plat-mxc] Error 2

    Signed-off-by: Richard Zhao
    Signed-off-by: Richard Zhao
    Signed-off-by: Sascha Hauer

    Richard Zhao
     
  • Signed-off-by: Dong Aisheng
    Acked-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Dong Aisheng
     
  • Signed-off-by: Jason Chen
    Signed-off-by: Sascha Hauer
    Cc: stable@kernel.org

    Jason Chen
     
  • If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
    in ->attribute we currently call set_memory_uc(), which in turn
    calls __pa() on a potentially ioremap'd address.

    On CONFIG_X86_32 this is invalid, resulting in the following
    oops on some machines:

    BUG: unable to handle kernel paging request at f7f22280
    IP: [] reserve_ram_pages_type+0x89/0x210
    [...]

    Call Trace:
    [] ? page_is_ram+0x1a/0x40
    [] reserve_memtype+0xdf/0x2f0
    [] set_memory_uc+0x49/0xa0
    [] efi_enter_virtual_mode+0x1c2/0x3aa
    [] start_kernel+0x291/0x2f2
    [] ? loglevel+0x1b/0x1b
    [] i386_start_kernel+0xbf/0xc8

    A better approach to this problem is to map the memory region
    with the correct attributes from the start, instead of modifying
    it after the fact. The uncached case can be handled by
    ioremap_nocache() and the cached by ioremap_cache().

    Despite first impressions, it's not possible to use
    ioremap_cache() to map all cached memory regions on
    CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
    don't like being mapped into the vmalloc space, as detailed in
    the following bug report,

    https://bugzilla.redhat.com/show_bug.cgi?id=748516

    Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
    regions are covered by the direct kernel mapping table on
    CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
    regions via the direct kernel mapping with the initial call to
    init_memory_mapping() in setup_arch(), whereas previously these
    regions wouldn't be mapped if they were after the last E820_RAM
    region until efi_ioremap() was called. Doing it this way allows
    us to delete efi_ioremap() completely.

    Signed-off-by: Matt Fleming
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
    Signed-off-by: Ingo Molnar

    Matt Fleming
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits)
    ARM: sa1100: fix build error
    ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
    ARM: davinci: dm365 evm: align nand partition table to u-boot
    ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0
    ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode
    ARM: davinci: dm646x does not have a DSP domain
    ARM: davinci: psc: fix incorrect offsets
    ARM: davinci: psc: fix incorrect mask
    ARM: mx28: LRADC macro rename
    arm: mx23: recognise stmp378x as mx23
    ARM: mxs: fix machines' initializers order
    ARM: mxs/tx28: add __initconst for fec pdata
    ARM: S3C64XX: Staticise s3c6400_sysclass
    ARM: S3C64XX: Add linux/export.h to dev-spi.c
    ARM: S3C64XX: Remove extern from definition of framebuffer setup call
    MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers
    MAINTAINERS: Add linux-samsung-soc mailing list for Samsung
    MAINTAINERS: Consolidate Samsung MAINTAINERS
    ARM: CSR: PM: fix build error due to undeclared 'THIS_MODULE'
    ARM: CSR: fix build error due to new mdesc->dma_zone_size
    ...

    Linus Torvalds
     
  • When HPET is operating in RTC mode, the TN_ENABLE bit on timer1
    controls whether the HPET or the RTC delivers interrupts to irq8. When
    the system goes into suspend, the RTC driver sends a signal to the
    HPET driver so that the HPET releases control of irq8, allowing the
    RTC to wake the system from suspend. The switchover is accomplished by
    a write to the HPET configuration registers which currently only
    occurs while servicing the HPET interrupt.

    On some systems, I have seen the system suspend before an HPET
    interrupt occurs, preventing the write to the HPET configuration
    register and leaving the HPET in control of the irq8. As the HPET is
    not active during suspend, it does not generate a wake signal and RTC
    alarms do not work.

    This patch forces the HPET driver to immediately transfer control of
    the irq8 channel to the RTC instead of waiting until the next
    interrupt event.

    Signed-off-by: Mark Langsdorf
    Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com
    Tested-by: Andreas Herrmann
    Signed-off-by: Andreas Herrmann
    Signed-off-by: Thomas Gleixner
    Cc: stable@vger.kernel.org

    Mark Langsdorf
     

08 Dec, 2011

4 commits