11 Apr, 2008

5 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
    [SPARC]: Fix several regset and ptrace bugs.

    Linus Torvalds
     
  • The prevent_tail_call() macro works around the problem of the compiler
    clobbering argument words on the stack, which for asmlinkage functions
    is the caller's (user's) struct pt_regs. The tail/sibling-call
    optimization is not the only way that the compiler can decide to use
    stack argument words as scratch space, which we have to prevent.
    Other optimizations can do it too.

    Until we have new compiler support to make "asmlinkage" binding on the
    compiler's own use of the stack argument frame, we have work around all
    the manifestations of this issue that crop up.

    More cases seem to be prevented by also keeping the incoming argument
    variables live at the end of the function. This makes their original
    stack slots attractive places to leave those variables, so the compiler
    tends not clobber them for something else. It's still no guarantee, but
    it handles some observed cases that prevent_tail_call() did not.

    Signed-off-by: Roland McGrath
    Signed-off-by: Linus Torvalds

    Roland McGrath
     
  • This patch also resolves hangs on boot:
    http://lkml.org/lkml/2008/2/23/263
    http://bugzilla.kernel.org/show_bug.cgi?id=10093

    The bug was causing once-in-few-reboots 10-15 sec wait during boot on
    certain laptops.

    Earlier commit 40d6a146629b98d8e322b6f9332b182c7cbff3df added
    smp_call_function in cpu_idle_wait() to kick cpus that are in tickless
    idle. Looking at cpu_idle_wait code at that time, code seemed to be
    over-engineered for a case which is rarely used (while changing idle
    handler).

    Below is a simplified version of cpu_idle_wait, which just makes a dummy
    smp_call_function to all cpus, to make them come out of old idle handler
    and start using the new idle handler. It eliminates code in the idle
    loop to handle cpu_idle_wait.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Linus Torvalds

    Venki Pallipadi
     
  • Make NOMMU-mode work with base addresses other than 0xC0000000 by:

    (1) Giving the code that sets up the protection registers the right address
    in __sdram_base. Rather than being hard coded to 0xC0000000, the value
    of __page_offset is obtained from the linker script.

    (2) Eliminate the check in __switch_to() that verifies the current thread
    info is in the 0xCxxxxxxx region.

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

    David Howells
     
  • Use traps 120-126 to emulate atomic cmpxchg32, xchg32, and XOR-, OR-, AND-, SUB-
    and ADD-to-memory operations for userspace.

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

    David Howells
     

10 Apr, 2008

2 commits

  • 1) ptrace should pass 'current' to task_user_regset_view()

    2) When fetching general registers using a 64-bit view, and
    the target is 32-bit, we have to convert.

    3) Skip the whole register window get/set code block if
    the user isn't asking to access anything in there.

    Otherwise we have problems if the user doesn't have
    an address space setup. Fetching ptrace register is
    still valid at such a time, and ptrace does not try
    to access the register window area of the regset.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • gcc expects all toplevel assembly to return to the original section type.
    The code in alteranative.c does not do this. This caused some strange bugs
    in sched-devel where code would end up in the .rodata section and when
    the kernel sets the NX bit on all .rodata, the kernel would crash when
    executing this code.

    This patch adds a .previous marker to return the code back to the
    original section.

    Credit goes to Andrew Pinski for telling me it wasn't a gcc bug but a
    bug in the toplevel asm code in the kernel. ;-)

    Signed-off-by: Steven Rostedt
    Signed-off-by: Linus Torvalds

    Steven Rostedt
     

08 Apr, 2008

3 commits

  • flush_cache_vmap / flush_cache_vunmap were calling flush_cache_all which -
    having been deprecated - turned into a nop ...

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • In time_cpufreq_notifier() the cpu id to act upon is held in freq->cpu. Use it
    instead of smp_processor_id() in the call to set_cyc2ns_scale().
    This makes the preempt_*able() unnecessary and lets set_cyc2ns_scale() update
    the intended cpu's cyc2ns.

    Related mail/thread: http://lkml.org/lkml/2007/12/7/130

    Signed-off-by: Karsten Wiese
    Signed-off-by: Ingo Molnar

    Karsten Wiese
     
  • revert:

    | commit 47001d603375f857a7fab0e9c095d964a1ea0039
    | Author: Thomas Gleixner
    | Date: Tue Apr 1 19:45:18 2008 +0200
    |
    | x86: tsc prevent time going backwards

    it has been identified to cause suspend regression - and the
    commit fixes a longstanding bug that existed before 2.6.25 was
    opened - so it can wait some more until the effects are better
    understood.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

