1. 23 Feb, 2011 4 commits
    • Russell King's avatar
      ARM: improve module relocation fixup diagnostics · 68e6fad4
      Russell King authored
      Current diagnostics are rather poor when things go wrong:
        ipv6: relocation out of range, section 2 reloc 0 sym 'snmp_mib_free'
      
      Let's include a little more information about the problem:
        ipv6: section 2 reloc 0 sym 'snmp_mib_free': relocation 28 out of range (0xbf0000a4 -> 0xc11b4858)
      
      so that we show exactly what the problem is - not only what type of
      relocation but also the offending address range too.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      68e6fad4
    • Russell King's avatar
      ARM: add 'uinstall' target for installing uboot kernels · a65d2922
      Russell King authored
      We have 'install' and 'zinstall' for installing Image and zImage
      kernels, so add 'uinstall' to complete the set.
      
      This allows developers to have a ~/bin/installkernel script which (eg)
      copies the kernel to the tftp server automatically once the kernel
      has built, resulting in a better workflow.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a65d2922
    • Russell King's avatar
      ARM: fix some sparse errors in generic ARM code · 2bbd7e9b
      Russell King authored
      arch/arm/kernel/return_address.c:37:6: warning: symbol 'return_address' was not declared. Should it be static?
      arch/arm/kernel/setup.c:76:14: warning: symbol 'processor_id' was not declared. Should it be static?
      arch/arm/kernel/traps.c:259:1: warning: symbol 'die_lock' was not declared. Should it be static?
      arch/arm/vfp/vfpmodule.c:156:6: warning: symbol 'vfp_raise_sigfpe' was not declared. Should it be static?
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2bbd7e9b
    • Russell King's avatar
      ARM: DMA: top-down allocation in DMA coherent region · 459c1517
      Russell King authored
      Achieve better usage of the DMA coherent region by doing top-down
      allocation rather than bottom up.  If we ask for a 128kB allocation,
      this will be aligned to 128kB and satisfied from the very bottom
      address.  If we then ask for a 600kB allocation, this will be aligned
      to 1MB, and we will have a 896kB hole.
      
      Performing top-down allocation resolves this by allocating the 128kB
      at the very top, and then the 600kB can come in below it without any
      unnecessary wastage.
      
      This problem was reported by Janusz Krzysztofik, who had 2 x 128kB +
      1 x 640kB allocations which wouldn't fit into 1MB.
      Tested-by: default avatarJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      459c1517
  2. 15 Feb, 2011 1 commit
  3. 01 Feb, 2011 1 commit
  4. 31 Jan, 2011 27 commits
  5. 29 Jan, 2011 5 commits
  6. 28 Jan, 2011 2 commits
    • Chuck Lever's avatar
      NFS: NFSv4 readdir loses entries · d1205f87
      Chuck Lever authored
      On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
      NFSv4 mounts of OpenSolaris with something like:
      
      > ./test6: readdir
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
      > 	./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
      > basic tests failed
      > Tests failed, leaving /mnt/klimt mounted
      > [cel@matisse cthon04]$
      
      I narrowed the problem down to nfs4_decode_dirent() reporting that the
      decode buffer had overflowed while decoding the entries for those
      missing files.
      
      verify_attr_len() assumes both it's pointer arguments reside on the
      same page.  When these arguments point to locations on two different
      pages, verify_attr_len() can report false errors.  This can happen now
      that a large NFSv4 readdir result can span pages.
      
      We have reasonably good checking in nfs4_decode_dirent() anyway, so
      it should be safe to simply remove the extra checking.
      
      At a guess, this was introduced by commit 6650239a, "NFS: Don't use
      vm_map_ram() in readdir".
      
      Cc: stable@kernel.org [2.6.37]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d1205f87
    • Chuck Lever's avatar
      NFS: Micro-optimize nfs4_decode_dirent() · c08e76d0
      Chuck Lever authored
      Make the decoding of NFSv4 directory entries slightly more efficient
      by:
      
        1.  Avoiding unnecessary byte swapping when checking XDR booleans,
            and
      
        2.  Not bumping "p" when its value will be immediately replaced by
            xdr_inline_decode()
      
      This commit makes nfs4_decode_dirent() consistent with similar logic
      in the other two decode_dirent() functions.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      c08e76d0