|
Bugzilla – Full Text Bug Listing |
| Summary: | running glxinfo the first time after reboot always hangs | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Sebastien ROHAUT <sebastien.rohaut> |
| Component: | X11 3rd Party Driver | Assignee: | Jammy Zhou <atilinuxnovellbugs> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Blocker | ||
| Priority: | P5 - None | CC: | cyberorg, forgotten_egDjy87GPQ, holler, Joachim.Reichelt, ro, sebastien.rohaut |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | Top5 Bug | ||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Xorg.0.log details
xorg.conf file used with fglrx driver X11 log |
||
Created attachment 185318 [details]
xorg.conf file used with fglrx driver
Here is the answer (by mail) from Matthias Hopf : On Nov 29, 07 11:40:40 +0100, sebastien.rohaut@free.fr wrote: > It seems that /etc/X11/xdm/Xsetup in xorg-x11-7.3-24.1 has a little problem. In your case, yes, pleas open a bug report. This is serious. > if test -x $glxinfo -a -x $compiz; then > if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then > if test "$gdm" = "yes" ; then > $compiz --sm-disable decoration fade place & > if test -x $gwd ; then > $gwd --minimal & > fi > fi > fi > fi > > If I manuallay kill the glxinfo process, then kdm is lauched and then all is > working well. Thanks for analyzing. > It don't know why Xsetup waits here, because when I'm logging and opening a X > console, it works : > > seb@p64p17bicb3:/etc/X11/xdm> glxinfo | grep -q GLX_EXT_texture_from_pixmap; > echo $? > 0 This buggers me as well. I have *no* clue what is happening here. If you create an according bug report, we could assign this to ATI. You might want to check some variables and linking: echo $DISPLAY ldconfig $glxinfo in the script just before calling glxinfo. If the output differs to the one you get from the shell, this would indicate something. Alternatively, add a sleep 2 in the script before the call to glxinfo. Maybe we have a race condition here. > Another thing, it seems that this code is used only if gdm is used, not kdm, so > is it possible to modify as this to test if : Ok, this is probably the Gnome people not speaking to the KDE people and vice versa. This change sounds reasonable, but it should rather be discussed whether a) we still need compiz on login manager time anyway (this used to work around another fglrx bug) b) if we need it why don't to start it for kdm as well? > # > # Compiz > # > if test "$gdm" = "yes" ; then > if test -x $glxinfo -a -x $compiz; then > if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then > $compiz --sm-disable decoration fade place & > if test -x $gwd ; then > $gwd --minimal & > fi > fi > fi > fi Thanks Matthias Please try, what Matthias proposed =============================================================================== You might want to check some variables and linking: echo $DISPLAY ldconfig $glxinfo in the script just before calling glxinfo. If the output differs to the one you get from the shell, this would indicate something. Alternatively, add a sleep 2 in the script before the call to glxinfo. Maybe we have a race condition here. =============================================================================== Does the issue also happen after uninstalling the fglrx driver? Unfortunately I can't remember why we enabled compiz at login manager for gdm but not for kdm. I'm setting this to openSUSE 11.0, because Xorg 7.4 won't be a package of 10.3. Maybe this helps: as sebastien mentioned in comment #2 > if test -x $glxinfo -a -x $compiz; then > if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then > if test "$gdm" = "yes" ; then > $compiz --sm-disable decoration fade place & > if test -x $gwd ; then > $gwd --minimal & > fi > fi > fi > fi seems to hang booting into graphics. Killing glxinfo at this state is the trick to go on further. 1st: the first test returns 1 _if_ $glxinfo _and_ $compiz can be resolved as existing executables. if one of them are not found the insided statements will not be executed and evaluated. 2nd: if $compiz is _not_ installed this test gives 0 and $glxinfo is _not_ executed (next inner if). 3rd: that's the item for SUSE/ATI: glxinfo hangs at the first invocation after boot, you have to ^C (or kill) this first run. All other runs will run fine. As I don't use compiz on my particular hardware (9700 Mobility) I did a rpm -e compiz and then I could start my notebook into graphics. Please note: this has nothing to do with the compiz package. Just removing it leads to "-x $compiz" evaluating to 0. The crux is the first call of glxinfo. It just hangs. BUT: IMO this is an ATI/AMD issue. glxinfo with the radeon driver returns without hang. This is with fglrx 8.42 and 8.43. I can confirm this here, first time it hangs, second time it works. Alpha0 + fglrx 8.43. To the best of our knowledge AMD is working on that. *** Bug 349617 has been marked as a duplicate of this bug. *** Direct after driver install I did a startx, which is not calling /etc/X11/xdm/Xsetup". glxinfo in an xterm hang forever too Is this issue still reproducable with driver release 8.44? reopen. Still there with 8.44. Same here on SUSE 11 alpha1 and #341805 is active too! A lot of other bugs of the driver is gone here. OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON X600 Series OpenGL version string: 2.1.7170 Release starting with: ati-driver-installer-8.443.1-x86.x86_64.run Created attachment 188558 [details]
X11 log
The driver is buggy, recognizing the display!
This is a 1680x1050 DFP as given in xorg.conf, but limited to 1280x1024 by the driver(?)
I'm on DVI.
There are some black lines on top and bottom, not to the left or right.
If better, I make o new Bug of this.
Joachim, please handle different bugs in seperate bugreports, preferrably on http://ati.cchtml.com. Added bug for resolution problem. http://ati.cchtml.com/show_bug.cgi?id=939 New Top5 Bug. Hi, I've the same problem here. HP Compaq mw8440. With Radeon Mobility X1600. I do a startx from runlevel3. Then open Konsole. If i do a glxinfo, nothing happens. But if I do a glxgears before a glxinfo, glxinfo works o.k. The same is for amdcccle. Perhaps this could give you a hint ?!? regards uli Same with the latest drivers 8.45 :( What about this "very very very bad ugly" temporary hack ?
# Launch glxinfo a first time, then kill it
$glxinfo 2>/dev/null 2>&1 &
sleep 1 && kill -9 $!
# glxinfo launched a second time, it works
if test -x $glxinfo -a -x $compiz; then
if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then
if test "$gdm" = "yes" ; then
$compiz --sm-disable decoration fade place &
if test -x $gwd ; then
$gwd --minimal &
fi
fi
fi
fi
I considered such a workaround as well - given that we don't know if this issue ever gets fixed. Ok. I've added the following hack for STABLE/Factory. --- old/etc/X11/xdm/Xsetup 2007-11-09 16:47:38.000000000 +0100 +++ new/etc/X11/xdm/Xsetup 2008-01-26 11:52:57.000000000 +0100 @@ -234,8 +234,12 @@ # Compiz # if test -x $glxinfo -a -x $compiz; then - if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then - if test "$gdm" = "yes" ; then + if test "$gdm" = "yes" ; then + # when running glxinfo with fglrx driver the first time it + # hangs forever (Bug #345035) + $glxinfo &> /dev/null & + sleep 1; kill -9 $! + if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then $compiz --sm-disable decoration fade place & if test -x $gwd ; then $gwd --minimal & Fixed with Catalyst 8.2 / 8.45.5 / 8.455.2. *** Bug 346758 has been marked as a duplicate of this bug. *** |
Created attachment 185317 [details] Xorg.0.log details Hi, Due to a mail exchange between Matthias Hopf and me here is a bug report. I'm using your Xorg74 experimental repository (from Stefan Dirsch) for Opensuse 10.3 to test your lastest packages. I put Severity to Blocker because of this bug xdm/kdm/gdm is not launched and users can't connect. It seems that /etc/X11/xdm/Xsetup in xorg-x11-7.3-24.1 has a "little" problem. I'm using the lastest flgrx ATI driver (8.43.2) on a ATI RADEON XPRESS 200M (II) fglrx(0): VESA VBE OEM: ATI RADEON XPRESS 200 Series (II) fglrx(0): VESA VBE OEM Software Rev: 1.0 (II) fglrx(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) fglrx(0): VESA VBE OEM Product: RS48 (II) fglrx(0): VESA VBE OEM Product Rev: 01.00 and when I start X11, it stops loading just before launching xdm or other graphical session manager (in fact kdm for me). Under a console (Ctrl+Alt+F1), I can see two process : glxinfo grep -q GLX_EXT_texture_from_pixmap launched by Xsetup, especially here, line 233-245 : if test -x $glxinfo -a -x $compiz; then if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then if test "$gdm" = "yes" ; then $compiz --sm-disable decoration fade place & if test -x $gwd ; then $gwd --minimal & fi fi fi fi If I manually kill glxinfo kdm/xdm/gdm is launched and all is working well. It don't know why theses instructions are not working here, because when I'm logging and opening a X console (xterm, kconsole), it works : seb@p64p17bicb3:/etc/X11/xdm> glxinfo | grep -q GLX_EXT_texture_from_pixmap echo $? 0 Another thing, it seems that this code is used only if gdm is used, not kdm, so it is possible to modify as this to test it (it works for me because I use KDE) : # # Compiz # if test "$gdm" = "yes" ; then if test -x $glxinfo -a -x $compiz; then if $glxinfo | grep -q GLX_EXT_texture_from_pixmap ; then $compiz --sm-disable decoration fade place & if test -x $gwd ; then $gwd --minimal & fi fi fi fi Last : This problem occurs on my professional desktop computer (with ATI). At home, with the same Xorg release and a Nvidia card (with the lastest commercial nvidia driver), it works perfectly. It seems it's an issue with this release of Xorg and the use of fglrx driver. I will make some additional tests tomorrow at work as described by Matthias Hopf in his answer (in the next comment). I also have a notebook (HP NC6000) with Radeon 9600, I will upgrade it to this bugging release of Xorg and fglrx driver to see if I have the same problem.