Bug 7372 - super maryo chronicles crashes traceback is deep in r300_dri.so
Summary: super maryo chronicles crashes traceback is deep in r300_dri.so
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: 6.5
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2006-06-30 03:03 UTC by Hans de Goede
Modified: 2006-08-03 01:19 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2006-06-30 03:03:34 UTC
I friend has been so kind to donate me a radeon 9800 so now I'm giving this card
a spin with the new opensource r300 dri support.

I've just tried SMC: http://www.secretmaryo.org/ and it segfaults. Doing a
traceback on the core shows that the crash happens deep in r300_dri.so.

Depending on what distro your on SMC is a bit of a pain to compile, because it
needs CEGUI. I've been involved in packaging cegui for Fedora and it is
available for fedora from fedora-extras. For other distros I don't know what the
situation is.

You can get CEGUI from here:
CEGUI contains a couple of bugs, 1 if not using xcerces, another when running on
64 bit, I've put the patches we use in fedora for this here for you:

CEGUI in turn needs DevIL:
Which also contains a few bugs, patches once again are here:

Once you've got CEGUI compiled and installed, you need todo the following to get
SMC 0.98.1 to compile:
chmod +x autogen.sh configure
./configure ...... continue as usual

I'm running a fully up2date Fedora development branch (rawhide) x86_64 system.
So I've got pretty much the latest version of everything.

I'm a skilled C programmer and have a bachelor in electronics. I've written a
few kernel drivers and lots of userland code. I'm however totaly at loss when it
comes where to begin with debugging OpenGL / dri problems.

Please let me know what I can do to help debug this, compiling CVS versions
adding printf running it through a debugger etc, should all not be a problem.

Here is a traceback of the crash with mesa-debuginfo installed to also get you
the line numbers where things are happening:
#0  0x00002aaaaf5b01c1 in _swrast_choose_texture_sample_func (ctx=0x6431c0, 
    t=0xbf2080) at swrast/s_texfilter.c:2649
#1  0x00002aaaaf583887 in _swrast_update_texture_samplers (ctx=0x6431c0)
    at swrast/s_context.c:504
#2  0x00002aaaaf58398b in _swrast_validate_derived (ctx=0x6431c0)
    at swrast/s_context.c:535
#3  0x00002aaaaf5830ef in _swrast_validate_triangle (ctx=0x6431c0, 
    v0=0x2aaab8275020, v1=0x2aaab82750c4, v2=0x2aaab8275168)
    at swrast/s_context.c:297
#4  0x00002aaaaf583a6d in _swrast_Triangle (ctx=0x6431c0, v0=0x2aaab8275020, 
    v1=0x2aaab82750c4, v2=0x2aaab8275168) at swrast/s_context.c:576
#5  0x00002aaaaf5da95d in triangle_rgba (ctx=0x6431c0, e0=0, e1=1, e2=2)
    at swrast_setup/ss_tritmp.h:159
#6  0x00002aaaaf539cc4 in _tnl_render_triangles_verts (ctx=0x6431c0, start=0, 
    count=60, flags=52) at tnl/t_vb_rendertmp.h:163
#7  0x00002aaaaf53bcb5 in run_render (ctx=0x6431c0, stage=0x7dfcb0)
    at tnl/t_vb_render.c:319
#8  0x00002aaaaf51f274 in _tnl_run_pipeline (ctx=0x6431c0)
    at tnl/t_pipeline.c:162
#9  0x00002aaaaf51d553 in _tnl_DrawArrays (mode=4, start=0, count=60)
    at tnl/t_array_api.c:250
#10 0x00002aaaaf50eaee in neutral_DrawArrays (mode=4, start=0, count=60)
    at main/vtxfmt_tmp.h:334
#11 0x00002aaaaf4428d6 in radeonDrawArrays (mode=4, start=0, count=60)
    at radeon_vtxfmt_a.c:599
#12 0x00002aaaaf50eaee in neutral_DrawArrays (mode=4, start=0, count=60)
    at main/vtxfmt_tmp.h:334
#13 0x00002aaaab8d85ec in CEGUI::OpenGLRenderer::renderVBuffer ()
   from /usr/lib64/libCEGUIOpenGLRenderer.so.0
#14 0x00002aaaab8d89ca in CEGUI::OpenGLRenderer::doRender ()
   from /usr/lib64/libCEGUIOpenGLRenderer.so.0
#15 0x00002aaaab563e54 in CEGUI::System::renderGUI ()
   from /usr/lib64/libCEGUIBase.so.0
