1. 25 1月, 2008 10 次提交
  2. 24 1月, 2008 2 次提交
  3. 23 1月, 2008 3 次提交
  4. 22 1月, 2008 5 次提交
  5. 20 1月, 2008 3 次提交
  6. 19 1月, 2008 3 次提交
  7. 18 1月, 2008 2 次提交
  8. 17 1月, 2008 1 次提交
  9. 16 1月, 2008 4 次提交
    • P
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra 提交于
      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: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fb1dac90
    • L
      [IA64] Fix unaligned handler for floating point instructions with base update · 1a499150
      Luck, Tony 提交于
      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: NTony Luck <tony.luck@intel.com>
      1a499150
    • M
      Fix Blackfin HARDWARE_PM support · 7d2284b0
      Mathieu Desnoyers 提交于
      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: NMathieu 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: NRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d2284b0
    • L
      Fix ARM profiling/instrumentation configuration · 38ad9aeb
      Linus Torvalds 提交于
      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: NIngo Molnar <mingo@elte.hu>
      Acked-by: NRussell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38ad9aeb
  10. 15 1月, 2008 7 次提交
    • B
      x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTC · 8ee291f8
      Bernhard Walle 提交于
      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: NBernhard Walle <bwalle@suse.de>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8ee291f8
    • I
      x86: fix boot crash on HIGHMEM4G && SPARSEMEM · 23be8c7d
      Ingo Molnar 提交于
      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: NIngo Molnar <mingo@elte.hu>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      23be8c7d
    • P
      [POWERPC] Fix boot failure on POWER6 · dfbe0d3b
      Paul Mackerras 提交于
      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: NPaul Mackerras <paulus@samba.org>
      dfbe0d3b
    • B
      [POWERPC] Workaround for iommu page alignment · d262c32a
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d262c32a
    • T
      [MIPS] Cobalt: Qube1 has no serial port so don't use it · c43756da
      Thomas Bogendoerfer 提交于
      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: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Acked-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c43756da
    • T
      [MIPS] Cobalt: Fix ethernet interrupts for RaQ1 · f6c0f32e
      Thomas Bogendoerfer 提交于
      RAQ1 uses the same interrupt routing as Qube2.
      Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f6c0f32e
    • A
      [MIPS] Kconfig fixes for BCM47XX platform · 2f02c15a
      Aurelien Jarno 提交于
      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: NAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2f02c15a