#1153 closed bug (fixed)
GLTeapot crashes on AMD64x2
Reported by: | tigerdog | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Crashes at startup when both CPUs are enabled. If one CPU is disabled using Probe, GLTeapot runs fine. Enable the 2nd CPU when running and it crashes immediately.
Attachments (1)
Change History (16)
follow-up: 2 comment:1 by , 18 years ago
comment:2 by , 18 years ago
Replying to jackburton:
Can you provide a backtrace ?
Hi, My Core2Duo machine has same problem.
[Switching to team /boot/beos/demos/GLTeapot (204) thread Simon (209)] 0x009445a0 in _mesa_sse_transform_points3_3d () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer (gdb) bt #0 0x009445a0 in _mesa_sse_transform_points3_3d () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer #1 0x008b6c2c in run_vertex_stage () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer #2 0x008974f3 in _tnl_run_pipeline () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer #3 0x008c6e85 in _tnl_flush_vtx () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer #4 0x008c145b in _tnl_End () from /boot/beos/system/add-ons/opengl/Mesa Software Renderer #5 0x00207bfb in TriangleObject::DoDrawing () #6 0x002069f9 in GLObject::Draw () #7 0x00209bc7 in ObjectView::DrawFrame () #8 0x00207dff in simonThread () #9 0x005a31c0 in thread_entry () from /boot/beos/system/lib/libroot.so #10 0x70080fec in ?? ()
follow-up: 6 comment:4 by , 18 years ago
Could you test again ? Mesa has been updated since then. Thanks.
comment:5 by , 18 years ago
I don't have a AMD64x2, but it definitely still crashes on a Core Duo - as long as both CPUs are running. Same for the DirectGLTest application; obviously, our Mesa port is broken for SMP machines.
comment:6 by , 18 years ago
comment:7 by , 18 years ago
I'll retest using build from haikuhost. official build factory doesn't seem to have built any new versions since 2007-04-26.
follow-up: 10 comment:9 by , 17 years ago
comment:10 by , 17 years ago
Replying to marcusoverhagen:
Can you please retest with hrev21784 or newer? This might have been fixed by hrev21782 or hrev21784.
Tested hrev21785, do not work. I think this is Jamfile problem I pointed before. Why Haiku build accepts "-DUSE_SSE_ASM"?
comment:11 by , 17 years ago
comment:12 by , 17 years ago
This problem is fixed - thank you! Tested with nightly build from 2007-08-24. Sorry for the delay in reporting.
comment:13 by , 17 years ago
BTW, it's very interesting to watch Pulse while teapot is running, as activity periodically switches between CPUs.
follow-up: 15 comment:14 by , 17 years ago
Component: | - General → - Applications |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Thanks for testing! The scheduler problem is just how the current one works; André Braga is currently working on a replacement as part of the Google Summer of Code - and that should fix this problem, among others.
comment:15 by , 17 years ago
Replying to axeld:
Thanks for testing! The scheduler problem is just how the current one works; André Braga is currently working on a replacement as part of the Google Summer of Code - and that should fix this problem, among others.
Hum, we still need to fix SSE & like under Haiku, as NOT using those within the Mesa software renderer hit it badly. Or is only MESA usage of SSE & like that crash, while VLC use SSE without issue?
Can you provide a backtrace ?