| Summary: | Mesa 7.8: Screen lock-ups, when drawing 3D built-in figures (probably GLUT?) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Zbigniew <zb> |
| Component: | Drivers/DRI/r200 | Assignee: | 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 |
||
Please don't submit zipped attachments. Just submit the .c file and make sure the mime type is text/plain. Sounds like 3D driver bug. Please attach xorg.log. Also testing with KMS enabled system would be nice. Created attachment 34708 [details]
The requested xorg.log
(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? 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 #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). > 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). 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. (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.
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]