#16 0x00000000004a92ce in DrawLoadingScreen () at video/video.cpp:1300
#17 0x000000000040e893 in InitGame () at main.cpp:99
#18 0x000000000040fa59 in main (argc=1, argv=0x7fff90accae8) at main.cpp:43
Comment 1 Jerome Glisse 2006-06-30 04:25:46 UTC
Seems the crash happens in mesa swrast (software rasteriser) not in r300. 
What is the exact version of mesa you using ? Could you try with cvs version. 
Comment 2 Hans de Goede 2006-06-30 04:36:35 UTC
AFAIK my version is 6.5 with a few patches:
[hans@shalem ~]$ rpm -q mesa-libGL --changelog
* Tue Jun 13 2006 Kristian Høgsberg <krh@redhat.com> - 6.5-9
- Add mesa-6.5-fix-pbuffer-dispatch.patch to fix pbuffer marshalling code.

* Tue May 30 2006 Kristian Høgsberg <krh@redhat.com> 6.5-8
- Bump for rawhide build.

* Tue May 30 2006 Kristian Høgsberg <krh@redhat.com> 6.5-7
- Update mesa-6.5-texture-from-pixmap-fixes.patch to include new
  tokens and change tfp functions to return void.  Yes, a new mesa
  snapshot would be nice.

* Thu May 18 2006 Mike A. Harris <mharris@redhat.com> 6.5-6
- Add "BuildRequires: makedepend" for bug (#191967)

* Wed Apr 12 2006 Kristian Høgsberg <krh@redhat.com> 6.5-5
- Bump for fc5 build.

* Wed Apr 12 2006 Adam Jackson <ajackson@redhat.com> 6.5-4
- Disable R300_FORCE_R300 hack for wider testing.

* Tue Apr 11 2006 Kristian Høgsberg <krh@redhat.com> 6.5-3
- Add mesa-6.5-noexecstack.patch to prevent assembly files from making
* Tue Apr 11 2006 Kristian Høgsberg <krh@redhat.com> 6.5-2
- Bump for fc5 build.
- Bump libdrm requires to 2.0.1.

* Sun Apr 02 2006 Kristian Høgsberg <krh@redhat.com> 6.5-1
- Update to mesa 6.5 snapshot.
- Use -MG for generating deps and some files aren't yet symlinked at
  make depend time.
- Drop mesa-6.4.2-dprintf-to-debugprintf-for-bug180122.patch and
  as these are upstream now.
- Drop mesa-6.4.1-texture-from-drawable.patch and add
- Update mesa-modular-dri-dir.patch to apply.
- Widen libGLU glob.
- Reenable r300 driver install.
- Widen libOSMesa glob.
- Go back to patching config/linux-dri, add mesa-6.5-build-config.patch,
  drop mesa-6.3.2-build-configuration-v4.patch.
- Disable sis dri driver for now, only builds on x86 and x86-64.

I'll give mesa CVS a try.
Comment 3 Hans de Goede 2006-06-30 06:03:22 UTC
I've tried to use CVS, but it currently won't compile:
r200_state_init.c: In function 'cmdveclinear':
r200_state_init.c:102: error: 'drm_radeon_cmd_header_t' has no member named
r200_state_init.c:102: error: 'RADEON_CMD_VECLINEAR' undeclared (first use in
this function)
r200_state_init.c:102: error: (Each undeclared identifier is reported only once
r200_state_init.c:102: error: for each function it appears in.)
r200_state_init.c:103: error: 'drm_radeon_cmd_header_t' has no member named
r200_state_init.c:104: error: 'drm_radeon_cmd_header_t' has no member named
r200_state_init.c:105: error: 'drm_radeon_cmd_header_t' has no member named
r200_state_init.c: In function 'r200InitState':
r200_state_init.c:460: error: 'R200_EMIT_VAP_PVS_CNTL' undeclared (first use in
this function)
make[6]: *** [r200_state_init.o] Error 1

These errors are thrown when compiling: src/mesa/drivers/dri/r200/r200_state_init.c
Comment 4 Jerome Glisse 2006-06-30 09:11:25 UTC
You need a newer libdrm use drm from cvs or try to update the package of your
distribution and see if it compile.
Comment 5 Hans de Goede 2006-06-30 12:45:02 UTC
Thanks for the libdrm hint, with that CVS does compile.

However CVS isn't exactly stable. Thats an understatement! With CVS mesa SMC
does run but terible slow while no software fallback messages are printed.

I tried to run glxgears after SMC to see if DRI was still operational and my
system froze.

After a reboot I ran glxgears again and it worked, but it was choppy it did less
fps then usual (1500 with the 5.6 snapshot it does 2800) and the turning of the
wheels wasn't smooth.

Then I ran ppracer and that resulted in another hard crash, more about that in
my ppracer bug.
Comment 6 Hans de Goede 2006-08-02 13:29:14 UTC
Good News! I've just tried smc again with the latest CVS, which I installed to
confirm that bug 7371 is fixed. With current cvs smc works, albeit still very
slow (software fallback), but now it does print a fallback message, the problem
is smooth lines, just like with google earth. By commenting the fallback in case
of smoothlines in r300_renderer.c I get descent performance with smc.

Very well done, keep up the good work!

This bug can be closed as far as I'm concerned.

Comment 7 Jerome Glisse 2006-08-03 01:19:41 UTC
Close the bug...

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.