07 Mar, 2007

17 commits

  • rcutorture's module parameters currently use permissions of 0, so they
    don't show up in /sys/module/rcutorture/parameters. Change the permissions
    on all module parameters to world-readable (0444).

    rcutorture does all of its initialization and thread startup when loaded
    and relies on the parameters not changing during execution, so they should
    not permit writing. However, reading seems fine.

    Signed-off-by: Josh Triplett
    Cc: "Paul E. McKenney"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     
  • Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • This fixes a regression caused by 22c8ca78f20724676b6006232bf06cc3e9299539.

    nobh_prepare_write() no longer marks the page uptodate, so
    nobh_truncate_page() needs to do it.

    Signed-off-by: Dave Kleikamp
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Kleikamp
     
  • I've only seen this on x86_64.

    The vsyscall state only gets updated when a timer interrupts comes in. So
    if the time is set long before the next timer, there will be a period when
    a gettimeofday() won't reflect the correct time.

    I added an explicit update_vsyscall() during the settimeofday(), that way
    the vsyscall state doesn't get stale.

    Signed-off-by: Daniel Walker
    Cc: Thomas Gleixner
    Acked-by: Ingo Molnar
    Acked-by: John Stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Walker
     
  • Fix http://bugzilla.kernel.org/show_bug.cgi?id=8130

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Zijlstra
     
  • Remove the no longer used custom_sched_clock.

    Signed-off-by: Adrian Bunk
    Acked-by: Zachary Amsden
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable
    clocksource and clock event sources are registered. The switch to high
    resolution mode happens inside of the TIMER_SOFTIRQ, but runs the softirq
    afterwards. That way the tick emulation timer, which was set up in the
    switch to highres might be executed in the softirq context, which is a BUG.
    The rbtree has not to be touched by the softirq after the highres switch.

    This BUG was observed by Andres Salomon, who provided the information to
    debug it.

    Return early from the softirq, when the switch was sucessful.

    [dilinger@debian.org: add debug warning]
    [akpm@linux-foundation.org: make debug warning compile]
    Signed-off-by: Thomas Gleixner
    Cc: Andres Salomon
    Acked-by: Ingo Molnar
    Signed-off-by: Andres Salomon
    Acked-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • The description for the hrtimer_clock_base struct describes "hrtimer_base".
    That should be hrtimer_clock_base.

    Signed-off-by: Andres Salomon
    Acked-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     
  • The description for HRTIMER_CB_IRQSAFE_NO_SOFTIRQ is backwards; "NO
    SOFTIRQ" sounds a whole lot like it means it must not be run in a softirq.

    Signed-off-by: Andres Salomon
    Acked-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     
  • Prior to commit 95492e4646e5de8b43d9a7908d6177fb737b61f0 ([PATCH] x86:
    rewrite SMP TSC sync code), the headers in asm-i386 did not really require
    anything in include/asm-x86_64. This means that distributions such as
    fedora did not include asm-x86_64 in kernel-devel headers for i386. Ingo's
    commit changed that, and broke things. This is easy enough to hack around
    in package builds by just including asm-x86_64 on i386, but that's kind of
    annoying. If anything, x86_64 should depend upon i386, not the other way
    around.

    This patch changes it so that asm-x86_64/tsc.h includes asm-i386/tsc.h,
    rather than vice-versa.

    Signed-off-by: Andres Salomon
    Acked-by: Ingo Molnar
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     
  • The obsolete SA_xxx interrupt flags have been used despite the scheduled
    removal. Fixup the remaining users.

    Signed-off-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Cc: Zachary Amsden
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • Any attempt to open/use a bluetooth rfcomm device locks up
    scheduling completely on my machine.

    Interrupts (ping, alt-sysrq) seem to be alive, but nothing else.

    This was working fine in 2.6.20, broken now in 2.6.21-rc2-git*

    Reverting this change (below) fixes it:

    | author Marcel Holtmann
    | Sat, 17 Feb 2007 22:58:57 +0000 (23:58 +0100)
    | committer David S. Miller
    | Mon, 26 Feb 2007 19:42:41 +0000 (11:42 -0800)
    | commit c1a3313698895d8ad4760f98642007bf236af2e8
    | tree 337a876f727061362b6a169f8759849c105b8f7a tree | snapshot
    | parent f5ffd4620aba9e55656483ae1ef5c79ba81f5403 commit | diff
    | | [Bluetooth] Make use of device_move() for RFCOMM TTY devices
    | | In the case of bound RFCOMM TTY devices the parent is not available
    | before its usage. So when opening a RFCOMM TTY device, move it to
    | the corresponding ACL device as a child. When closing the device,
    | move it back to the virtual device tree.
    | Signed-off-by: Marcel Holtmann

    The simplest fix for this bug is to prevent sysfs_move_dir()
    from self-deadlocking when (old_parent == new_parent).

    This patch prevents total system lockup when using rfcomm devices.

    Signed-off-by: Mark Lord
    Acked-by: Cornelia Huck
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mark Lord
     
  • Fix the following error if FB_DDC=n

    Kernel: arch/x86_64/boot/bzImage is ready (#1)
    Building modules, stage 2.
    MODPOST 229 modules
    WARNING: "fb_ddc_read" [drivers/video/nvidia/nvidiafb.ko] undefined!
    make[1]: *** [__modpost] Error 1

    Signed-off-by: Antonino Daplas
    Cc: James Simmons
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Simmons
     
  • Fix implicit declarations and missing code in atyfb.

    drivers/video/aty/atyfb_base.c:2137: warning: implicit declaration of function 'a
    ty_ld_lcd'
    drivers/video/aty/atyfb_base.c:2154: warning: implicit declaration of function 'a
    ty_st_lcd'
    atyfb_base.c:(.text+0x33e5c): undefined reference to `aty_ld_lcd'
    atyfb_base.c:(.text+0x33eb2): undefined reference to `aty_st_lcd'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Antonino Daplas
    Cc: James Simmons
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • drivers/video/nvidia/nv_backlight.c: In function 'nvidia_bl_init':
    drivers/video/nvidia/nv_backlight.c:103: error: implicit declaration of function 'pmac_has_backlight_type'

    Signed-off-by: Dave Jones
    Signed-off-by: Antonino Daplas
    Cc: James Simmons
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Jones
     
  • arch/i386/kernel/vmi.c: In function 'vmi_safe_halt':
    arch/i386/kernel/vmi.c:262: warning: implicit declaration of function 'vmi_stop_hz_timer'
    arch/i386/kernel/vmi.c:266: warning: implicit declaration of function 'vmi_account_time_restart_hz_timer'

    Acked-by: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Zachary Amsden
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • The programming of periodic tick devices needs to be saved/restored
    across suspend/resume - otherwise we might end up with a system coming
    up that relies on getting a PIT (or HPET) interrupt, while those devices
    default to 'no interrupts' after powerup. (To confuse things it worked
    to a certain degree on some systems because the lapic gets initialized
    as a side-effect of SMP bootup.)

    This suspend / resume thing was dropped unintentionally during the
    last-minute -mm code reshuffling.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

06 Mar, 2007

7 commits

  • CONFIG_PARAVIRT broke old glibc bootup: it silently turned off the
    selectability of CONFIG_COMPAT_VDSO and thus rendered distro kernels
    unbootable on old-style VDSO glibc setups.

    the proper solution is to keep COMPAT_VDSO available - if a hypervisor
    needs any modification of that concept then we'll judge those changes in
    full context, once those changes are submitted.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • * 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight:
    backlight: Allow enable/disable of fb backlights, fixing regressions
    backlight: Fix nvidia backlight initial brightness

    Linus Torvalds
     
  • there's a new NMI watchdog related problem: KVM crashes on certain
    bzImages because ... we enable the NMI watchdog by default (even if the
    user does not ask for it) , and no other OS on this planet does that so
    KVM doesnt have emulation for that yet. So KVM injects a #GP, which
    crashes the Linux guest:

    general protection fault: 0000 [#1]
    PREEMPT SMP
    Modules linked in:
    CPU: 0
    EIP: 0060:[] Not tainted VLI
    EFLAGS: 00000246 (2.6.20-rc5-rt0 #3)
    EIP is at setup_apic_nmi_watchdog+0x26d/0x3d3

    and no, i did /not/ request an nmi_watchdog on the boot command line!

    Solution: turn off that darn thing! It's a debug tool, not a 'make life
    harder' tool!!

    with this patch the KVM guest boots up just fine.

    And with this my laptop (Lenovo T60) also stopped its sporadic hard
    hanging (sometimes in acpi_init(), sometimes later during bootup,
    sometimes much later during actual use) as well. It hung with both
    nmi_watchdog=1 and nmi_watchdog=2, so it's generally the fact of NMI
    injection that is causing problems, not the NMI watchdog variant, nor
    any particular bootup code.

    [ NMI breaks on some systems, esp in combination with SMM -Arjan ]

    Signed-off-by: Ingo Molnar
    Acked-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • do not use default=y for CONFIG_VMI (we do not do that for any driver or
    special-hardware feature): the overwhelming majority of Linux users does
    not need it, and interested users and distributions can enable it
    as-needed.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • Clarify the description of the CONFIG_VMI option: describe the reality
    that VMI is a VMWare-only interface for now. Once that changes and
    another hypervisor adopts the VMI ABI we can change the text.

    As can be seen from the Xen paravirtualization patches submitted to lkml
    the Xen project has chosen its own, non-VMI interface between Xen and
    the para-Linux - so remove Xen from the description.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • Temove the mistaken turning on of NO_IDLE_HZ on x86+PARAVIRT kernels.

    It's an obsolete, limited form of dynticks.

    Signed-off-by: Ingo Molnar
    Acked-by: Thomas Gleixner
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • CT based mach64 cards were reported to hang on sparc64 boxes when
    compiled with gcc-4.1.x and later.

    Looking at this piece of code, it's no surprise. A critical
    delay was implemented as an empty for() loop, and gcc 4.0.x
    and previous did not optimize it away, so we did get a delay.

    But gcc-4.1.x and later can optimize it away, and we get crashes.

    Use a real udelay() to fix this. Fix verified on SunBlade100.

    Signed-off-by: David S. Miller
    Signed-off-by: Linus Torvalds

    David Miller
     

05 Mar, 2007

16 commits

  • CC arch/i386/kernel/vmi.o
    /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c: In function 'vmi_map_pt_hook':
    /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: 'KM_PTE0' undeclared (first use in this function)
    /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: (Each undeclared identifier is reported only once
    /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: for each function it appears in.)
    /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: 'KM_PTE1' undeclared (first use in this function)
    make[2]: *** [arch/i386/kernel/vmi.o] Error 1

    Signed-off-by: Adrian Bunk
    Acked-by: Zachary Amsden
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • Replacing use of UTS_RELEASE with utsname()->release avoids that the
    usb-storage driver is recompiled each time the kernel version changes.

    Signed-off-by: Sam Ravnborg
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sam Ravnborg
     
  • Add some documentation for the new and very useful io-accounting feature.
    It's being added to Documentation/filesystems/proc.txt

    Signed-off-by: Roland Kletzing
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roland Kletzing
     
  • Fix the following compile error:

    MODPOST 327 modules
    WARNING: "aty_st_lcd" [drivers/video/aty/atyfb.ko] undefined!
    WARNING: "aty_ld_lcd" [drivers/video/aty/atyfb.ko] undefined!
    make[1]: *** [__modpost] Error 1
    make: *** [modules] Error 2

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     
  • "drivers/char/epca.c:2741: warning: 'get_termio' defined but not used"

    Signed-off-by: Michal Piotrowski
    Acked-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Piotrowski
     
  • Doing something like this on a two cpu system

    # echo 0 > /sys/devices/system/cpu/cpu0/online
    # echo 1 > /sys/devices/system/cpu/cpu0/online
    # echo 0 > /sys/devices/system/cpu/cpu1/online

    will give me this:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.21-rc2-g562aa1d4-dirty #7
    -------------------------------------------------------
    bash/1282 is trying to acquire lock:
    (&cpu_base->lock_key){.+..}, at: [] hrtimer_cpu_notify+0xc6/0x240

    but task is already holding lock:
    (&cpu_base->lock_key#2){.+..}, at: [] hrtimer_cpu_notify+0xbc/0x240

    which lock already depends on the new lock.

    This happens because we have the following code in kernel/hrtimer.c:

    migrate_hrtimers(int cpu)
    [...]
    old_base = &per_cpu(hrtimer_bases, cpu);
    new_base = &get_cpu_var(hrtimer_bases);
    [...]
    spin_lock(&new_base->lock);
    spin_lock(&old_base->lock);

    Which means the spinlocks are taken in an order which depends on which cpu
    gets shut down from which other cpu. Therefore lockdep complains that there
    might be an ABBA deadlock. Since migrate_hrtimers() gets only called on
    cpu hotplug it's safe to assume that it isn't executed concurrently on a

    The same problem exists in kernel/timer.c: migrate_timers().

    As pointed out by Christian Borntraeger one possible solution to avoid
    the locking order complaints would be to make sure that the locks are
    always taken in the same order. E.g. by taking the lock of the cpu with
    the lower number first.

    To achieve this we introduce two new spinlock functions double_spin_lock
    and double_spin_unlock which lock or unlock two locks in a given order.

    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Roman Zippel
    Cc: John Stultz
    Cc: Christian Borntraeger
    Cc: Martin Schwidefsky
    Signed-off-by: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     
  • This patch resolves the issue found here:
    http://bugme.osdl.org/show_bug.cgi?id=7426

    The basic summary is:
    Currently we register most of i386/x86_64 clocksources at module_init
    time. Then we enable clocksource selection at late_initcall time. This
    causes some problems for drivers that use gettimeofday for init
    calibration routines (specifically the es1968 driver in this case),
    where durring module_init, the only clocksource available is the low-res
    jiffies clocksource. This may cause slight calibration errors, due to
    the small sampling time used.

    It should be noted that drivers that require fine grained time may not
    function on architectures that do not have better then jiffies
    resolution timekeeping (there are a few). However, this does not
    discount the reasonable need for such fine-grained timekeeping at init
    time.

    Thus the solution here is to register clocksources earlier (ideally when
    the hardware is being initialized), and then we enable clocksource
    selection at fs_initcall (before device_initcall).

    This patch should probably get some testing time in -mm, since
    clocksource selection is one of the most important issues for correct
    timekeeping, and I've only been able to test this on a few of my own
    boxes.

    Signed-off-by: John Stultz
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    john stultz
     
  • Removes unused 'flags' variable from setup_IO_APIC_irq().

    Signed-off-by: David Rientjes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     
  • ipmi_si_intf tries to access default ports, if no device could be found
    elsewhere. On PPC we have a function to check, if these legacy IO ports
    are accessible. This patch adds a check for these ports on PPC. This
    patch fixes a breakage of IPMI module on PPC machines without a BMC.

    Signed-off-by: Christian Krafft
    Acked-by: Michael Ellerman
    Signed-off-by: Corey Minyard
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christian Krafft
     
  • - In fact we don't have to fail if AOP_TRUNCATED_PAGE was returned from
    prepare_write or commit_write. It is beter to retry attempt where it
    is possible.

    - Rearange ecryptfs_get_lower_page() error handling logic, make it more clean.

    Signed-off-by: Dmitriy Monakhov
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitriy Monakhov
     
  • - Currently after path_lookup succeed we dot't have any guarantie what
    it is DIR. This must be explicitly demanded.
    - path_lookup can't return negative dentry, So inode check is useless.

    Signed-off-by: Dmitriy Monakhov
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitriy Monakhov
     
  • Testing NMI watchdog ... CPU#0: NMI appears to be stuck (54->54)!
    CPU#1: NMI appears to be stuck (0->0)!

    Keep the PIT/HPET alive when nmi_watchdog = 1 is given on the command
    line.

    Signed-off-by: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • Recent patch for raid6 reshape had a change missing that showed up in
    subsequent review.

    Many places in the raid5 code used "conf->raid_disks-1" to mean "number of
    data disks". With raid6 that had to be changed to "conf->raid_disk -
    conf->max_degraded" or similar. One place was missed.

    This bug means that if a raid6 reshape were aborted in the middle the
    recorded position would be wrong. On restart it would either fail (as the
    position wasn't on an appropriate boundary) or would leave a section of the
    array unreshaped, causing data corruption.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     
  • Critical fixes for SMP.

    Fix a couple functions which needed to be __devinit and fix a bogus parameter
    to AP startup that just so happened to work because the low virtual mapping of
    memory was still established.

    Signed-off-by: Zachary Amsden
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     
  • Use para_fill instead of directly setting the APIC ops to the result of the
    vmi_get_function call - this allows one to implement a VMI ROM without
    implementing APIC functions, just using the native APIC functions.

    While doing this, I realized that there is a lot more cleanup that should have
    been done. Basically, we should never assume that the ROM implements a
    specific set of functions, and always allow fallback to the native
    implementation.

    This is critical for future compatibility.

    Signed-off-by: Anthony Liguori
    Signed-off-by: Zachary Amsden

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     
  • More goo from hrtimers integration. We do compile and run properly with NO_HZ
    enabled. There was a period when we didn't because of a missing export, but
    that was since fixed.

    And with the clocksource code now firmly in place, we can get rid of code that
    fixes up the wallclock, since this is done in the common infrastructure. This
    actually fixes a timer bug as well, that was caused by do_settimeofday no
    longer being callable with interrupts disabled due to the use of
    on_each_cpu().

    Signed-off-by: Zachary Amsden
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden