29 May, 2009

1 commit


27 May, 2009

23 commits

  • …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: avoid back to back on_each_cpu in cpa_flush_array
    x86, relocs: ignore R_386_NONE in kernel relocation entries

    Linus Torvalds
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
    drm/i915: Add support for VGA load detection (pre-945).
    drm/i915: Use an I2C algo to do the flip to SDVO DDC bus.
    drm/i915: Determine type before initialising connector
    drm/i915: Return SDVO LVDS VBT mode if no EDID modes are detected.
    drm/i915: Fetch SDVO LVDS mode lines from VBT, then reserve them
    i915: support 8xx desktop cursors
    drm/i915: allocate large pointer arrays with vmalloc

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

    * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    oprofile: fix cpu buffer size

    Linus Torvalds
     
  • Cleanup cpa_flush_array() to avoid back to back on_each_cpu() calls.

    [ Impact: optimizes fix 0af48f42df15b97080b450d24219dd95db7b929a ]

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: H. Peter Anvin

    Pallipadi, Venkatesh
     
  • * 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
    NFSv4: Fix the case where NFSv4 renewal fails
    nfs: fix build error in nfsroot with initconst
    XPRTRDMA: fix client rpcrdma FRMR registration on mlx4 devices

    Linus Torvalds
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
    ALSA: hda - Add missing check of pin vref 50 and others in Realtek codecs
    ALSA: hda - Add 5stack-no-fp model for STAC927x
    ALSA: hda - Add forced codec-slots for ASUS W5Fm

    Linus Torvalds
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
    [CPUFREQ] powernow-k8: determine exact CPU frequency for HW Pstates
    [CPUFREQ] powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
    [CPUFREQ] fix timer teardown in ondemand governor
    [CPUFREQ] fix timer teardown in conservative governor
    [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call
    [CPUFREQ] powernow-k7 build fix when ACPI=n
    [CPUFREQ] add atom family to p4-clockmod

    Linus Torvalds
     
  • When KVM is loaded, and hence VT set up, the vmcall instruction in an
    lguest guest causes a #GP, not #UD.

    Signed-off-by: Rusty Russell
    Signed-off-by: Linus Torvalds

    Rusty Russell
     
  • call_usermodehelper_setup() forgot to kfree(sub_info)
    when prepare_usermodehelper_creds() failed.

    Signed-off-by: Tetsuo Handa
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Tetsuo Handa
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (21 commits)
    r8169: avoid losing MSI interrupts
    tcp: tcp_vegas ssthresh bugfix
    mac8390: fix regression caused during net_device_ops conversion
    gianfar: fix BUG under load after introduction of skb recycling
    wimax/i2400m: usb: fix device reset on autosuspend while not yet idle
    RxRPC: Error handling for rxrpc_alloc_connection()
    ipv4: Fix oops with FIB_TRIE
    pktgen: do not access flows[] beyond its length
    gigaset: beyond ARRAY_SIZE of iwb->data
    IPv6: set RTPROT_KERNEL to initial route
    net: fix rtable leak in net/ipv4/route.c
    net: fix length computation in rt_check_expire()
    wireless: beyond ARRAY_SIZE of intf->crypto_stats
    iwlwifi: update 5000 ucode support to version 2 of API
    cfg80211: fix race between core hint and driver's custom apply
    airo: fix airo_get_encode{,ext} buffer overflow like I mean it...
    ath5k: fix interpolation with equal power levels
    iwlwifi: do not cancel delayed work inside spin_lock_irqsave
    ath5k: fix exp off-by-one when computing OFDM delta slope
    wext: verify buffer size for SIOCSIWENCODEEXT
    ...

    Linus Torvalds
     
  • * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
    powerpc/mm: Fix broken MMU PID stealing on !SMP

    Linus Torvalds
     
  • * 'for-linus' of git://neil.brown.name/md:
    md: don't use locked_ioctl.
    md: don't update curr_resync_completed without also updating reshape_position.
    md: raid5: avoid sector values going negative when testing reshape progress.
    md: export 'frozen' resync state through sysfs
    md: bitmap: improve bitmap maintenance code.
    md: improve errno return when setting array_size
    md: always update level / chunk_size / layout when writing v1.x metadata.

    Linus Torvalds
     
  • If the asynchronous lease renewal fails (usually due to a soft timeout),
    then we _must_ schedule state recovery in order to ensure that we don't
    lose the lease unnecessarily or, if the lease is already lost, that we
    recover the locking state promptly...

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • fix build error with latest kbuild adjustments to initconst.

    The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
    const for kernel parser table") changed:

    static match_table_t __initdata tokens = {
    to
    static match_table_t __initconst tokens = {

    But the missing const causes popwerpc to fail with latest
    updates to __initconst like this:

    fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
    fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict

    The bug is only present with kbuild-next.
    Following patch has been build tested.

    Signed-off-by: Sam Ravnborg
    Cc: Steven Whitehouse
    Cc: Stephen Rothwell
    Acked-by: Jan Beulich
    Signed-off-by: Trond Myklebust

    Sam Ravnborg
     
  • mlx4/connectX FRMR requires local write enable together with remote
    rdma write enable. This fixes NFS/RDMA operation over the ConnectX
    Infiniband HCA in the default memreg mode.

    Signed-off-by: Vu Pham
    Signed-off-by: Tom Talpey
    Signed-off-by: Trond Myklebust

    Vu Pham
     
  • Two approaches for VGA detections: hot plug detection for 945G onwards
    and load pipe detection for Pre-945G. Load pipe detection will get one free
    pipe, set border color as red and blue, then check CRT status by
    swf register. This is a sync-up with the 2D driver.

    Signed-off-by: Ma Ling
    Signed-off-by: Eric Anholt

    Ma Ling
     
  • Slightly modified by trenn@suse.de -> only do this on fam 10h and fam 11h.

    Currently powernow-k8 determines CPU frequency from ACPI PSS objects, but
    according to AMD family 11h BKDG this frequency is just a rounded value:

    "CoreFreq (MHz) = The CPU COF specified by MSRC001_00[6B:64][CpuFid]
    rounded to the nearest 100 Mhz."

    As a consequnce powernow-k8 reports wrong CPU frequency on some systems,
    e.g. on Turion X2 Ultra:

    powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82
    processors (2 cpu cores) (version 2.20.00)
    powernow-k8: 0 : pstate 0 (2200 MHz)
    powernow-k8: 1 : pstate 1 (1100 MHz)
    powernow-k8: 2 : pstate 2 (600 MHz)

    But this is wrong as frequency for Pstate2 is 550 MHz. x86info reports it
    correctly:

    #x86info -a |grep Pstate
    ...
    Pstate-0: fid=e, did=0, vid=24 (2200MHz)
    Pstate-1: fid=e, did=1, vid=30 (1100MHz)
    Pstate-2: fid=e, did=2, vid=3c (550MHz) (current)

    Solution is to determine the frequency directly from Pstate MSRs instead
    of using rounded values from ACPI table.

    Signed-off-by: Andreas Herrmann
    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Andreas Herrmann
     
  • - Make the message shorter and easier to grep for
    - Use printk_once instead of WARN_ONCE (functionality of these was mixed)

    Signed-off-by: Thomas Renninger
    Cc: Langsdorf, Mark
    Signed-off-by: Dave Jones

    Thomas Renninger
     
  • * Rafael J. Wysocki (rjw@sisk.pl) wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.28 and 2.6.29.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.28 and 2.6.29. Please verify if it still should
    > be listed and let me know (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
    > Subject : cpufreq timer teardown problem
    > Submitter : Mathieu Desnoyers
    > Date : 2009-04-23 14:00 (24 days old)
    > References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
    > Handled-By : Mathieu Desnoyers
    > Patch : http://patchwork.kernel.org/patch/19754/
    > http://patchwork.kernel.org/patch/19753/
    >

    (updated changelog)

    cpufreq fix timer teardown in ondemand governor

    The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
    use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
    workqueue handler to exit.

    The ondemand governor does not seem to be affected because the
    "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
    immediately without rescheduling the work. The conservative governor in
    2.6.30-rc has the same check as the ondemand governor, which makes things
    usually run smoothly. However, if the governor is quickly stopped and then
    started, this could lead to the following race :

    dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
    This is why a synchronized teardown is required.

    The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.

    Depends on patch
    cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

    Signed-off-by: Mathieu Desnoyers
    CC: Andrew Morton
    CC: gregkh@suse.de
    CC: stable@kernel.org
    CC: cpufreq@vger.kernel.org
    CC: Ingo Molnar
    CC: rjw@sisk.pl
    CC: Ben Slusky
    Signed-off-by: Dave Jones

    Mathieu Desnoyers
     
  • * Rafael J. Wysocki (rjw@sisk.pl) wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.28 and 2.6.29.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.28 and 2.6.29. Please verify if it still should
    > be listed and let me know (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
    > Subject : cpufreq timer teardown problem
    > Submitter : Mathieu Desnoyers
    > Date : 2009-04-23 14:00 (24 days old)
    > References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
    > Handled-By : Mathieu Desnoyers
    > Patch : http://patchwork.kernel.org/patch/19754/
    > http://patchwork.kernel.org/patch/19753/
    >

    (re-send with updated changelog)

    cpufreq fix timer teardown in conservative governor

    The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
    use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
    workqueue handler to exit.

    The ondemand governor does not seem to be affected because the
    "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
    immediately without rescheduling the work. The conservative governor in
    2.6.30-rc has the same check as the ondemand governor, which makes things
    usually run smoothly. However, if the governor is quickly stopped and then
    started, this could lead to the following race :

    dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
    This is why a synchronized teardown is required.

    Depends on patch
    cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

    The following patch applies to 2.6.30-rc2. Stable kernels have a similar
    issue which should also be fixed, but the code changed between 2.6.29
    and 2.6.30, so this patch only applies to 2.6.30-rc.

    Signed-off-by: Mathieu Desnoyers
    CC: Andrew Morton
    CC: gregkh@suse.de
    CC: stable@kernel.org
    CC: cpufreq@vger.kernel.org
    CC: Ingo Molnar
    CC: rjw@sisk.pl
    CC: Ben Slusky
    Signed-off-by: Dave Jones

    Mathieu Desnoyers
     
  • * Rafael J. Wysocki (rjw@sisk.pl) wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.28 and 2.6.29.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.28 and 2.6.29. Please verify if it still should
    > be listed and let me know (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
    > Subject : cpufreq timer teardown problem
    > Submitter : Mathieu Desnoyers
    > Date : 2009-04-23 14:00 (24 days old)
    > References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
    > Handled-By : Mathieu Desnoyers
    > Patch : http://patchwork.kernel.org/patch/19754/
    > http://patchwork.kernel.org/patch/19753/

    The patches linked above depend on the following patch to remove
    circular locking dependency :

    cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

    (the following issue was faced when using cancel_delayed_work_sync() in the
    timer teardown (which fixes a race).

    * KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
    > Hi
    >
    > my box output following warnings.
    > it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
    >
    > A: work -> do_dbs_timer() -> cpu_policy_rwsem
    > B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
    >
    >

    Hrm, I think it must be due to my attempt to fix the timer teardown race
    in ondemand governor mixed with new locking behavior in 2.6.30-rc.

    The rwlock seems to be taken around the whole call to
    cpufreq_governor_dbs(), when it should be only taken around accesses to
    the locked data, and especially *not* around the call to
    dbs_timer_exit().

    Reverting my fix attempt would put the teardown race back in place
    (replacing the cancel_delayed_work_sync by cancel_delayed_work).
    Instead, a proper fix would imply modifying this critical section :

    cpufreq.c: __cpufreq_remove_dev()
    ...
    if (cpufreq_driver->target)
    __cpufreq_governor(data, CPUFREQ_GOV_STOP);

    unlock_policy_rwsem_write(cpu);

    To make sure the __cpufreq_governor() callback is not called with rwsem
    held. This would allow execution of cancel_delayed_work_sync() without
    being nested within the rwsem.

    Applies on top of the 2.6.30-rc5 tree.

    Required to remove circular dep in teardown of both conservative and
    ondemande governors so they can use cancel_delayed_work_sync().
    CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
    unneeded.

    Signed-off-by: Mathieu Desnoyers
    CC: KOSAKI Motohiro
    Cc: Greg KH
    CC: Ingo Molnar
    CC: "Rafael J. Wysocki"
    CC: Ben Slusky
    CC: Chris Wright
    CC: Andrew Morton
    Signed-off-by: Dave Jones

    Mathieu Desnoyers
     
  • arch/x86/kernel/cpu/cpufreq/powernow-k7.c:172: warning: 'invalidate_entry' defined but not used

    Reported-by: Toralf Förster
    Signed-off-by: Dave Jones

    Dave Jones
     
  • Some atom procs don't do freq scaling (such as the atom 330 on my own
    littlefalls2 board). By adding the atom family here, we at least get
    the benefit of passive cooling in a thermal emergency. Not sure how
    to see that its actually helping any, but the driver does bind and
    claim its functioning on my atom 330.

    Signed-off-by: Jarod Wilson
    Signed-off-by: Dave Jones

    Jarod Wilson
     

26 May, 2009

16 commits

  • David S. Miller
     
  • The 8169 chip only generates MSI interrupts when all enabled event
    sources are quiescent and one or more sources transition to active. If
    not all of the active events are acknowledged, or a new event becomes
    active while the existing ones are cleared in the handler, we will not
    see a new interrupt.

    The current interrupt handler masks off the Rx and Tx events once the
    NAPI handler has been scheduled, which opens a race window in which we
    can get another Rx or Tx event and never ACK'ing it, stopping all
    activity until the link is reset (ifconfig down/up). Fix this by always
    ACK'ing all event sources, and loop in the handler until we have all
    sources quiescent.

    Signed-off-by: David Dillow
    Tested-by: Michael Buesch
    Signed-off-by: David S. Miller

    David Dillow
     
  • For relocatable 32bit kernels, boot/compressed/relocs.c processes
    relocation entries in the kernel image and appends it to the kernel
    image such that boot/compressed/head_32.S can relocate the kernel.
    The kernel image is one statically linked object and only uses two
    relocation types - R_386_PC32 and R_386_32, of the two only the latter
    needs massaging during kernel relocation and thus handled by relocs.
    R_386_PC32 is ignored and all other relocation types are considered
    error.

    When the target of a relocation resides in a discarded section,
    binutils doesn't throw away the relocation record but nullifies it by
    changing it to R_386_NONE, which unfortunately makes relocs fail.

    The problem was triggered by yet out-of-tree x86 stack unwind patches
    but given the binutils behavior, ignoring R_386_NONE is the right
    thing to do.

    The problem has been tracked down to binutils behavior by Jan Beulich.

    [ Impact: fix build with certain binutils by ignoring R_386_NONE ]

    Signed-off-by: Tejun Heo
    Cc: Jan Beulich
    Cc: Ingo Molnar
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Tejun Heo
     
  • This patch fixes ssthresh accounting issues in tcp_vegas when cwnd decreases

    Signed-off-by: Doug Leith
    Signed-off-by: David S. Miller

    Doug Leith
     
  • Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc ("mac8390: update
    to net_device_ops") broke mac8390 by adding 8390.o to the link. That
    meant that lib8390.c was included twice, once in mac8390.c and once in
    8390.c, subject to different macros. This patch reverts that by
    avoiding the wrappers in 8390.c. They seem to be of no value since
    COMPAT_NET_DEV_OPS is going away soon.

    Tested with a Kinetics EtherPort card.

    Signed-off-by: Finn Thain
    Signed-off-by: David S. Miller

    Finn Thain
     
  • The recent rework of the MMU PID handling for non-hash CPUs has a
    subtle bug in the !SMP "optimized" variant of the PID stealing
    function. It clears the PID in the mm context before it calls
    local_flush_tlb_mm(). However, the later will not flush anything
    if the PID in the context is clear...

    Signed-off-by: Hideo Saito
    Signed-off-by: Benjamin Herrenschmidt

    Hideo Saito
     
  • md has no need for the BKL - it does its own locking.
    So md_ioctl doesn't need to be a locked_ioctl.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • In order for the metadata to always be consistent, we mustn't updated
    curr_resync_completed without also updating reshape_position.

    The reshape code updates both at the same time. However since
    commit 97e4f42d62badb0f9fbc27c013e89bc1336a03bc
    the common md_do_sync will sometimes update curr_resync_completed
    but is not in a position to update reshape_position.
    So if MD_RECOVERY_RESHAPE is set (indicating that a reshape is
    happening, so reshape_position might change), don't update
    curr_resync_completed in md_do_sync, leave it to the per-personality
    reshape code.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • As sector_t in unsigned, we cannot afford to let 'safepos' etc go
    negative.
    So replace
    a -= b;
    by
    a -= min(b,a);

    Signed-off-by: NeilBrown

    NeilBrown
     
  • The md resync engine has a 'frozen' state which ensures that
    no resync/recovery. This is used to avoid races.

    Export this state through the 'sync_action' sysfs attribute
    so that user-space can benefit and also avoid some races.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • The code for checking which bits in the bitmap can be cleared
    has 2 problems:
    1/ it repeatedly takes and drops a spinlock, where it would make
    more sense to just hold on to it most of the time.
    2/ it doesn't make use of some opportunities to skip large sections
    of the bitmap

    This patch fixes those. It will only affect CPU consumption, not
    correctness.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • Instead of always returns EINVAL if anything goes wrong
    when setting the array size, add the option of
    E2BIG
    if the size requested is too large. This makes it easier
    for user-space to be sure what went wrong.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • We previously didn't update these fields when writing the metadata
    because they could never change. They can now, so we better write
    them.
    v0.90 metadata always updated these fields.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • * 'kvm-updates/2.6.30' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
    KVM: Fix PDPTR reloading on CR4 writes
    KVM: Make paravirt tlb flush also reload the PAE PDPTRs

    Linus Torvalds
     
  • …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: Remove remap percpu allocator for the time being
    x86: cpa_flush_array wbinvd should be done on all CPUs
    x86: bugfix wbinvd() model check instead of family check
    x86: introduce noxsave boot parameter
    x86, setup: revert ACPI 3 E820 extended attributes support
    x86: DMI match for the Sony VGN-Z540N as it needs BIOS reboot

    Linus Torvalds
     
  • The processor is documented to reload the PDPTRs while in PAE mode if any
    of the CR4 bits PSE, PGE, or PAE change. Linux relies on this
    behaviour when zapping the low mappings of PAE kernels during boot.

    The code already handled changes to CR4.PAE; augment it to also notice changes
    to PSE and PGE.

    This triggered while booting an F11 PAE kernel; the futex initialization code
    runs before any CR3 reloads and writes to a NULL pointer; the futex subsystem
    ended up uninitialized, killing PI futexes and pulseaudio which uses them.

    Cc: stable@kernel.org
    Signed-off-by: Avi Kivity

    Avi Kivity