22 Dec, 2010

1 commit


21 Dec, 2010

13 commits


20 Dec, 2010

3 commits

  • Linus reported that the new warning introduced by commit f26f9aff6aaf
    "Sched: fix skip_clock_update optimization" triggers. The need_resched
    flag can be set by other CPUs asynchronously so this debug check is
    bogus - remove it.

    Reported-by: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • …nel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86-32: Make sure we can map all of lowmem if we need to
    x86, vt-d: Handle previous faults after enabling fault handling
    x86: Enable the intr-remap fault handling after local APIC setup
    x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
    x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
    x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem()
    bootmem: Add alloc_bootmem_align()
    x86, gcc-4.6: Use gcc -m options when building vdso
    x86: HPET: Chose a paranoid safe value for the ETIME check
    x86: io_apic: Avoid unused variable warning when CONFIG_GENERIC_PENDING_IRQ=n

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    perf: Fix off by one in perf_swevent_init()
    perf: Fix duplicate events with multiple-pmu vs software events
    ftrace: Have recordmcount honor endianness in fn_ELF_R_INFO
    scripts/tags.sh: Add magic for trace-events
    tracing: Fix panic when lseek() called on "trace" opened for writing

    Linus Torvalds
     
  • …l/git/tip/linux-2.6-tip

    * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    sched: Fix the irqtime code for 32bit
    sched: Fix the irqtime code to deal with u64 wraps
    nohz: Fix get_next_timer_interrupt() vs cpu hotplug
    Sched: fix skip_clock_update optimization
    sched: Cure more NO_HZ load average woes

    Linus Torvalds
     

19 Dec, 2010

3 commits


18 Dec, 2010

