1. 03 2月, 2009 2 次提交
    • M
      sata_mv: Fix chip type for Hightpoint RocketRaid 1740/1742 · 4462254a
      Mark Lord 提交于
      Fix chip type for the Highpoint RocketRAID 1740 and 1742 PCI cards.
      These really do have Marvell 6042 chips on them, rather than the 5081 chip.
      
      Confirmed by multiple (two) users (for the 1740), and by examining
      the product photographs from Highpoint's web site.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4462254a
    • P
      [libata] sata_sil: Fix compilation error with libata debugging enabled · 41137aa6
      Pasi Kärkkäinen 提交于
      I tried compiling 2.6.29-rc1 and 2.6.29-rc3 with libata debugging enabled
      and got the following error:
      
        CC [M]  drivers/ata/sata_sil.o
      drivers/ata/sata_sil.c: In function 'sil_fill_sg':
      drivers/ata/sata_sil.c:327: error: 'pi' undeclared (first use in this function)
      drivers/ata/sata_sil.c:327: error: (Each undeclared identifier is reported only once
      drivers/ata/sata_sil.c:327: error: for each function it appears in.)
      make[2]: *** [drivers/ata/sata_sil.o] Error 1
      make[1]: *** [drivers/ata] Error 2
      make: *** [drivers] Error 2
      
      include/linux/libata.h has the following enabled:
      
      #define ATA_DEBUG
      #define ATA_VERBOSE_DEBUG
      #define ATA_IRQ_TRAP
      
      This fixes the compilation.
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      41137aa6
  2. 02 2月, 2009 1 次提交
    • L
      Manually revert "mlock: downgrade mmap sem while populating mlocked regions" · 27421e21
      Linus Torvalds 提交于
      This essentially reverts commit 8edb08ca.
      
      It downgraded our mmap semaphore to a read-lock while mlocking pages, in
      order to allow other threads (and external accesses like "ps" et al) to
      walk the vma lists and take page faults etc.  Which is a nice idea, but
      the implementation does not work.
      
      Because we cannot upgrade the lock back to a write lock without
      releasing the mmap semaphore, the code had to release the lock entirely
      and then re-take it as a writelock.  However, that meant that the caller
      possibly lost the vma chain that it was following, since now another
      thread could come in and mmap/munmap the range.
      
      The code tried to work around that by just looking up the vma again and
      erroring out if that happened, but quite frankly, that was just a buggy
      hack that doesn't actually protect against anything (the other thread
      could just have replaced the vma with another one instead of totally
      unmapping it).
      
      The only way to downgrade to a read map _reliably_ is to do it at the
      end, which is likely the right thing to do: do all the 'vma' operations
      with the write-lock held, then downgrade to a read after completing them
      all, and then do the "populate the newly mlocked regions" while holding
      just the read lock.  And then just drop the read-lock and return to user
      space.
      
      The (perhaps somewhat simpler) alternative is to just make all the
      callers of mlock_vma_pages_range() know that the mmap lock got dropped,
      and just re-grab the mmap semaphore if it needs to mlock more than one
      vma region.
      
      So we can do this "downgrade mmap sem while populating mlocked regions"
      thing right, but the way it was done here was absolutely not correct.
      Thus the revert, in the expectation that we will do it all correctly
      some day.
      
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27421e21
  3. 01 2月, 2009 11 次提交
  4. 31 1月, 2009 26 次提交