1. 26 11月, 2009 2 次提交
    • I
      block: add helpers to run flush_dcache_page() against a bio and a request's pages · 2d4dc890
      Ilya Loginov 提交于
      Mtdblock driver doesn't call flush_dcache_page for pages in request.  So,
      this causes problems on architectures where the icache doesn't fill from
      the dcache or with dcache aliases.  The patch fixes this.
      
      The ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE symbol was introduced to avoid
      pointless empty cache-thrashing loops on architectures for which
      flush_dcache_page() is a no-op.  Every architecture was provided with this
      flush pages on architectires where ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE is
      equal 1 or do nothing otherwise.
      
      See "fix mtd_blkdevs problem with caches on some architectures" discussion
      on LKML for more information.
      Signed-off-by: NIlya Loginov <isloginov@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Peter Horton <phorton@bitbox.co.uk>
      Cc: "Ed L. Cashin" <ecashin@coraid.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2d4dc890
    • G
      cfq: Make use of service count to estimate the rb_key offset · 3586e917
      Gui Jianfeng 提交于
      For the moment, different workload cfq queues are put into different
      service trees. But CFQ still uses "busy_queues" to estimate rb_key
      offset when inserting a cfq queue into a service tree. I think this
      isn't appropriate, and it should make use of service tree count to do
      this estimation. This patch is for for-2.6.33 branch.
      Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      3586e917
  2. 23 11月, 2009 4 次提交
    • A
      cciss: change Cmd_sg_list.sg_chain_dma type to dma_addr_t · 32a87c01
      Alex Chiang 提交于
      A recent commit broke the ia64 build:
      
      	Author: Don Brace <brace@beardog.cce.hp.com>
      	Date:   Thu Nov 12 12:50:01 2009 -0600
      
      	cciss: Add enhanced scatter-gather support.
      
      because of this hunk:
      
      	--- a/drivers/block/cciss.h
      	+++ b/drivers/block/cciss.h
      	+struct Cmd_sg_list {
      	+       SGDescriptor_struct     *sgchain;
      	+       dma64_addr_t            sg_chain_dma;
      	+       int                     chain_block_size;
      	+};
      
      The issue is that dma64_addr_t isn't #define'd on ia64.
      
      The way that we're using Cmd_sg_list.sg_chain_dma is to hold an
      address returned from pci_map_single().
      
      	+               temp64.val = pci_map_single(h->pdev,
      	+                                 h->cmd_sg_list[c->cmdindex]->sgchain,
      	+                                 len, dir);
      	+
      	+               h->cmd_sg_list[c->cmdindex]->sg_chain_dma = temp64.val;
      
      pci_map_single() returns a dma_addr_t too.
      
      This code will still work even on a 32-bit x86 build, where
      dma_addr_t is defined to be a u32 because it will simply be
      promoted to the __u64 that temp64.val is defined as.
      
      Thus, declaring Cmd_sg_list.sg_chain_dma as dma_addr_t is safe.
      
      Cc: Don Brace <brace@beardog.cce.hp.com>
      Cc: Stephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      32a87c01
    • S
      cciss: fix scatter gather cleanup problems · d61c4269
      Stephen M. Cameron 提交于
      On driver unload, only free up the extra scatter gather data if they were
      allocated in the first place (the controller supports it) and don't forget
      to free up the sg_cmd_list array of pointers.
      Signed-off-by: NDon Brace <brace@beardog.cce.hp.com>
      Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      d61c4269
    • K
      partitions: read whole sector with EFI GPT header · 87038c2d
      Karel Zak 提交于
      The size of EFI GPT header is not static, but whole sector is
      allocated for the header. The HeaderSize field must be greater
      than 92 (= sizeof(struct gpt_header) and must be less than or
      equal to the logical block size.
      
      It means we have to read whole sector with the header, because the
      header crc32 checksum is calculated according to HeaderSize.
      
      For more details see UEFI standard (version 2.3, May 2009):
        - 5.3.1 GUID Format overview, page 93
        - Table 13. GUID Partition Table Header, page 96
      Signed-off-by: NKarel Zak <kzak@redhat.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      87038c2d
    • K
      partitions: use sector size for EFI GPT · 7d13af32
      Karel Zak 提交于
      Currently, kernel uses strictly 512-byte sectors for EFI GPT parsing.
      That's wrong.
      
      UEFI standard (version 2.3, May 2009, 5.3.1 GUID Format overview, page
      95) defines that LBA is always based on the logical block size. It
      means bdev_logical_block_size() (aka BLKSSZGET) for Linux.
      
      This patch removes static sector size from EFI GPT parser.
      
      The problem is reproducible with the latest GNU Parted:
      
       # modprobe scsi_debug dev_size_mb=50 sector_size=4096
      
        # ./parted /dev/sdb print
        Model: Linux scsi_debug (scsi)
        Disk /dev/sdb: 52.4MB
        Sector size (logical/physical): 4096B/4096B
        Partition Table: gpt
      
        Number  Start   End     Size    File system  Name     Flags
         1      24.6kB  3002kB  2978kB               primary
         2      3002kB  6001kB  2998kB               primary
         3      6001kB  9003kB  3002kB               primary
      
        # blockdev --rereadpt /dev/sdb
        # dmesg | tail -1
         sdb: unknown partition table      <---- !!!
      
      with this patch:
      
        # blockdev --rereadpt /dev/sdb
        # dmesg | tail -1
         sdb: sdb1 sdb2 sdb3
      Signed-off-by: NKarel Zak <kzak@redhat.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      7d13af32
  3. 13 11月, 2009 11 次提交
  4. 11 11月, 2009 1 次提交
  5. 10 11月, 2009 1 次提交
  6. 09 11月, 2009 1 次提交
    • C
      cfq-iosched: fix next_rq computation · cf7c25cf
      Corrado Zoccolo 提交于
      Cfq has a bug in computation of next_rq, that affects transition
      between multiple sequential request streams in a single queue
      (e.g.: two sequential buffered writers of the same priority),
      causing the alternation between the two streams for a transient period.
      
        8,0    1    18737     0.260400660  5312  D   W 141653311 + 256
        8,0    1    20839     0.273239461  5400  D   W 141653567 + 256
        8,0    1    20841     0.276343885  5394  D   W 142803919 + 256
        8,0    1    20843     0.279490878  5394  D   W 141668927 + 256
        8,0    1    20845     0.292459993  5400  D   W 142804175 + 256
        8,0    1    20847     0.295537247  5400  D   W 141668671 + 256
        8,0    1    20849     0.298656337  5400  D   W 142804431 + 256
        8,0    1    20851     0.311481148  5394  D   W 141668415 + 256
        8,0    1    20853     0.314421305  5394  D   W 142804687 + 256
        8,0    1    20855     0.318960112  5400  D   W 142804943 + 256
      
      The fix makes sure that the next_rq is computed from the last
      dispatched request, and not affected by merging.
      
        8,0    1    37776     4.305161306     0  D   W 141738087 + 256
        8,0    1    37778     4.308298091     0  D   W 141738343 + 256
        8,0    1    37780     4.312885190     0  D   W 141738599 + 256
        8,0    1    37782     4.315933291     0  D   W 141738855 + 256
        8,0    1    37784     4.319064459     0  D   W 141739111 + 256
        8,0    1    37786     4.331918431  5672  D   W 142803007 + 256
        8,0    1    37788     4.334930332  5672  D   W 142803263 + 256
        8,0    1    37790     4.337902723  5672  D   W 142803519 + 256
        8,0    1    37792     4.342359774  5672  D   W 142803775 + 256
        8,0    1    37794     4.345318286     0  D   W 142804031 + 256
      Signed-off-by: NCorrado Zoccolo <czoccolo@gmail.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      cf7c25cf
  7. 05 11月, 2009 1 次提交
  8. 04 11月, 2009 17 次提交
  9. 03 11月, 2009 1 次提交
  10. 02 11月, 2009 1 次提交