(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Jun 2010 17:32:04 GMT bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=16148 > > Summary: page allocation failure. order:1, mode:0x50d0 > Product: Memory Management > Version: 2.5 > Kernel Version: 2.6.35-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Page Allocator > AssignedTo: akpm@xxxxxxxxxxxxxxxxxxxx > ReportedBy: devnull@xxxxxxxx > Regression: No > > > Created an attachment (id=26687) > --> (https://bugzilla.kernel.org/attachment.cgi?id=26687) > dmesg > > Never seen this before. > > 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux > > [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0 > [48126.787691] Pid: 1895, comm: Xorg Tainted: G W 2.6.35-rc1 #1 > [48126.787694] Call Trace: > [48126.787709] [<ffffffff811192f5>] __alloc_pages_nodemask+0x5f5/0x6f0 > [48126.787716] [<ffffffff81148695>] alloc_pages_current+0x95/0x100 > [48126.787720] [<ffffffff8114e04a>] new_slab+0x2ba/0x2c0 > [48126.787724] [<ffffffff8114ed0b>] __slab_alloc+0x14b/0x4e0 > [48126.787730] [<ffffffff81403f91>] ? security_vm_enough_memory_kern+0x21/0x30 > [48126.787736] [<ffffffff81556e6a>] ? agp_alloc_page_array+0x5a/0x70 > [48126.787740] [<ffffffff8115087f>] __kmalloc+0x11f/0x1c0 > [48126.787744] [<ffffffff81556e6a>] agp_alloc_page_array+0x5a/0x70 > [48126.787747] [<ffffffff81556ee4>] agp_generic_alloc_user+0x64/0x140 > [48126.787750] [<ffffffff8155717a>] agp_allocate_memory+0x9a/0x140 > [48126.787755] [<ffffffff8156c179>] drm_agp_allocate_memory+0x9/0x10 > [48126.787758] [<ffffffff8156c1d7>] drm_agp_bind_pages+0x57/0x100 > [48126.787765] [<ffffffff81627fe4>] i915_gem_object_bind_to_gtt+0x144/0x340 > [48126.787768] [<ffffffff81628295>] i915_gem_object_pin+0xb5/0xd0 > [48126.787772] [<ffffffff81629a4c>] i915_gem_do_execbuffer+0x6cc/0x14f0 > [48126.787777] [<ffffffff81091ba0>] ? __is_ram+0x0/0x10 > [48126.787783] [<ffffffff8106c76e>] ? lookup_memtype+0xce/0xe0 > [48126.787787] [<ffffffff8162ab11>] ? i915_gem_execbuffer+0x91/0x390 > [48126.787790] [<ffffffff8162ac55>] i915_gem_execbuffer+0x1d5/0x390 > [48126.787794] [<ffffffff816255b0>] ? i915_gem_sw_finish_ioctl+0x90/0xc0 > [48126.787799] [<ffffffff81565a0a>] drm_ioctl+0x32a/0x4b0 > [48126.787802] [<ffffffff8162aa80>] ? i915_gem_execbuffer+0x0/0x390 > [48126.787807] [<ffffffff8116c248>] vfs_ioctl+0x38/0xd0 > [48126.787810] [<ffffffff8116c87a>] do_vfs_ioctl+0x8a/0x580 > [48126.787814] [<ffffffff8116cdf1>] sys_ioctl+0x81/0xa0 > [48126.787820] [<ffffffff8103af02>] system_call_fastpath+0x16/0x1b > David, I have a vague feeling that we've been round this loop before.. Why does agp_alloc_page_array() use __GFP_NORETRY? It's pretty unusual and it's what caused this spew. There's nothing in the changelog and the only relevant commentary appears to be "This speeds things up and also saves memory for small AGP regions", which is inscrutable. Can you please add a usable comment there? Presumably this was added in response to some observed behaviour, but what was it?? If the __GFP_NORETRY is indeed useful and legitimate and given that we have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as well to keep the bug reports away. btw, agp_memory.vmalloc_flag can be done away with - it's conventional to use is_vmalloc_addr() for this. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
