1. 03 7月, 2009 9 次提交
  2. 18 6月, 2009 1 次提交
  3. 17 6月, 2009 1 次提交
    • R
      kmap_types: make most arches use generic header file · e4c9dd0f
      Randy Dunlap 提交于
      Convert most arches to use asm-generic/kmap_types.h.
      
      Move the KM_FENCE_ macro additions into asm-generic/kmap_types.h,
      controlled by __WITH_KM_FENCE from each arch's kmap_types.h file.
      
      Would be nice to be able to add custom KM_types per arch, but I don't yet
      see a nice, clean way to do that.
      
      Built on x86_64, i386, mips, sparc, alpha(tonyb), powerpc(tonyb), and
      68k(tonyb).
      
      Note: avr32 should be able to remove KM_PTE2 (since it's not used) and
      then just use the generic kmap_types.h file.  Get avr32 maintainer
      approval.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: <linux-arch@vger.kernel.org>
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Bryan Wu <cooloney@kernel.org>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: "Luck Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4c9dd0f
  4. 12 6月, 2009 3 次提交
  5. 07 6月, 2009 1 次提交
  6. 03 4月, 2009 1 次提交
  7. 02 4月, 2009 3 次提交
  8. 31 3月, 2009 4 次提交
    • J
    • H
      parisc: add ftrace (function and graph tracer) functionality · d75f054a
      Helge Deller 提交于
      This patch adds the ftrace debugging functionality to the parisc kernel.
      It will currently only work with 64bit kernels, because the gcc options -pg
      and -ffunction-sections can't be enabled at the same time and -ffunction-sections
      is still needed to be able to link 32bit kernels.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      d75f054a
    • C
      parisc: expose 32/64-bit capabilities in cpuinfo · 445c088f
      Colin Watson 提交于
      It'd be rather useful for debian-installer if we could get hold of
      accurate firmware information on whether only 32-bit kernels are
      supported, only 64-bit kernels, or both; this would allow us to present
      an accurate menu of kernel packages if more than one is available,
      rather than the user having to guess. This patch attempts to expose it
      in cpuinfo.
      
      I adjusted pdc_model_capabilities to cope with a potential
      PDC_INVALID_ARG return as the firmware manual instructs, by assuming
      32-bit only. This may be the wrong place for it.
      
      I made up user-visible capability names by total fiat and for the moment
      ignored the other bits that may appear in the capabilities word.
      
      I have no PA-RISC machine myself to test on, and no PA experience
      either, so I rather hope that somebody will kind-heartedly take this and
      fix it up if needed. I ran it past Dann Frazier on IRC and he said
      "looks good to me", but I think without testing.
      
      Also, this is against the Ubuntu 2.6.28 kernel tree since that's what I
      had handy and I was a bit tight on disk space to slurp down another
      tree. Sorry if it's skewed in any relevant way; I'll be happy to adjust
      if necessary.
      
      Thanks in advance!
      Signed-off-by: NColin Watson <cjwatson@canonical.com>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      445c088f
    • H
      parisc: fix usage of 32bit PTE page table entries on 32bit kernels · 48d27cb2
      Helge Deller 提交于
      This patch fixes a long outstanding bug on 32bit parisc linux kernels
      which prevented us from using 32bit PTE table entries (instead of 64bit
      entries of which 32bit were unused).
      
      The problem was caused by this assembler statement in the L2_ptep
      macro in arch/parisc/kernel/entry.S:447:
      	EXTR \va,31-ASM_PGDIR_SHIFT,ASM_BITS_PER_PGD,\index
      which expanded to
      	extrw,u r8,9,11,r1
      and which has undefined behavior since the length value (11) extends
      beyond the leftmost bit (11-1 > 9).
      Interestingly PA2.0 processors seem to don't care and just zero-extend
      the value, while PA1.1 processors don't.
      
      Fix this problem by detecting an address space overflow with ASM_BITS_PER_PGD
      and adjusting it accordingly. To prevent such problems in the future,
      some compile time sanity checks in arch/parisc/mm/init.c were added.
      
      Since the page table now only consumes half of it's old size, we can
      use the freed memory to harmonize 32- and 64bit kernels and let both
      map 16MB for the initial page table.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      48d27cb2
  9. 16 3月, 2009 1 次提交
  10. 13 3月, 2009 6 次提交
  11. 03 3月, 2009 1 次提交
  12. 16 2月, 2009 1 次提交
    • P
      net: new user space API for time stamping of incoming and outgoing packets · cb9eff09
      Patrick Ohly 提交于
      User space can request hardware and/or software time stamping.
      Reporting of the result(s) via a new control message is enabled
      separately for each field in the message because some of the
      fields may require additional computation and thus cause overhead.
      User space can tell the different kinds of time stamps apart
      and choose what suits its needs.
      
      When a TX timestamp operation is requested, the TX skb will be cloned
      and the clone will be time stamped (in hardware or software) and added
      to the socket error queue of the skb, if the skb has a socket
      associated with it.
      
      The actual TX timestamp will reach userspace as a RX timestamp on the
      cloned packet. If timestamping is requested and no timestamping is
      done in the device driver (potentially this may use hardware
      timestamping), it will be done in software after the device's
      start_hard_xmit routine.
      Signed-off-by: NPatrick Ohly <patrick.ohly@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb9eff09
  13. 01 2月, 2009 2 次提交
  14. 30 1月, 2009 1 次提交
  15. 15 1月, 2009 1 次提交
  16. 10 1月, 2009 1 次提交
  17. 07 1月, 2009 1 次提交
  18. 06 1月, 2009 2 次提交
    • K
      parisc: fix kernel crash (protection id trap) when compiling ruby1.9 · c61c25eb
      Kyle McMartin 提交于
      On Wed, Dec 17, 2008 at 11:46:05PM +0100, Helge Deller wrote:
      >
      
      Honestly, I can't decide whether to apply this. It really should never
      happen in the kernel, since the kernel can guarantee it won't get the
      access rights failure (highest privilege level, and can set %sr and
      %protid to whatever it wants.)
      
      It really genuinely is a bug that probably should panic the kernel. The
      only precedent I can easily see is x86 fixing up a bad iret with a
      general protection fault, which is more or less analogous to code 27
      here.
      
      On the other hand, taking the exception on a userspace access really
      isn't all that critical, and there's fundamentally little reason for the
      kernel not to SIGSEGV the process, and continue...
      
      Argh.
      
      (btw, I've instrumented my do_sys_poll with a pile of assertions that
       %cr8 << 1 == %sr3 == current->mm.context... let's see if where we're
       getting corrupted is deterministic, though, I would guess that it won't
       be.)
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      c61c25eb
    • K
      parisc: fix ipv6 checksum · 5fbf6635
      Kyle McMartin 提交于
      ipv6 recently started exhibiting the same symptoms as ipv4 was, add
      a memory clobber around inline checksum assembly that fribbles memory
      to ensure gcc doesn't erroneously cache across it.
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      5fbf6635