Summary: | wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4 | ||
---|---|---|---|
Product: | Mesa | Reporter: | Andrew Randrianasulu <randrik> |
Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
glxinfo
X log last 350 lines from /var/log/messages dmesg from 2.6.39-rc5+ with additional debug in r300.c stderr log with export RADEON_DEBUG=draw, bz2 compressed more debug in dmesg |
Description
Andrew Randrianasulu
2011-05-01 09:19:44 UTC
Created attachment 46223 [details]
glxinfo
Created attachment 46224 [details]
X log
Created attachment 46225 [details]
last 350 lines from /var/log/messages
Currently I use zram module, it may interfere with ttm/drm memory management, but for me "Buffer too small for color buffer 0" sounds like buffer in VRAM ... but I can unload it, or disable color tiling/pageflip for testing, if needed. This machine much faster (compared to celeron-400), but I ran this test for first time on it, so I can't say if it was regression or not. Disabling colortiling and/or pageflips has no effect on this bug. Also changing texture mode in 3Dmark itself from default "compressed" to 32-bit does nothing. Bug still here with 2.6.39-rc5+ (3fd9952) Created attachment 46266 [details]
dmesg from 2.6.39-rc5+ with additional debug in r300.c
I've just added some DRM_ERROR in function r300_packet3_check, like this:
case PACKET3_3D_DRAW_INDX_2:
track->vap_vf_cntl = radeon_get_ib_value(p, idx);
r = r100_cs_track_check(p->rdev, track);
if (r) {
DRM_ERROR("Error from packet3_draw_indx_2!\n");
return r;
}
break;
because r100_cs_track_check clearly reported wrong track->cb[i].cpp
Created attachment 46268 [details]
stderr log with export RADEON_DEBUG=draw, bz2 compressed
Can you print track->num_arrays when this happens? I suspect track->arrays[] may be overflowing and clobbering track->cb[]. Created attachment 46284 [details]
more debug in dmesg
I've added DRM_ERROR("[drm] num_arrays, %u\n", track->num_arrays); into r100_cs_track_check(), but it prints just "3"
Hm, just tested 2.6.37 - it is free from this bug! (In reply to comment #11) > Hm, just tested 2.6.37 - it is free from this bug! Can you bisect? (In reply to comment #12) > (In reply to comment #11) > > Hm, just tested 2.6.37 - it is free from this bug! > > Can you bisect? Incomplete log: guest@slax:~/src/linux-bisect$ git bisect log git bisect start # good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37 git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5 # bad: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38 git bisect bad 521cb40b0c44418a4fd36dc633f575813d59a43d # good: [5943a268002fce97885f2ca08827ff1b0312068c] Merge branch 'timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good 5943a268002fce97885f2ca08827ff1b0312068c # good: [7d209c8110ecd49db46da786437485e8ef67f414] alpha: kill off alpha_do_IRQ git bisect good 7d209c8110ecd49db46da786437485e8ef67f414 # good: [78d2978874e4e10e97dfd4fd79db45bdc0748550] CRED: Fix kernel panic upon security_file_alloc() failure. git bisect good 78d2978874e4e10e97dfd4fd79db45bdc0748550 # bad: [c486da34390846b430896a407b47f0cea3a4189c] sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush git bisect bad c486da34390846b430896a407b47f0cea3a4189c # skip: [68c3d4b26623e92656588061405d9dbdf97c0706] Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging git bisect skip 68c3d4b26623e92656588061405d9dbdf97c0706 [skip because X was unstartable with this kernel - hang] guest@slax:~/src/linux-bisect$ git bisect bad 501834349e872ed4115eea3beef65ca9eeb5528e is the first bad commit commit 501834349e872ed4115eea3beef65ca9eeb5528e Author: Marek OlЕЎГЎk <maraeo@gmail.com> Date: Mon Feb 14 01:01:09 2011 +0100 drm/radeon/kms: fix tracking of BLENDCNTL, COLOR_CHANNEL_MASK, and GB_Z on r300 Also move ZB_DEPTHCLEARVALUE to the list of safe regs. Signed-off-by: Marek OlЕЎГЎk <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> :040000 040000 63bb0565c7887abb72f93967caea0606d028df09 c3a86a556f8c4ee1313bdc12e1f86cb44bacb742 M drivers Andrew, could you please make an OpenGL trace file using apitrace? Get it here: https://github.com/apitrace/apitrace Compile it using cmake, then run something like: TRACE_FILE=/home/..user../3dmark.trace LD_PRELOAD=/path-to-apitrace/glxtrace.so ./executable where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me. That will capture all the 3D commands and I can replay it here. (In reply to comment #15) > Andrew, > > could you please make an OpenGL trace file using apitrace? > > Get it here: > https://github.com/apitrace/apitrace > > Compile it using cmake, then run something like: > > TRACE_FILE=/home/..user../3dmark.trace LD_PRELOAD=/path-to-apitrace/glxtrace.so > ./executable > > where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me. > > That will capture all the 3D commands and I can replay it here. file is 37M big (bz2 compressed) (In reply to comment #16) > (In reply to comment #15) > > Andrew, > > > > could you please make an OpenGL trace file using apitrace? > > > > Get it here: > > https://github.com/apitrace/apitrace > > > > Compile it using cmake, then run something like: > > > > TRACE_FILE=/home/..user../3dmark.trace LD_PRELOAD=/path-to-apitrace/glxtrace.so > > ./executable > > > > where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me. > > > > That will capture all the 3D commands and I can replay it here. > > file is 37M big (bz2 compressed) https://rapidshare.com/files/1581552170/3dmark.trace.gz Thanks for the trace. The fix is here: http://lists.freedesktop.org/archives/dri-devel/2011-June/011985.html (In reply to comment #9) > Can you print track->num_arrays when this happens? I suspect track->arrays[] > may be overflowing and clobbering track->cb[]. You were right. (In reply to comment #18) > Thanks for the trace. > > The fix is here: > http://lists.freedesktop.org/archives/dri-devel/2011-June/011985.html > > > (In reply to comment #9) > > Can you print track->num_arrays when this happens? I suspect track->arrays[] > > may be overflowing and clobbering track->cb[]. > > You were right. Yes, confired fixed. I'll wait until fix land into mainline (Linus's 2.6 master - actually 3.0.0-rc at the moment .... should one rename all git trees too? Heh.) and hopefully will mark this closed (after re-testing). Fixed in mainline kernel (3.0.0-rc3+) A patch referencing this bug report has been merged in Linux v3.0-rc4: commit a27bb4b209dd6c327fa4e7185f2487f9508a58db Author: Marek Olšák <maraeo@gmail.com> Date: Fri Jun 10 14:41:26 2011 +0000 drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.