07 Apr, 2008

2 commits


05 Apr, 2008

13 commits

  • * 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/ralf/upstream-linus:
    [MIPS] Make KGDB compile on UP
    [MIPS] Pb1200: Fix header breakage

    Linus Torvalds
     
  • Building UP kernel with KGDB enabled produces the following errors and warning
    (fatal due to -Werror in arch/mips/kernel/Makefile):

    In file included from arch/mips/kernel/gdb-stub.c:142:
    include/asm/smp.h:25:1: "raw_smp_processor_id" redefined
    In file included from include/linux/sched.h:69,
    from arch/mips/kernel/gdb-stub.c:126:
    include/linux/smp.h:88:1: this is the location of the previous definition
    In file included from arch/mips/kernel/gdb-stub.c:142:
    include/asm/smp.h:62: error: redefinition of 'smp_send_reschedule'
    include/linux/smp.h:102: error: previous definition of 'smp_send_reschedule' was here
    include/asm/smp.h: In function `smp_send_reschedule':
    include/asm/smp.h:65: error: dereferencing pointer to incomplete type
    arch/mips/kernel/gdb-stub.c: At top level:
    arch/mips/kernel/gdb-stub.c:660: warning: 'kgdb_wait' defined but not used

    Fix the errors by not directly including (which is already included
    by ) and the warning by enclosing kgdb_wait() in #ifdef CONFIG_SMP.

    Signed-off-by: Sergei Shtylyov
    Signed-off-by: Ralf Baechle

    Sergei Shtylyov
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
    x86: revert assign IRQs to hpet timer
    x86: tsc prevent time going backwards
    xen: Clear PG_pinned in release_{pt,pd}()
    xen: Do not pin/unpin PMD pages
    xen: refactor xen_{alloc,release}_{pt,pd}()
    x86, agpgart: scary messages are fortunately obsolete
    xen: fix grant table bug
    x86: fix breakage of vSMP irq operations
    x86: print message if nmi_watchdog=2 cannot be enabled
    x86: fix nmi_watchdog=2 on Pentium-D CPUs

    Linus Torvalds
     
  • Long overdue update of the m68k defconfigs

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     
  • The default defconfig should be one from arch/m68k/configs/

    arch/m68k/defconfig was not exactly identical to amiga_defconfig but
    also considering how long they have been without any update that doesn't
    seem to have been on purpose.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • The commits:

    commit 37a47db8d7f0f38dac5acf5a13abbc8f401707fa
    Author: Balaji Rao
    Date: Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers, fix

    and

    commit e3f37a54f690d3e64995ea7ecea08c5ab3070faf
    Author: Balaji Rao
    Date: Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers

    have been identified to cause a regression on some platforms due to
    the assignement of legacy IRQs which makes the legacy devices
    connected to those IRQs disfunctional.

    Revert them.

    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382

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

    Thomas Gleixner
     
  • We already catch most of the TSC problems by sanity checks, but there
    is a subtle bug which has been in the code for ever. This can cause
    time jumps in the range of hours.

    This was reported in:
    http://lkml.org/lkml/2007/8/23/96
    and
    http://lkml.org/lkml/2008/3/31/23

    I was able to reproduce the problem with a gettimeofday loop test on a
    dual core and a quad core machine which both have sychronized
    TSCs. The TSCs seems not to be perfectly in sync though, but the
    kernel is not able to detect the slight delta in the sync check. Still
    there exists an extremly small window where this delta can be observed
    with a real big time jump. So far I was only able to reproduce this
    with the vsyscall gettimeofday implementation, but in theory this
    might be observable with the syscall based version as well.

    CPU 0 updates the clock source variables under xtime/vyscall lock and
    CPU1, where the TSC is slighty behind CPU0, is reading the time right
    after the seqlock was unlocked.

    The clocksource reference data was updated with the TSC from CPU0 and
    the value which is read from TSC on CPU1 is less than the reference
    data. This results in a huge delta value due to the unsigned
    subtraction of the TSC value and the reference value. This algorithm
    can not be changed due to the support of wrapping clock sources like
    pm timer.

    The huge delta is converted to nanoseconds and added to xtime, which
    is then observable by the caller. The next gettimeofday call on CPU1
    will show the correct time again as now the TSC has advanced above the
    reference value.

    To prevent this TSC specific wreckage we need to compare the TSC value
    against the reference value and return the latter when it is larger
    than the actual TSC value.

    I pondered to mark the TSC unstable when the readout is smaller than
    the reference value, but this would render an otherwise good and fast
    clocksource unusable without a real good reason.

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

    Thomas Gleixner
     
  • Signed-off-by: Mark McLoughlin
    Cc: xen-devel@lists.xensource.com
    Cc: Mark McLoughlin
    Cc: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Mark McLoughlin
     
  • i.e. with this simple test case:

    int fd = open("/dev/zero", O_RDONLY);
    munmap(mmap((void *)0x40000000, 0x1000_LEN, PROT_READ, MAP_PRIVATE, fd, 0), 0x1000);
    close(fd);

    we currently get:

    kernel BUG at arch/x86/xen/enlighten.c:678!
    ...
    EIP is at xen_release_pt+0x79/0xa9
    ...
    Call Trace:
    [] ? __pmd_free_tlb+0x1a/0x75
    [] ? free_pgd_range+0x1d2/0x2b5
    [] ? free_pgtables+0x7e/0x93
    [] ? unmap_region+0xb9/0xf5
    [] ? do_munmap+0x193/0x1f5
    [] ? sys_munmap+0x30/0x3f
    [] ? syscall_call+0x7/0xb
    =======================

    and xen complains:

    (XEN) mm.c:2241:d4 Mfn 1cc37 not pinned

    Further details at:

    https://bugzilla.redhat.com/436453

    Signed-off-by: Mark McLoughlin
    Cc: xen-devel@lists.xensource.com
    Cc: Mark McLoughlin
    Cc: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Mark McLoughlin
     
  • Signed-off-by: Mark McLoughlin
    Cc: xen-devel@lists.xensource.com
    Cc: Mark McLoughlin
    Cc: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Mark McLoughlin
     
  • Fix obsolete printks in aperture-64. We used not to handle missing
    agpgart, but we handle it okay now.

    Signed-off-by: Pavel Machek
    Signed-off-by: Ingo Molnar

    Pavel Machek
     
  • right now if there's no CPU support for nmi_watchdog=2 we'll just
    refuse it silently.

    print a useful warning.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • implement nmi_watchdog=2 on this class of CPUs:

    cpu family : 15
    model : 6
    model name : Intel(R) Pentium(R) D CPU 3.00GHz

    the watchdog's ->setup() method is safe anyway, so if the CPU
    cannot support it we'll bail out safely.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

04 Apr, 2008

4 commits

  • If target is not current we need to use access_process_vm().

    Noticed by Roland McGrath.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • This avoids using wrmsr on MSR_IA32_DEBUGCTLMSR when it's not needed.
    No wrmsr ever needs to be done if noone has ever used block stepping.

    Without this change, using ptrace on 2.6.25 on an x86 KVM guest
    will tickle KVM's missing support for the MSR and crash the guest
    kernel. Though host KVM is the buggy one, this makes for a regression
    in the guest behavior from 2.6.24->2.6.25 that we can easily avoid.

    I also corrected some bad whitespace.

    Signed-off-by: Roland McGrath
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Linus Torvalds

    Roland McGrath
     
  • * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
    [POWERPC] Fix MPC5200 (not B!) device tree so FEC ethernet works
    [POWERPC] mpc5200: Amalgamated DTS fixes and updates
    [POWERPC] Fix rtas_flash procfs interface
    [POWERPC] Fix deadlock with mmu_hash_lock in hash_page_sync
    [POWERPC] Fix iSeries hard irq enabling regression
    [POWERPC] Fix CPM2 SCC1 clock initialization.
    [POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
    [POWERPC] fsldma: Use compatiable binding as spec
    [POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata
    [POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
    [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts

    Linus Torvalds
     
  • The calculation of the FPU reg save area pointer
    was wrong.

    Based upon an OOPS report from Tom Callaway.

    Signed-off-by: David S. Miller

    David S. Miller
     

03 Apr, 2008

8 commits

  • This gets the FEC ethernet driver working again on the lite5200
    platform.

    The FEC driver is also compatible with the MPC5200, not only with the
    MPC5200B, so this adds a suitable entry to the driver's match list.
    Furthermore this adds the settings for the PHY in the dts file for the
    Lite5200. Note, that this is not exactly the same as in the
    Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
    at :00 for the 5200B. This was tested on a Lite5200 and a Lite5200B,
    both booted a kernel via tftp and mounted the root via nfs
    successfully.

    Signed-off-by: René Bürgel
    Acked-by: Grant Likely
    Signed-off-by: Paul Mackerras

    René Bürgel
     
  • DTS updates that fix booting problems on mpc5200-based boards:
    - change to ethernet reg property
    - addition of mdio and phy nodes
    - removal of pci node (Motion-Pro board)

    Other DTS updates:
    - update i2c device tree nodes
    - add lpb bus node and flash device (without partitions defined)
    - add rtc i2c nodes

    Signed-off-by: Marian Balakowicz
    Acked-by: Grant Likely
    Signed-off-by: Paul Mackerras

    Bartlomiej Sieka
     
  • Handling of the proc_dir_entry->count was changed in 2.6.24-rc5.
    After this change, the default value for pde->count is 1 and not 0 as
    before. Therefore, if we want to check whether our procfs file is
    already opened (already in use), we have to check if pde->count is
    greater than 2 rather than 1.

    Signed-off-by: Maxim Shchetynin
    Signed-off-by: Jens Osterkamp
    Signed-off-by: Paul Mackerras

    Maxim Shchetynin
     
  • hash_page_sync() takes and releases the low level mmu hash
    lock in order to sync with other processors disposing of page
    tables. Because that lock can be needed to service hash misses
    triggered by interrupt handlers, taking it must be done with
    interrupts off. However, hash_page_sync() appears to be called
    with interrupts enabled, thus causing occasional deadlocks.

    We fix it by making sure hash_page_sync() masks interrupts while
    holding the lock.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Paul Mackerras

    Benjamin Herrenschmidt
     
  • A subtle bug sneaked into iSeries recently. On this platform, we must
    not normally clear MSR:EE (the hardware external interrupt enable)
    except for short periods of time. Taking an interrupt while
    soft-disabled doesn't cause us to clear it for example.

    The iSeries kernel expects to mostly run with MSR:EE enabled at all
    times except in a few exception entry/exit code paths. Thus
    local_irq_enable() doesn't check if it needs to hard-enable as it
    expects this to be unnecessary on iSeries.

    However, hard_irq_disable() _does_ cause MSR:EE to be cleared,
    including on iSeries. A call to it was recently added to the
    context switch code, thus causing interrupts to become disabled
    for a long periods of time, causing the iSeries watchdog to kick
    in under some circumstances and other nasty things.

    This patch fixes it by making local_irq_enable() properly re-enable
    MSR:EE on iSeries. It basically removes a return statement here
    to make iSeries use the same code path as everybody else. That does
    mean that we might occasionally get spurious decrementer interrupts
    but I don't think that matters.

    Another option would have been to make hard_irq_disable() a nop
    on iSeries but I didn't like it much, in case we have good reasons
    to hard-disable.

    Part of the patch is fixes to make sure the hard_enabled PACA field
    is properly set on iSeries as it used not to be before, since it
    was mostly unused.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Paul Mackerras

    Benjamin Herrenschmidt
     
  • A missing break statement in a switch caused cpm2_clk_setup() to initialize
    SCC2 instead of SCC1.

    Signed-off-by: Laurent Pinchart
    Signed-off-by: Kumar Gala

    Laurent Pinchart
     
  • Fix the problem that makedumpfile sometimes fails on x86_64 machine.

    This patch adds the symbol "phys_base" to a vmcoreinfo data. The
    vmcoreinfo data has the minimum debugging information only for dump
    filtering. makedumpfile (dump filtering command) gets it to distinguish
    unnecessary pages, and makedumpfile creates a small dumpfile.

    On x86_64 kernel which compiled with CONFIG_PHYSICAL_START=0x0 and
    CONFIG_RELOCATABLE=y, makedumpfile fails like the following:

    # makedumpfile -d31 /proc/vmcore dumpfile
    The kernel version is not supported.
    The created dumpfile may be incomplete.
    _exclude_free_page: Can't get next online node.

    makedumpfile Failed.
    #

    The cause is the lack of the symbol "phys_base" in a vmcoreinfo data.
    If the symbol "phys_base" does not exist, makedumpfile considers an
    x86_64 kernel as non relocatable. As the result, makedumpfile
    misunderstands the physical address where the kernel is loaded, and it
    cannot translate a kernel virtual address to physical address correctly.

    To fix this problem, this patch adds the symbol "phys_base" to a
    vmcoreinfo data.

    Signed-off-by: Ken'ichi Ohmichi
    Cc: "Eric W. Biederman"
    Cc:
    Acked-by: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ken'ichi Ohmichi
     
  • Make dma_alloc_coherent respect gfp flags (__GFP_COMP is one that
    matters).

    Signed-off-by: Ivan Kokshaysky
    Tested-by: Michael Cree
    Cc: Richard Henderson
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ivan Kokshaysky
     

02 Apr, 2008

3 commits