Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 12 1月, 2010 1 次提交
  3. 07 1月, 2010 1 次提交
  5. 04 1月, 2010 1 次提交
  7. 31 12月, 2009 1 次提交
  9. 30 12月, 2009 3 次提交
  11. 22 12月, 2009 3 次提交
  13. 21 12月, 2009 4 次提交
  15. 18 12月, 2009 1 次提交
  17. 16 12月, 2009 2 次提交
  19. 09 12月, 2009 3 次提交
    • M
      block,xd: Delay allocation of DMA buffers until device is known · a3b8d92d
      由 Mel Gorman 提交于 
      Loading the XD module triggers a warning like

 WARNING: at mm/page_alloc.c:1805
 __alloc_pages_nodemask+0x127/0x48f()
 Hardware name: System Product Name
 Modules linked in:
 Pid: 1, comm: swapper Not tainted 2.6.32-rc8-git5 #1
 Call Trace:
  [<c103d94b>] warn_slowpath_common+0x65/0x95
  [<c103d98d>] warn_slowpath_null+0x12/0x15
  [<c109550c>] __alloc_pages_nodemask+0x127/0x48f
  [<c10be964>] ? get_slab+0x8/0x50
  [<c10b8979>] alloc_page_interleave+0x2e/0x6e
  [<c10b8a10>] alloc_pages_current+0x57/0x99
  [<c2083a4a>] ? xd_init+0x0/0x482
  [<c1094c38>] __get_free_pages+0xd/0x1e
  [<c2083a94>] xd_init+0x4a/0x482
  [<c2082df0>] ? loop_init+0x104/0x16a
  [<c169162d>] ? loop_probe+0x0/0xaf
  [<c2083a4a>] ? xd_init+0x0/0x482
  [<c1001143>] do_one_initcall+0x51/0x13f
  [<c204a307>] kernel_init+0x10b/0x15f
  [<c204a1fc>] ? kernel_init+0x0/0x15f
  [<c1004347>] kernel_thread_helper+0x7/0x10
 ---[ end trace 686db6333ade6e7a ]---
 xd: Out of memory.

The warning is because the alloc_pages is called with an
order >= MAX_ORDER. The simplistic reason is that get_order(0) returns garbage
values when given 0 as a size. The more complex reason is that the XD driver
initialisation is broken.

It's not clear why this ever worked. XD allocates a buffer for DMA based
on the value of xd_maxsectors. This value is determined by the exact
type of controller in use but the value is determined *after* an attempt
has been made to allocate the buffer. i.e. the requested size of the DMA
buffer will always be 0.

This patch alters how XD is initialised slightly by allocating the
buffer when and if a device has actually been detected. The error paths
are updated to suit the new logic.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      a3b8d92d
    • P
      drbd: Following the hmac change to SHASH (see linux commit 8bd1209c) · 8b43aebd
      由 Philipp Reisner 提交于 
      Signed-off-by: NPhilipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: NLars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      8b43aebd
    • B
      powerpc/macio: Rework hotplug media bay support · d58b0c39
      由 Benjamin Herrenschmidt 提交于 
      The hotplug mediabay has tendrils deep into drivers/ide code
which makes a libata port reather difficult. In addition it's
ugly and could be done better.

This reworks the interface between the mediabay and the rest
of the world so that:

   - Any macio_driver can now have a mediabay_event callback
which will be called when that driver sits on a mediabay and
it's been either plugged or unplugged. The device type is
passed as an argument. We can now move all the IDE cruft
into the IDE driver itself

   - A check_media_bay() function can be used to take a peek
at the type of device currently in the bay if any, a cleaner
variant of the previous function with the same name.

   - A pair of lock/unlock functions are exposed to allow the
IDE driver to block the hotplug callbacks during the initial
setup and probing of the bay in order to avoid nasty race
conditions.

   - The mediabay code no longer needs to spin on the status
register of the IDE interface when it detects an IDE device,
this is done just fine by the IDE code itself

Overall, less code, simpler, and allows for another driver
than our old drivers/ide based one.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d58b0c39
  21. 05 12月, 2009 1 次提交
  23. 04 12月, 2009 1 次提交
  25. 02 12月, 2009 1 次提交
  27. 25 11月, 2009 3 次提交
  29. 23 11月, 2009 2 次提交
    • 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
  31. 13 11月, 2009 12 次提交