1. 24 Mar, 2008 3 commits
    • Roland Dreier's avatar
      SVCRDMA: Use only 1 RDMA read scatter entry for iWARP adapters · d3073779
      Roland Dreier authored
      The iWARP protocol limits RDMA read requests to a single scatter
      entry.  NFS/RDMA has code in rdma_read_max_sge() that is supposed to
      limit the sge_count for RDMA read requests to 1, but the code to do
      that is inside an #ifdef RDMA_TRANSPORT_IWARP block.  In the mainline
      kernel at least, RDMA_TRANSPORT_IWARP is an enum and not a
      preprocessor #define, so the #ifdef'ed code is never compiled.
      
      In my test of a kernel build with -j8 on an NFS/RDMA mount, this
      problem eventually leads to trouble starting with:
      
          svcrdma: Error posting send = -22
          svcrdma : RDMA_READ error = -22
      
      and things go downhill from there.
      
      The trivial fix is to delete the #ifdef guard.  The check seems to be
      a remnant of when the NFS/RDMA code was not merged and needed to
      compile against multiple kernel versions, although I don't think it
      ever worked as intended.  In any case now that the code is upstream
      there's no need to test whether the RDMA_TRANSPORT_IWARP constant is
      defined or not.
      
      Without this patch, my kernel build on an NFS/RDMA mount using NetEffect
      adapters quickly and 100% reproducibly failed with an error like:
      
          ld: final link failed: Software caused connection abort
      
      With the patch applied I was able to complete a kernel build on the
      same setup.
      
      (Tom Tucker says this is "actually an _ancient_ remnant when it had to
      compile against iWARP vs. non-iWARP enabled OFA trees.")
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Acked-by: default avatarTom Tucker <tom@opengridcomputing.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d3073779
    • Linus Torvalds's avatar
      x86-32: Pass the full resource data to ioremap() · b9e76a00
      Linus Torvalds authored
      It appears that 64-bit PCI resources cannot possibly ever have worked on
      x86-32 even when the RESOURCES_64BIT config option was set, because any
      driver that tried to [pci_]ioremap() the resource would have been unable
      to do so because the high 32 bits would have been silently dropped on
      the floor by the ioremap() routines that only used "unsigned long".
      
      Change them to use "resource_size_t" instead, which properly encodes the
      whole 64-bit resource data if RESOURCES_64BIT is enabled.
      Acked-by: default avatarH. Peter Anvin <hpa@kernel.org>
      Acked-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b9e76a00
    • Linus Torvalds's avatar
      Don't 'printk()' while holding xtime lock for writing · 92896bd9
      Linus Torvalds authored
      The printk() can deadlock because it can wake up klogd(), and
      task enqueueing will try to read the time in order to set a hrtimer.
      Reported-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Debugged-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      92896bd9
  2. 23 Mar, 2008 8 commits
  3. 22 Mar, 2008 8 commits
  4. 21 Mar, 2008 21 commits