Am 2002.12.10 11:59:13 +0100 schrieb(en) Felix Kühling:
On Tue, 10 Dec 2002 10:37:07 +0000
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Charl P. Botha wrote:
....
> > Okay, I just checked and I can still reproduce a SIGFPE with
today's CVS.
> > I've made doubly sure that the new libGL is used. Here is a
backtrace:
> >
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x4246fe4a in _mesa_sse_transform_points3_general ()
> > from /usr/X11R6/lib/modules/dri/radeon_dri.so
> > (gdb) bt
> > #0 0x4246fe4a in _mesa_sse_transform_points3_general ()
> > from /usr/X11R6/lib/modules/dri/radeon_dri.so
> > #1 0x0840b6a0 in ?? ()
> > #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0,
stage=0x840b174)
> > at t_vb_vertex.c:286
> > #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at
t_pipeline.c:154
> > #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at
radeon_state.c:2089
> > #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0,
IM=0x8411f60)
> > at t_imm_exec.c:399
> > #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0,
IM=0x8411f60)
> > at t_imm_exec.c:424
> > #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0,
IM=0x8411f60)
> > at t_imm_exec.c:493
> > #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60)
> > at t_imm_api.c:77
> > #9 0x4241e5f1 in _tnl_Vertex3f (x=39.2000008, y=46.7999992,
z=17)
> > at t_imm_api.c:834
> > #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c,
octantIdx=@0xbfffe657,
> > y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0,
ambient=@0xbfffe660,
> > diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0)
> > at
/home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113
> >
> > DrawVoxelSplat is simply rendering oodles and oodles of textured
quads. Any
> > ideas?
>
> It looks like a new/different problem to the one fixed earlier.
It's tempting
> to say it's a bug in the assembly, but otoh that code has been
pretty widely
> used without change over the last couple of years.
>
> It may be a result of the new gcc's ability to put sse, mmx into
normal code -
> this has bitten us a couple of times.
As far as I can tell it is a bug in gcc if you get mmx instructions
in
normal output. It would break the kernel. As a test I once compiled
my
kernel with gcc-3.2 -S and grepped for "%mm". All I found was some
inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1)
problems
is to compile with -mno-mmx -mno-3dnow.
The use of SSE for normal floating point operations is another
thing,
though. But according to gcc-3.2 docs -mfpmath=387 should be the
default.
>
> The debugger should be able to show you the assembly instruction
on which this
> fails. 'disassemble' is the command. 'info regs' will show the
contents of
> the registers at this point.
>
> Basically it's standard debugging: What went wrong, why?
>
> Keith
Felix
I get the same sigfpe exception as Charls,
using gcc 2.95.3 (suse 7.3), kernel 2.4.20,
when disabling TCL and running xmms with plugins and
with other apps its maybe the same...
also the backtrace is the same til step #9
HW: Radeon7500, sis745, AthlonXP1700+
Just to clarify: The SIGFPE occurs when SSE
is enabled and TCL disabled,
disabling only VTXFMT doesnt trigger
that bug I think (now).
Andreas
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
