Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#8318 closed bug (fixed)

transmeta crusoe: Illegal instruction in libGL.so

Reported by: cb88 Owned by: kallisti5
Priority: blocker Milestone: R1/alpha4
Component: Kits/OpenGL Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

gcc4hybrid hrev43718 built myself not a nightly

OpenGL software rendering used to work on here now it doesn't

I have an invalid opcode exception in libGL.so when running GLTeapot

gdb says 0x00718c8e in one_time_init() from /boot/system/lib/libGL.so0

The Crusoe should support all of i586 instructions and should even work for alot of programs compiled for i686 unless they also have -O2 which can trip it up.

I would like to build haiku with the -Os flag instead of -O2 I assume I can set that in UserBuildConfig? That said I am not sure that kallisti5's mesa build script would pick up those flags or just ignore them.

I have a radeon rv100 so it can run a few little OpenGL apps so I'd like to have it working eventually even if it is weak sauce it does make some games playable instead of software rendering on Linux.

Attachments (2)

syslog (247.4 KB ) - added by cb88 8 years ago.
syslog just after running GLteapot
sysinfo (991 bytes ) - added by cb88 8 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by umccullough, 8 years ago

Owner: changed from korli to kallisti5
Status: newassigned

You might include a syslog, or at the very least the output from the commandline "sysinfo" which shows the list of CPU features supported by your processor.

My guess is that some mmx/sse opcodes are being used when they shouldn't be. I'm not sure what the gcc command looked like for kallisti's compilation of libGL.so, but it might be accidentally targeting i686 (which would be bad for Haiku's i586 minimum target).

by cb88, 8 years ago

Attachment: syslog added

syslog just after running GLteapot

by cb88, 8 years ago

Attachment: sysinfo added

comment:2 by cb88, 8 years ago

I have checked on Linux and using the swrastg_dri causes an Illegal Instruction.... when running glxgears I guess that perhaps llvm emits code it doesn't like. Glxinfo however does run with swrastg on linux.

So... swrast_dri and radeon_drr drivers work swrastg_dri does not.

comment:3 by kallisti5, 8 years ago

09:34 < umccullough> kallisti5, so you can use -mtune=i586 or -mtune=pentium
09:35 < umccullough> hopefully the mmx/sse code is in ASM
09:36 < umccullough> or, just use -mtune=generic i guess
09:36 < umccullough> but that one is ambiguous IMO
09:36 < umccullough> sounds like it targets i686
09:38 < umccullough> or, you can -march=i586 -mtune=i686 which hopefully makes compatible code that tries to optimize for 686
09:39 < umccullough> on gcc2, i think it's a little muddier
09:42 <@DeadYak> umccullough: that's precisely what it does, on gcc2 that'd be -march=pentium -mcpu=pentiumpro
09:43  * kallisti5 takes notes
09:43 <@DeadYak> -march restricts the instruction set it's allowed to use, -mcpu/-mtune tries to fine tune for that particular model and up's 
                 pipelines within the constraints of -march

comment:4 by kallisti5, 8 years ago

Milestone: R1R1/beta1
Priority: normalblocker

comment:5 by mmadia, 8 years ago

Milestone: R1/beta1R1/alpha4

comment:6 by kallisti5, 8 years ago

trying a build of mesa with the following options:

-O0 -m32 -march=i586 -mtune=i686 -mmmx -msse -msse2 -mstackrealign -mfpmath=sse

I'm not sure if this is actually going to work as it doesn't make much sense... however there is some code in mesa to do CPU instruction support checking.

Building without any sse support at all would have pretty large performance cuts for Pentium 3+ CPUs which is 99% of our users.

If this works for gcc4, I'll do the same general thing with the gcc2 mesa package.

comment:7 by kallisti5, 8 years ago

I have a confirmed fix for mesa gcc4, verifying if it's an issue in gcc2

comment:8 by kallisti5, 8 years ago

Resolution: fixed
Status: assignedclosed

gcc4 i686+ mesa package issue fixed in hrev43765

I didn't see the issue in the gcc2 build, let us know if you see any issues in gcc4 images or gcc2 images.

comment:9 by kallisti5, 8 years ago

a small note. This patch was pushed upstream to mesa in: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb3054c849d8485af53da6a61b31b5c4e4eeb95d

Patch removed from 3rdparty/mesa in hrev44242

Note: See TracTickets for help on using tickets.