20 commits

  • The current tile rt_sigreturn() syscall pattern uses the common idiom
    of loading up pt_regs with all the saved registers from the time of
    the signal, then anticipating the fact that we will clobber the ABI
    "return value" register (r0) as we return from the syscall by setting
    the rt_sigreturn return value to whatever random value was in the pt_regs
    for r0.

    However, this breaks in our 64-bit kernel when running "compat" tasks,
    since we always sign-extend the "return value" register to properly
    handle returned pointers that are in the upper 2GB of the 32-bit compat
    address space. Doing this to the sigreturn path then causes occasional
    random corruption of the 64-bit r0 register.

    Instead, we stop doing the crazy "load the return-value register"
    hack in sigreturn. We already have some sigreturn-specific assembly
    code that we use to pass the pt_regs pointer to C code. We extend that
    code to also set the link register to point to a spot a few instructions
    after the usual syscall return address so we don't clobber the saved r0.
    Now it no longer matters what the rt_sigreturn syscall returns, and the
    pt_regs structure can be cleanly and completely reloaded.

    Signed-off-by: Chris Metcalf

    Chris Metcalf
     
  • Previously we were just setting up the "tp" register in the
    new task as started by clone() in libc. However, this is not
    quite right, since in principle a signal might be delivered to
    the new task before it had its TLS set up. (Of course, this race
    window still exists for resetting the libc getpid() cached value
    in the new task, in principle. But in any case, we are now doing
    this exactly the way all other architectures do it.)

    This change is important for 2.6.37 since the tile glibc we will
    be submitting upstream will not set TLS in user space any more,
    so it will only work on a kernel that has this fix. It should
    also be taken for 2.6.36.x in the stable tree if possible.

    Signed-off-by: Chris Metcalf
    Cc: stable

    Chris Metcalf
     
  • The initial values of the registers 0x01 and 0x17 are taken from the sensor
    table at capture start and updated according to the flag PDN_INV.

    Their values are updated at each step of the capture initialization and
    memorized for reuse in capture stop.

    This patch also fixed automatically some bad hardcoded values of these
    registers.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
    value as other webcams with the same sensor. For now, only two webcams have
    been so detected: the Microsoft's VX1000 and VX3000.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • After Mauro's "bttv: Fix locking issues due to BKL removal code" there
    are a number of comments that are no longer needed about lock ordering.
    Remove them.

    Signed-off-by: Brandon Philips
    Signed-off-by: Mauro Carvalho Chehab

    Brandon Philips
     
  • Fix a regression where bttv driver causes oopses when loading, since it
    were using some non-initialized mutexes. While it would be possible to
    fix the issue, there are some other lock troubles, like to the presence of
    lock code at free_btres_lock().

    It is possible to fix, but the better is to just use the core-assisted
    locking schema. This way, V4L2 core will serialize access to all
    ioctl's/open/close/mmap/read/poll operations, avoiding to have two
    processes accessing the hardware at the same time. Also, as there's just
    one lock, instead of 3, there's no risk of dead locks.

    The net result is a cleaner code, with just one lock.

    Reported-by: Dan Carpenter
    Reported-by: Brandon Philips
    Reported-by: Chris Clayton
    Reported-by: Torsten Kaiser
    Tested-by: Chris Clayton
    Tested-by: Torsten Kaiser
    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • Seen with malta_defconfig on Linus' tree:

    CC arch/mips/mm/sc-mips.o
    arch/mips/mm/sc-mips.c: In function 'mips_sc_is_activated':
    arch/mips/mm/sc-mips.c:77: error: 'config2' undeclared (first use in this function)
    arch/mips/mm/sc-mips.c:77: error: (Each undeclared identifier is reported only once
    arch/mips/mm/sc-mips.c:77: error: for each function it appears in.)
    arch/mips/mm/sc-mips.c:81: error: 'tmp' undeclared (first use in this function)
    make[2]: *** [arch/mips/mm/sc-mips.o] Error 1
    make[1]: *** [arch/mips/mm] Error 2
    make: *** [arch/mips] Error 2

    [Ralf: Cosmetic changes to minimize the number of arguments passed to
    mips_sc_is_activated]

    Signed-off-by: Kevin Cernekee
    Patchwork: https://patchwork.linux-mips.org/patch/1752/
    Signed-off-by: Ralf Baechle

    Kevin Cernekee
     
  • This prevents allocation of the last 2MB before 4GB.

    The experiment described here shows Windows 7 ignoring the last 1MB:
    https://bugzilla.kernel.org/show_bug.cgi?id=23542#c27

    This patch ignores the top 2MB instead of just 1MB because H. Peter Anvin
    says "There will be ROM at the top of the 32-bit address space; it's a fact
    of the architecture, and on at least older systems it was common to have a
    shadow 1 MiB below."

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • When we allocate address space, e.g., to assign it to a PCI device, don't
    allocate anything mentioned in the BIOS E820 memory map.

    On recent machines (2008 and newer), we assign PCI resources from the
    windows described by the ACPI PCI host bridge _CRS. On many Dell
    machines, these windows overlap some E820 reserved areas, e.g.,

    BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved)
    pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]

    If we put devices at 0xbff00000, they don't work, probably because
    that's really RAM, not I/O memory. This patch prevents that by removing
    the 0xbfe4dc00-0xbfffffff area from the "available" resource.

    I'm not very happy with this solution because Windows solves the problem
    differently (it seems to ignore E820 reserved areas and it allocates
    top-down instead of bottom-up; details at comment 45 of the bugzilla
    below). That means we're vulnerable to BIOS defects that Windows would not
    trip over. For example, if BIOS described a device in ACPI but didn't
    mention it in E820, Windows would work fine but Linux would fail.

    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228
    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This implements arch_remove_reservations() so allocate_resource() can
    avoid any arch-specific reserved areas. This currently just avoids the
    BIOS area (the first 1MB), but could be used for E820 reserved areas if
    that turns out to be necessary.

    We previously avoided this area in pcibios_align_resource(). This patch
    moves the test from that PCI-specific path to a generic path, so *all*
    resource allocations will avoid this area.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This adds arch_remove_reservations(), which an arch can implement if it
    needs to protect part of the address space from allocation.

    Sometimes that can be done by just putting a region in the resource tree,
    but there are cases where that doesn't work well. For example, x86 BIOS
    E820 reservations are not related to devices, so they may overlap part of,
    all of, or more than a device resource, so they may not end up at the
    correct spot in the resource tree.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This reverts commit e7f8567db9a7f6b3151b0b275e245c1cef0d9c70.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This reverts commit b126b4703afa4010b161784a43650337676dd03b.

    We're going back to the old behavior of allocating from bus resources
    in _CRS order.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This reverts commit dc9887dc02e37bcf83f4e792aa14b07782ef54cf.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This reverts commit 1af3c2e45e7a641e774bbb84fa428f2f0bf2d9c9.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This reverts commit 82e3e767c21fef2b1b38868e20eb4e470a1e38e3.

    We're going back to considering bus resources in the order we found
    them (in _CRS order, when we're using _CRS), so we don't need to
    define any ordering.

    Acked-by: H. Peter Anvin
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas