dri-devel June 2010

dri-devel@lists.freedesktop.org

71 participants
237 discussions

Re: [Bug 16148] page allocation failure. order:1, mode:0x50d0
by Andrew Morton 16 Jun '10

16 Jun '10

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). (switching back to email, actually) On Sun, 13 Jun 2010 13:01:57 GMT bugzilla-daemon(a)bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=16148 > > > Mikko C. <mikko.cal(a)gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > … [View More] CC| |mikko.cal(a)gmail.com > > > > > --- Comment #8 from Mikko C. <mikko.cal(a)gmail.com> 2010-06-13 13:01:53 --- > I have been getting this with 2.6.35-rc2 and rc3. > Could it be the same problem? > > > X: page allocation failure. order:0, mode:0x4 > Pid: 1514, comm: X Not tainted 2.6.35-rc3 #1 > Call Trace: > [<ffffffff8108ce49>] ? __alloc_pages_nodemask+0x629/0x680 > [<ffffffff8108c920>] ? __alloc_pages_nodemask+0x100/0x680 > [<ffffffffa00db8f3>] ? ttm_get_pages+0x2c3/0x448 [ttm] > [<ffffffffa00d4658>] ? __ttm_tt_get_page+0x98/0xc0 [ttm] > [<ffffffffa00d4988>] ? ttm_tt_populate+0x48/0x90 [ttm] > [<ffffffffa00d4a26>] ? ttm_tt_bind+0x56/0xa0 [ttm] > [<ffffffffa00d5230>] ? ttm_bo_handle_move_mem+0x1d0/0x430 [ttm] > [<ffffffffa00d76d6>] ? ttm_bo_move_buffer+0x166/0x180 [ttm] > [<ffffffffa00b9736>] ? drm_mm_kmalloc+0x26/0xc0 [drm] > [<ffffffff81030ea9>] ? get_parent_ip+0x9/0x20 > [<ffffffffa00d7786>] ? ttm_bo_validate+0x96/0x130 [ttm] > [<ffffffffa00d7b35>] ? ttm_bo_init+0x315/0x390 [ttm] > [<ffffffffa0122eb8>] ? radeon_bo_create+0x118/0x210 [radeon] > [<ffffffffa0122fb0>] ? radeon_ttm_bo_destroy+0x0/0xb0 [radeon] > [<ffffffffa013704c>] ? radeon_gem_object_create+0x8c/0x110 [radeon] > [<ffffffffa013711f>] ? radeon_gem_create_ioctl+0x4f/0xe0 [radeon] > [<ffffffffa00b10e6>] ? drm_ioctl+0x3d6/0x470 [drm] > [<ffffffffa01370d0>] ? radeon_gem_create_ioctl+0x0/0xe0 [radeon] > [<ffffffff810b965f>] ? do_sync_read+0xbf/0x100 > [<ffffffff810c8965>] ? vfs_ioctl+0x35/0xd0 > [<ffffffff810c8b28>] ? do_vfs_ioctl+0x88/0x530 > [<ffffffff81031ed7>] ? sub_preempt_count+0x87/0xb0 > [<ffffffff810c9019>] ? sys_ioctl+0x49/0x80 > [<ffffffff810ba4fe>] ? sys_read+0x4e/0x90 > [<ffffffff810024ab>] ? system_call_fastpath+0x16/0x1b That's different. ttm_get_pages() looks pretty busted to me. It's not using __GFP_WAIT and it's not using __GFP_FS. It's using a plain GFP_DMA32 so it's using atomic allocations even though it doesn't need to. IOW, it's shooting itself in the head. Given that it will sometimes use GFP_HIGHUSER which includes __GFP_FS and __GFP_WAIT, I assume it can always include __GFP_FS and __GFP_WAIT. If so, it should very much do so. If not then the function is misdesigned and should be altered to take a gfp_t argument so the caller can tell ttm_get_pages() which is the strongest allocation mode which it may use. > [TTM] Unable to allocate page. > radeon 0000:01:05.0: object_init failed for (7827456, 0x00000002) > [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7827456, > 2, 4096, -12) This bug actually broke stuff for you. Something like this: --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c~a +++ a/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -677,7 +677,7 @@ int ttm_get_pages(struct list_head *page /* No pool for cached pages */ if (pool == NULL) { if (flags & TTM_PAGE_FLAG_DMA32) - gfp_flags |= GFP_DMA32; + gfp_flags |= GFP_KERNEL|GFP_DMA32; else gfp_flags |= GFP_HIGHUSER; _ although I wonder whether it should be using pool->gfp_flags. It's a shame that this code was developed and merged in secret :( Had we known, we could have looked at enhancing mempools to cover the requirement, or at implementing this in some generic fashion rather than hiding it down in drivers/gpu/drm. [View Less]

3 2

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 16 Jun '10

16 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #7 from Aidan Marks <aidan(a)cisco.com> 2010-06-16 05:22:05 PDT --- > (In reply to comment #5) > > Also seeing random freezes here on my Thinkpad T60 on 2.6.34 with X1300 > > mobility radeon. > > Could you please also specify the exact GPU that you have ? (lspci -v), and > your kernel logs? (perhaps there is something being logged in yours?) the easy one to start with: # uname -a Linux voyager 2.6.… [View More]34-gentoo #1 SMP PREEMPT Mon May 24 10:53:46 EST 2010 i686 Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz GenuineIntel GNU/Linux # lspci -vv -s 01:0 01:00.0 VGA compatible controller: ATI Technologies Inc M52 [Mobility Radeon X1300] (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 2005 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 2000 [size=256] Region 2: Memory at ee100000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at ee120000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Kernel driver in use: radeon Kernel modules: radeon -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. [View Less]

1 0

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 16 Jun '10

16 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #6 from Da Fox <da_fox(a)mad.scientist.com> 2010-06-16 05:12:00 PDT --- I've recompiled the kernel (this time revision 8e36113082821980c60ce89a6c5d45fc9492fc26) with netconsole enabled, and have 'triggered' the freeze. At this point no errors, warnings or other messages were being printed to netconsole. Remotely logging-in via ssh was not possible. The kernel did not respond even to SysRQ-b. Netconsole output did stop when … [View More]

1 0

Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
by David Daney 16 Jun '10

16 Jun '10

On 06/15/2010 04:40 AM, Jean Delvare wrote: > Hi David, > > On Mon, 14 Jun 2010 14:28:57 -0700, David Daney wrote: >> On 06/14/2010 01:53 PM, Jean Delvare wrote: >>> Hi Justin, >>> >>> On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: >>>> could be a right solution, could be wrong >>>> here is the warning: >>>> CC drivers/i2c/i2c-core.o >>>> drivers/i2c/i2c-core.c: In function '… [View More]i2c_register_adapter': >>>> drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used >>>> >>>> Signed-off-by: Justin P. Mattock<justinmattock(a)gmail.com> >>>> >>>> --- >>>> drivers/i2c/i2c-core.c | 2 ++ >>>> 1 files changed, 2 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c >>>> index 1cca263..79c6c26 100644 >>>> --- a/drivers/i2c/i2c-core.c >>>> +++ b/drivers/i2c/i2c-core.c >>>> @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) >>>> mutex_lock(&core_lock); >>>> dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap, >>>> __process_new_adapter); >>>> + if(!dummy) >>>> + dummy = 0; >>> >>> One word: scripts/checkpatch.pl >>> >>> In other news, the above is just plain wrong. First we force people to >>> read the result of bus_for_each_drv() and then when they do and don't >>> need the value, gcc complains, so we add one more layer of useless >>> code, which developers and possibly tools will later wonder and >>> complain about? I can easily imagine that a static code analyzer would >>> spot the above code as being a potential bug. >>> >>> Let's stop this madness now please. >>> >>> Either __must_check goes away from bus_for_each_drv() and from every >>> other function which raises this problem, or we must disable that new >>> type of warning gcc 4.6.0 generates. Depends which warnings we value >>> more, as we can't sanely have both. >>> >> >> That is the crux of the whole thing. Putting in crap to get rid of the >> __must_check warning someone obviously wanted to provoke is just plain >> wrong. > > __process_new_adapter() calls i2c_do_add_adapter() which always returns > 0. Why should I check the return value of bus_for_each_drv() when I > know it will always be 0 by construction? > > Also note that the same function is also called through > bus_for_each_dev() somewhere else in i2c-core, and there is no warning > there because bus_for_each_dev() is not marked __must_check. How > consistent is this? If bus_for_each_dev() is OK without __must_check, > then I can't see why bus_for_each_drv() wouldn't be. > Well, I would advocate removing the __must_check then. David Daney [View Less]

2 1

[PATCH] drm/ttm: non pooled page allocation should have GFP_USER set
by Jerome Glisse 16 Jun '10

16 Jun '10

Non pooled page allocation should have GFP_USER set so allocation can wait and reclaim page from other process (ie non atomic). Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index ef91069..2f04757 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -… [View More]

1 0

[Bug 26852] Build libkms against in-tree xf86drm.h
by bugzilla-daemon＠freedesktop.org 16 Jun '10

16 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=26852 --- Comment #5 from Sérgio M. B. <sergio(a)sergiomb.no-ip.org> 2010-06-15 21:12:52 PDT --- What I'm try to say is, I think the ./configure of libdrm, should check what kernel version we have on system and require a version of kernel bigger than a number which libdrm, we are compiling, works. Is not logic, build libdrm-2.4.21 with a kernel <= 2.6.26 , I think. So libdrm should avoid those situations. -- Configure bugmail: https://… [View More]

1 0

[Bug 28443] New: [r300g] HoN sometimes crashes when loading
by bugzilla-daemon＠freedesktop.org 15 Jun '10

15 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=28443 Summary: [r300g] HoN sometimes crashes when loading Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: drakkk(a)centrum.cz Created an attachment (id=36140) --> (https://bugs.freedesktop.org/… [View More]attachment.cgi?id=36140) dmesg I've been experiencing this random crash for some time, but this was the first time I was able to get a backtrace. Sometimes when HoN menu or new map is loading it crash like this: Failed to allocate : size : 8388608 bytes alignment : 2048 bytes domains : 2 Program received signal SIGSEGV, Segmentation fault. get_drm_buffer (_buf=0x0) at radeon_drm_buffer.c:255 255 if (_buf->vtbl == &radeon_drm_buffer_vtbl) { Missing separate debuginfos, use: debuginfo-install glibc-2.12-2.i686 (gdb) bt #0 get_drm_buffer (_buf=0x0) at radeon_drm_buffer.c:255 #1 0x02bd7267 in radeon_drm_bufmgr_set_tiling (_buf=0x0, microtiled=R300_BUFFER_LINEAR, macrotiled=R300_BUFFER_LINEAR, pitch=8192) at radeon_drm_buffer.c:319 #2 0x02bd6392 in radeon_r300_winsys_buffer_set_tiling (rws=0x887e258, buf=0x0, pitch=8192, microtiled=R300_BUFFER_LINEAR, macrotiled=R300_BUFFER_LINEAR) at radeon_r300.c:81 #3 0x02be72fc in r300_texture_create (screen=0x887fa20, base=0xbfffdd18) at r300_texture.c:982 #4 0x02bf6eeb in r300_resource_create (screen=0x887fa20, templ=0xbfffdd18) at r300_resource.c:37 #5 0x02be7a4f in r300_texture_get_transfer (ctx=0x8932c58, texture=0xa353778, sr=..., usage=2, box=0xbfffddb8) at r300_transfer.c:157 #6 0x02db71ee in u_get_transfer_vtbl (context=0x8932c58, resource=0xa353778, sr=..., usage=PIPE_TRANSFER_WRITE, box=0xbfffddb8) at util/u_resource.c:42 #7 0x02d03586 in pipe_get_transfer (st=0x89b7340, stImage=0xa193ba8, zoffset=0, usage=PIPE_TRANSFER_WRITE, x=0, y=0, w=2048, h=1024) at ../../src/gallium/auxiliary/util/u_inlines.h:342 #8 st_texture_image_map (st=0x89b7340, stImage=0xa193ba8, zoffset=0, usage=PIPE_TRANSFER_WRITE, x=0, y=0, w=2048, h=1024) at state_tracker/st_texture.c:147 #9 0x02d4226e in st_TexImage (ctx=0x898be10, dims=2, target=3553, level=0, internalFormat=6408, width=2048, height=1024, depth=1, border=<value optimized out>, format=6408, type=5121, pixels=0x6548008, unpack=0x899abe0, texObj=0xa353558, texImage=0xa193ba8, imageSize=0, compressed_src=0 '\000') at state_tracker/st_cb_texture.c:681 #10 0x02d42c7e in st_TexImage2D (ctx=0x898be10, target=3553, level=0, internalFormat=6408, width=2048, height=1024, border=0, format=6408, type=5121, pixels=0x6548008, unpack=0x899abe0, texObj=0xa353558, texImage=0xa193ba8) at state_tracker/st_cb_texture.c:798 #11 0x02c99b0f in _mesa_TexImage2D (target=3553, level=0, internalFormat=6408, width=2048, height=1024, border=0, format=6408, type=5121, pixels=0x6548008) at main/teximage.c:2251 #12 0x07c10307 in glTexImage2D (target=3553, level=0, internalformat=6408, width=2048, height=1024, border=0, format=6408, type=5121, pixels=0x6548008) at ../../src/mesa/glapi/glapitemp.h:1002 #13 0x01f37461 in ?? () from /home/Paulie/HoN/vid_gl2-x86.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) mesa: a2817f6ae566b672f195cff22e14e2058d3617ea kernel: 2.6.33.5-112.fc13 GPU: ATI Technologies Inc M56P [Radeon Mobility X1600] (RV530) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. [View Less]

1 5

[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
by Justin P. Mattock 15 Jun '10

15 Jun '10

First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a … [View More]

11 31

[Bug 28538] New: Mesa 7.8.1 for the RV250 or Radeon 9000 is broke
by bugzilla-daemon＠freedesktop.org 15 Jun '10

15 Jun '10

https://bugs.freedesktop.org/show_bug.cgi?id=28538 Summary: Mesa 7.8.1 for the RV250 or Radeon 9000 is broke Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: brian(a)rapsure.net I've tested with two different computers in … [View More]

1 6

Re: [PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
by Justin P. Mattock 15 Jun '10

15 Jun '10

On 06/15/2010 04:38 AM, Jean Delvare wrote: > On Mon, 14 Jun 2010 13:26:47 -0700, Justin P. Mattock wrote: >> Temporary fix until something is resolved > > This is wrong by design, sorry. Warnings aren't blocking, and thus need > no "temporary fix". Such temporary fixes would be only hiding the > warning, cancelling the good work of gcc developers. Nack nack nack. > o.k. >> to fix the below warning: >> CC [M] drivers/ieee1394/sbp2.o >> drivers/… [View More]

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
24
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2010