Bug 27461

Summary: Mesa 7.8: Screen lock-ups, when drawing 3D built-in figures (probably GLUT?)
Product: Mesa Reporter: Zbigniew <zb>
Component: Drivers/DRI/r200Assignee: Default DRI bug account <dri-devel>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Code mentioned in bug-report
The requested xorg.log
My xorg.conf

Description Zbigniew 2010-04-05 05:30:47 UTC
Created attachment 34669 [details]
Code mentioned in bug-report

Noticed lock-ups (screen, keyboard "frozen") when using newest Mesa3D 7.8. Fortunately, it's easy to repeat, using attached code. The problem appears, when user wants to interact with his window manager's widgets, for example: if there's a need to start another application using WM's menu, while having window of application (the one utilizing Mesa/GLUT) still open.

How to repeat:

1. If you just compile the attached code, it'll work quite normally, and you won't notice any problems.

2. The important thing is in the renderScene function: now try to remove all the lines starting from glBegin, and ending on glEnd, then uncomment any of two commented out lines: either glutWireIcosahedron, or glutWireCube.

3. After new compilation, the application will start and behave normally. But now it's enough to click WM's "Menu" button - or workspace switching buttons on taskbar - and the screen will be "frozen" completely, keyboard unusable (fortunately, sometimes "Magis SysReq" still works), and the only way out is reset.

Using the code you can check two more things, that I'm not sure about its nature ("bug or feature?"):

4. If you choose glutWireTeapot as the corpse for displaying - instead of cube or icosahedron - you'll notice from the very start heavy CPU load.

5. If you won't register glutTimerFunc function - and you'll choose to trigger glutPostRedisplay() by placing it within any idle function, registered then using glutIdleFunc - you'll notice lockup from the very start (being GLUT-newbie I'm not sure, is it OK, maybe it's not good practice? But redisplaying in the idle time shouldn't lock the WM completely, right?).

Tested using Kernel 2.6.32.10, Glibc 2.10.1, Gobolinux 0.14 (32-bit), Mesa 7.8, Xorg 7.5, X-Server 1.7.6, IceWM 1.2.37, Pentium III/750, old mobo Intel BX-based, ATI Technologies Inc RV280 [Radeon 9200 PRO]
Comment 1 Ian Romanick 2010-04-05 13:09:26 UTC
Please don't submit zipped attachments.  Just submit the .c file and make sure the mime type is text/plain.
Comment 2 Pauli 2010-04-06 01:54:47 UTC
Sounds like 3D driver bug.

Please attach xorg.log.

Also testing with KMS enabled system would be nice.
Comment 3 Zbigniew 2010-04-06 03:50:23 UTC
Created attachment 34708 [details]
The requested xorg.log
Comment 4 Pauli 2010-04-06 05:34:13 UTC
(In reply to comment #3)
> Created an attachment (id=34708) [details]
> The requested xorg.log

Looks like you are using some possible unstable options in your xorg.conf. Can you try after commenting out all device options for radeon?
Comment 5 Zbigniew 2010-04-06 05:42:31 UTC
Created attachment 34713 [details]
My xorg.conf

No idea, which options are specific to Radeon - neither which ones have been considered unstable. Take a look at my config, then point out, what changes you recommend.

I'll try to test KMS-enabled kernel as well - but I've got to build new kernel first (not today).
Comment 6 Pauli 2010-04-06 06:12:04 UTC
> --- Comment #5 from Zbigniew <zb@jabster.pl> 2010-04-06 05:42:31 PDT ---
> Created an attachment (id=34713)
>  --> (https://bugs.freedesktop.org/attachment.cgi?id=34713)
> My xorg.conf
>
> No idea, which options are specific to Radeon - neither which ones have been
> considered unstable. Take a look at my config, then point out, what changes you
> recommend.
>

Commenting out all "Option" lines in section where the driver is set
to radeon would let driver use defaults that are considered stable for
your card.

> I'll try to test KMS-enabled kernel as well - but I've got to build new kernel
> first (not today).
>
Comment 7 Zbigniew 2010-04-06 06:28:04 UTC
When all the "Option" lines have been just cut out of my xorg.conf file (starting from: `        #Option     "NoAccel"                   # [<bool>]', and ending on (including) `        Option      "DRI"                       "True"    ', then - after restarting Xorg, and starting test proggy - although now I could use WM's menu to choose another application from there, but click on workspace switching button caused a complete freeze (even Magic SysReq was unusable).
Comment 8 Zbigniew 2010-04-06 06:40:54 UTC
I wasn't aware until now, that there are 2 different situations, while having active test proggy:

a) When I'm clicking on the IceWM's menu button, such action causes graphics lockup, but the mouse cursor can be still moved (although its move isn't smooth anymore, but in "leaps" instead - maybe heavy CPU load?), and it's still possible to use "Magic SysReq" to get out safely.

b) Clicking on any "workspace switching button" causes complete freeze - mouse cursor cannot be moved anymore, and "Magic SysReq" doesn't work.
Comment 9 Zbigniew 2010-05-26 08:49:29 UTC
(In reply to comment #2)
> Sounds like 3D driver bug.
> 
> Please attach xorg.log.
> 
> Also testing with KMS enabled system would be nice.

See my comments to bug 27464

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.