1. 24 Jan, 2008 1 commit
    • Eric W. Biederman's avatar
      sysctl: kill binary sysctl KERN_PPC_L2CR · c2f3dabe
      Eric W. Biederman authored
      
      
      : Stefan Roese <sr@denx.de> said:
      > ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
      >
      > I'm seeing this error message when booting an recent arch/ppc kernel on
      > 4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
      > rootfs still works fine, but this message kind of makes me "nervous".
      > This is not seen on 4xx arch/powerpc platforms. Here the bootlog:
      
      Because the data field was never filled and a binary sysctl handler was
      never written this sysctl has never been usable through the sys_sysctl
      interface.  So just remove the binary sysctl number.  Making the kernel
      sanity checks happy.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Reported-by: default avatarStefan Roese <sr@denx.de>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c2f3dabe
  2. 23 Jan, 2008 2 commits
  3. 22 Jan, 2008 4 commits
  4. 21 Jan, 2008 4 commits
    • Sam Ravnborg's avatar
      [SPARC64]: Fix of section mismatch warnings. · a1f35ba3
      Sam Ravnborg authored
      
      
      Fix following Section mismatch warning in sparc64:
      
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x13dec): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'psycho_scan_bus' and 'psycho_pbm_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x14b58): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'sabre_scan_bus' and 'sabre_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x15ea4): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'schizo_scan_bus' and 'schizo_pbm_init')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x17780): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'pci_sun4v_scan_bus' and 'pci_sun4v_get_head')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x17d5c): Section mismatch: reference to .devinit.text:pci_scan_one_pbm (between 'pci_fire_scan_bus' and 'pci_fire_get_head')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x23860): Section mismatch: reference to .devinit.text:vio_dev_release (between 'vio_create_one' and 'vio_add')
      WARNING: arch/sparc64/kernel/built-in.o(.text+0x23868): Section mismatch: reference to .devinit.text:vio_dev_release (between 'vio_create_one' and 'vio_add')
      
      The pci_* were all missing __init annotations.
      For the vio.c case it was a function with a wrong annotation which was removed.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1f35ba3
    • Cyrill Gorcunov's avatar
      CRIS: add missed local_irq_restore call · a56d00bb
      Cyrill Gorcunov authored
      
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@akpm@linux-foundation.org>
      a56d00bb
    • Atsushi Nemoto's avatar
      tc35815: Use irq number for tc35815-mac platform device id · 06675e6f
      Atsushi Nemoto authored
      
      
      The tc35815-mac platform device used a pci bus number and a devfn to
      identify its target device, but the pci bus number may vary if some
      bus-bridges are found.  Use irq number which is be unique for embedded
      controllers.
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      06675e6f
    • Dmitri Vorobiev's avatar
      [MIPS] Malta: Fix reading the PCI clock frequency on big-endian · 0487de91
      Dmitri Vorobiev authored
      
      
      The JMPRS register on Malta boards keeps a 32-bit CPU-endian
      value. The readw() function assumes that the value it reads is a
      little-endian 16-bit number. Therefore, using readw() to obtain
      the value of the JMPRS register is a mistake. This error leads
      to incorrect reading of the PCI clock frequency on big-endian
      during board start-up.
      
      Change readw() to __raw_readl().
      
      This was tested by injecting a call to printk() and verifying
      that the value of the jmpr variable was consistent with current
      setting of the JP4 "PCI CLK" jumper.
      Signed-off-by: default avatarDmitri Vorobiev <dmitri.vorobiev@gmail.com>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      0487de91
  5. 20 Jan, 2008 2 commits
  6. 19 Jan, 2008 1 commit
  7. 18 Jan, 2008 3 commits
  8. 17 Jan, 2008 3 commits
  9. 16 Jan, 2008 1 commit
    • Peter Zijlstra's avatar
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra authored
      
      On Sat, 2007-12-29 at 18:06 +0100, Marcin Slusarz wrote:
      > Hi
      > Today I've got this (while i was upgrading my gentoo box):
      >
      > WARNING: at kernel/lockdep.c:2658 check_flags()
      > Pid: 21680, comm: conftest Not tainted 2.6.24-rc6 #63
      >
      > Call Trace:
      >  [<ffffffff80253457>] check_flags+0x1c7/0x1d0
      >  [<ffffffff80257217>] lock_acquire+0x57/0xc0
      >  [<ffffffff8024d5c0>] __atomic_notifier_call_chain+0x60/0xd0
      >  [<ffffffff8024d641>] atomic_notifier_call_chain+0x11/0x20
      >  [<ffffffff8024d67e>] notify_die+0x2e/0x30
      >  [<ffffffff8020da0a>] do_divide_error+0x5a/0xa0
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80255b89>] trace_hardirqs_on+0xd9/0x180
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80523c2d>] error_exit+0x0/0xa9
      >
      > possible reason: unannotated irqs-off.
      > irq event stamp: 4693
      > hardirqs last  enabled at (4693): [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      > hardirqs last disabled at (4692): [<ffffffff80522c17>] trace_hardirqs_off_thunk+0x35/0x37
      > softirqs last  enabled at (3546): [<ffffffff80238343>] __do_softirq+0xb3/0xd0
      > softirqs last disabled at (3521): [<ffffffff8020c97c>] call_softirq+0x1c/0x30
      
      more early fixups for notify_die()..
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fb1dac90
  10. 15 Jan, 2008 5 commits
    • Luck, Tony's avatar
      [IA64] Fix unaligned handler for floating point instructions with base update · 1a499150
      Luck, Tony authored
      
      
      The compiler team did the hard work for this distilling a problem in
      large fortran application which showed up when applied to a 290MB input
      data set down to this instruction:
      
      	ldfd f34=[r17],-8
      
      Which they noticed incremented r17 by 0x10 rather than decrementing it
      by 8 when the value in r17 caused an unaligned data fault.  I tracked
      it down to some bad instruction decoding in unaligned.c. The code
      assumes that the 'x' bit can determine whether the instruction is
      an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on
      page 3:302 of the SDM).  But for opcode=7 the 'x' bit is irrelevent,
      all variants are "ldf" instructions (see table 4-36 on page 3:306).
      
      Note also that interpreting the instruction as "ldfp" means that the
      "paired" floating point register (f35 in the example here) will also
      be corrupted.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      1a499150
    • Mathieu Desnoyers's avatar
      Fix Blackfin HARDWARE_PM support · 7d2284b0
      Mathieu Desnoyers authored
      This patch restores the blackfin Hardware Performance Monitor Profiling
      support that was killed by the combining of instrumentation menus in
      commit 09cadedb
      
      .
      
      Since there seems to be no good reason to behave differently from other
      architectures, it now automatically selects the hardware performance
      counters whenever the profiling is activated.
      
      mach-common/irqpanic.c: pm_overflow calls pm_overflow_handler which is
      in oprofile/op_model_bf533.c.  I doubt that setting HARDWARE_PM as "m"
      will work at all, since the pm_overflow_handler should be in the core
      kernel image because it is called by irqpanic.c.
      
      Therefore, I change HARDWARE_PM from a tristate to a bool.
      
      The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since
      part of the HARDWARE_PM support files sits in this directory, it makes sense to
      also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on
      PROFILING, it is correct to only depend on OPROFILE only.
      
      Thanks to Adrian Bunk for finding this bug and providing an initial
      patch.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Adrian Bunk <adrian.bunk@movial.fi>
      CC: Randy Dunlap <randy.dunlap@oracle.com>
      CC: bryan.wu@analog.com
      Acked-by: default avatarRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d2284b0
    • Linus Torvalds's avatar
      Fix ARM profiling/instrumentation configuration · 38ad9aeb
      Linus Torvalds authored
      Commit 09cadedb
      
       ("Combine
      instrumentation menus in kernel/Kconfig.instrumentation") broke ARM
      profiling support, since ARM has some extra Kconfig options and doesn't
      just use the common OPROFILE/KPROBES config options.
      
      Rather than just revert the thing outright, or add ARM-specific
      knowledge to the generic Kconfig.instrumentation file (where the only
      and whole point was to be generic, not too architecture-specific), this
      just makes ARM not use the generic version, since it doesn't suit it.
      
      So create an arm-specific version of Kconfig.instrumentation instead,
      and use that.
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarRussell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      38ad9aeb
    • Bernhard Walle's avatar
      x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTC · 8ee291f8
      Bernhard Walle authored
      
      
      In the current code, RTC_AIE doesn't work if the RTC relies on
      CONFIG_HPET_EMULATE_RTC because the code sets the RTC_AIE flag in
      hpet_set_rtc_irq_bit().  The interrupt handles does accidentally check
      for RTC_PIE and not RTC_AIE when comparing the time which was set in
      hpet_set_alarm_time().
      
      I now verified on a test system here that without the patch applied,
      the attached test program fails on a system that has HPET with
      2.6.24-rc7-default. That's not critical since I guess the problem has
      been there for several kernel releases, but as the fix is quite
      obvious.
      
      Configuration is CONFIG_RTC=y and CONFIG_HPET_EMULATE_RTC=y.
      Signed-off-by: default avatarBernhard Walle <bwalle@suse.de>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8ee291f8
    • Ingo Molnar's avatar
      x86: fix boot crash on HIGHMEM4G && SPARSEMEM · 23be8c7d
      Ingo Molnar authored
      Denys Fedoryshchenko reported a bootup crash when he upgraded
      his system from 3GB to 4GB RAM:
      
         http://lkml.org/lkml/2008/1/7/9
      
      
      
      the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page()
      to return an invalid pointer when the pfn is in a memory hole. The
      256 MB PCI aperture at the end of RAM was not mapped by sparsemem,
      and hence the pfn was not valid. But set_highmem_pages_init() iterated
      this range without checking the pfn's validity first.
      
      this bug was probably present in the sparsemem code ever since sparsemem
      has been introduced in v2.6.13. It was masked due to HIGHMEM64G using
      larger memory regions in sparsemem_32.h:
      
       #ifdef CONFIG_X86_PAE
       #define SECTION_SIZE_BITS       30
       #define MAX_PHYSADDR_BITS       36
       #define MAX_PHYSMEM_BITS        36
       #else
       #define SECTION_SIZE_BITS       26
       #define MAX_PHYSADDR_BITS       32
       #define MAX_PHYSMEM_BITS        32
       #endif
      
      which creates 1GB sparsemem regions instead of 64MB sparsemem regions.
      So in practice we only ever created true sparsemem holes on x86 with
      HIGHMEM4G - but that was rarely used by distros.
      
      ( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced
        the sparsemem region size to 256 MB. )
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      23be8c7d
  11. 14 Jan, 2008 9 commits
    • Paul Mackerras's avatar
      [POWERPC] Fix boot failure on POWER6 · dfbe0d3b
      Paul Mackerras authored
      Commit 473980a9 added a call to clear
      the SLB shadow buffer before registering it.  Unfortunately this means
      that we clear out the entries that slb_initialize has previously set in
      there.  On POWER6, the hypervisor uses the SLB shadow buffer when doing
      partition switches, and that means that after the next partition switch,
      each non-boot CPU has no SLB entries to map the kernel text and data,
      which causes it to crash.
      
      This fixes it by reverting most of 473980a9 and instead clearing the
      3rd entry explicitly in slb_initialize.  This fixes the problem that
      473980a9
      
       was trying to solve, but without breaking POWER6.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      dfbe0d3b
    • Benjamin Herrenschmidt's avatar
      [POWERPC] Workaround for iommu page alignment · d262c32a
      Benjamin Herrenschmidt authored
      Commit 5d2efba6
      
       changed our iommu code
      so that it always uses an iommu page size of 4kB.  That means with our
      current code, drivers may do a dma_map_sg() of a 64kB page and obtain
      a dma_addr_t that is only 4k aligned.
      
      This works fine in most cases except for some infiniband HW it seems,
      where they tell the HW about the page size and it ignores the low bits
      of the DMA address.
      
      This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
      for mappings of objects that are page aligned in the first place and whose
      size is larger or equal to a page.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      d262c32a
    • Thomas Bogendoerfer's avatar
      [MIPS] Cobalt: Qube1 has no serial port so don't use it · c43756da
      Thomas Bogendoerfer authored
      
      
      Because Qube1 doesn't have a serial chip waiting for transmit fifo empty
      takes forever, which isn't a good idea. No prom_putchar/early console
      for Qube1 fixes this.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Acked-by: default avatarYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      c43756da
    • Thomas Bogendoerfer's avatar
      [MIPS] Cobalt: Fix ethernet interrupts for RaQ1 · f6c0f32e
      Thomas Bogendoerfer authored
      
      
      RAQ1 uses the same interrupt routing as Qube2.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f6c0f32e
    • Aurelien Jarno's avatar
      [MIPS] Kconfig fixes for BCM47XX platform · 2f02c15a
      Aurelien Jarno authored
      
      
      The patch below fixes two problems for Kconfig on the BCM47xx platform:
      
      - arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. Selecting
        SSB_DRIVER_EXTIF makes sure those functions are available.
      - arch/mips/pci/pci.c needs, when enabled, platform specific functions,
        which are defined when SSB_PCICORE_HOSTMODE is enabled.
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      2f02c15a
    • Jesper Nilsson's avatar
      CRIS v10: driver for ds1302 needs to include cris-specific i2c.h · bbde25b1
      Jesper Nilsson authored
      
      
      This fixes compilation error where i2c_init wasn't defined.
      Also, remove the CVS log and version tags, they are no longer useful.
      Signed-off-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bbde25b1
    • Jesper Nilsson's avatar
      CRIS v10: kernel/time.c needs to include linux/vmstat.h to compile · d2d159db
      Jesper Nilsson authored
      
      
      This fixes compile error when nr_free_pages() from linux/swap.h
      expands to global_page_state(NR_FREE_PAGES), but linux/vmstat.h isn't
      included to declare global_page_state().
      Signed-off-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d2d159db
    • Jesper Nilsson's avatar
      CRIS v10: correct do_signal to fix oops and clean up signal handling in general · a4858d4d
      Jesper Nilsson authored
      
      
      This fixes a kernel panic on boot due to do_signal not being compatible
      with it's callers.
      
      - do_signal now returns void, and does not have the previous signal set
        as a parameter.
      - Remove sys_rt_sigsuspend, we can use the common one instead.
      - Change sys_sigsuspend to be more like x86, don't call do_signal here.
      - handle_signal, setup_frame and setup_rt_frame now return -EFAULT
        if we've delivered a segfault, which is used by callers to perform
        necessary cleanup.
      - Break long lines, correct whitespace and formatting errors.
      Signed-off-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a4858d4d
    • Steven Rostedt's avatar
      Kick CPUS that might be sleeping in cpus_idle_wait · 40d6a146
      Steven Rostedt authored
      
      
      Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
      already in idle, have no tasks waiting to run and have no interrupts going
      to them.  This is common on bootup when switching cpu idle governors.
      
      This patch gives those CPUS that don't check in an IPI kick.
      
       Background:
       -----------
      I notice this while developing the mcount patches, that every once in a
      while the system would hang. Looking deeper, the hang was always at boot
      up when registering init_menu of the cpu_idle menu governor. Talking
      with Thomas Gliexner, we discovered that one of the CPUS had no timer
      events scheduled for it and it was in idle (running with NO_HZ). So the
      CPU would not set the cpu_idle_state bit.
      
      Hitting sysrq-t a few times would eventually route the interrupt to the
      stuck CPU and the system would continue.
      
      Note, I would have used the PDA isidle but that is set after the
      cpu_idle_state bit is cleared, and would leave a window open where we
      may miss being kicked.
      
      hmm, looking closer at this, we still have a small race window between
      clearing the cpu_idle_state and disabling interrupts (hence the RFC).
      
          CPU0:                          CPU 1:
        ---------                       ---------
       cpu_idle_wait():                 cpu_idle():
            |                           __cpu_cpu_var(is_idle) = 1;
            |                           if (__get_cpu_var(cpu_idle_state)) /* == 0 */
       per_cpu(cpu_idle_state, 1) = 1;         |
       if (per_cpu(is_idle, 1)) /* == 1 */     |
       smp_call_function(1)                    |
            |                             receives ipi and runs do_nothing.
       wait on map == empty               idle();
         /* waits forever */
      
      So really we need interrupts off for most of this then. One might think
      that we could simply clear the cpu_idle_state from do_nothing, but I'm
      assuming that cpu_idle governors can be removed, and this might cause a
      race that a governor might be used after the module was removed.
      
      Venki said:
      
        I think your RFC patch is the right solution here.  As I see it, there is
        no race with your RFC patch.  As long as you call a dummy smp_call_function
        on all CPUs, we should be OK.  We can get rid of cpu_idle_state and the
        current wait forever logic altogether with dummy smp_call_function.  And so
        there wont be any wait forever scenario.
      
        The whole point of cpu_idle_wait() is to make all CPUs come out of idle
        loop atleast once.  The caller will use cpu_idle_wait something like this.
      
        // Want to change idle handler
      
        - Switch global idle handler to always present default_idle
      
        - call cpu_idle_wait so that all cpus come out of idle for an instant
          and stop using old idle pointer and start using default idle
      
        - Change the idle handler to a new handler
      
        - optional cpu_idle_wait if you want all cpus to start using the new
          handler immediately.
      
      Maybe the below 1s patch is safe bet for .24.  But for .25, I would say we
      just replace all complicated logic by simple dummy smp_call_function and
      remove cpu_idle_state altogether.
      Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      40d6a146
  12. 12 Jan, 2008 2 commits
  13. 11 Jan, 2008 3 commits