Messages in this thread | | | Date | Mon, 7 Dec 2009 12:48:28 -0800 | From | Andrew Morton <> | Subject | Re: kernel problem |
| |
On Mon, 7 Dec 2009 14:50:11 +0000 Mel Gorman <mel@csn.ul.ie> wrote:
> On Fri, Dec 04, 2009 at 10:41:09AM -0500, Steven Rostedt wrote: > > [ Added Cc's of people that may be interested in this ] > > > <SNIP> > > > ------------[ cut here ]------------ > > > 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. > > First off, it would appear that every block driver under the sun is > being loaded. I seriously doubt this controller really exists in the > machine.
I'd be surprised if anyone uses xd.c any more.
> Second, it's a real warning as the driver is trying to allocate a buffer of > size 0 which get_order() chokes on.
ooh, good one. I couldn't work it out.
Have we changed behaviour here? Is it possible that an xd_dma_mem_alloc(0) in some earlier kernel did something different?
> For bonus points, it tries to allocate > a buffer before it knows what size it should be. This patch should resolve > the problem but because I don't have the hardware to test it on, it could > do with a second set of eyes just to be sure the rejigged logic makes sense. > > If this is ok, what is the appropriate submission path for unmaintained > block drivers? Is it the block maintainer or someone else?
Yup, Jens would be the appropriate target.
> ==== CUT HERE ==== > block,xd: Delay allocation of DMA buffers until device is known > > 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. > > ...
| |