Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 Description of problem: On this Sony Vaio FX-705 with an Ati Rage Mobility P/M AGP 2x rev 64 X does not work. All I get is a big white box on the top left corner and the rest of the screen is a flickering white/black area. Neither Xconfigurator or [X -configure] helped. The card works with X under FB [e.g. in the 7.3 installer] but doesn't in limbo [graphical installer included] Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Xconfigurator [or X -configure or graphical install] 2. startx [or X] 3. Actual Results: The messed up screen as described above Expected Results: The usual usable screen :) Additional info: Am attaching the relevant config files
Created attachment 67584 [details] X configuration as set up by Xconfigurator
Created attachment 67585 [details] XFree86.0.log
Created attachment 67586 [details] lspci -vn
Just to try to cut down the possibilities: The card works fine using the 4.1.0 xfree packages found in debian woody and also the 4.2.0 experimental packages for debian. So it could be either a non official fix in their packages that fixes something or some other RH specific patch that causes problems. I hopefully will be able to try XFree86 cvs in a couple of days
Just tried out XFree86 from CVS [compiled with gcc3.1] and I get the same problem. Seems more like a regression in the newer XFree86 versions then
tried the xf-4_1_0 branch and it works ok
Slowly getting to the matter of things I guess.. XFree86 HEAD Cvs works fine if compiled with an older compiler [2.95.4] It doesn't if compiled with gcc-3.1
What about if it is compiled with our gcc 2.96?
Just finished trying and yes the problem persists with XFree4.2 HEAD compiled with gcc-2.96-112. Was compiled on a clean 7.3 fully updated.
I am officially on crack. Had the wrong gcc in PATH... All versions I tried of XFree [xf-4_1_0, xf-4_2_0, HEAD] work fine on the Rage Mobility P/M when compiled with gcc 2.95.x or gcc 2.96-112. The problem appears with the gcc-3.x shipped in limbo. I just tried the second release of limbo and the problem is still there [graphical install included] So I assume problems appeared with gcc-3.1.something Sorry about my misleading comment before
Very weird. sct has mentioned a problem which went away on Mach64 with the latest build. It is possible there is/was a gcc bug which is now fixed. I'll have to chuck a Mach64 into a machine and pound on it with the lastest stuff soon.
Just did a minimal limbo2 install. Updated gcc and its dependencies Recreated the Xfree86 rpms and it works again. Everythin appears to fine. Just the initial X background is completely black instead of gray/black dots but the rest seems fine so far. So gcc-3.2-0.3 did the trick for me here. For the record : [btw. a BuildRequires: libtool, XFree86-devel is needed since xmkmf is used in the process and since libtool is used by ttmkfdir2]. I also had to switch two lines in the main Makefile to get it to compile : --- XFree86-4.2.0/xc/Makefile.orig 2002-08-12 10:30:28.000000000 -0400 +++ XFree86-4.2.0/xc/Makefile 2002-08-12 10:30:46.000000000 -0400 @@ -74,8 +74,8 @@ $(MAKE_CMD) $(MFLAGS) version.def $(MAKE_CMD) $(MFLAGS) Makefiles $(MAKE_CMD) $(MFLAGS) BOOTSTRAPSUBDIRS= clean - cd $(CONFIGSRC)/pswrap && $(MAKE) pswrap $(MAKE_CMD) $(MFLAGS) includes + cd $(CONFIGSRC)/pswrap && $(MAKE) pswrap $(MAKE) -C $(CONFIGSRC)/util gccmakedep $(MAKE_CMD) $(MFLAGS) depend $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World
closing since it appears to work ok now
Reopening bug report... bug reporter was sniffing glue when closing report... problem still exists. ;o) /me runs from michele
Ok. Glue quality has gone pretty bad these days..so I feel excused. So it happened that while switching gcc's for testing I had also rebooted with kernel in fb console..which was the real trick to the problem. So : - Kernel in fb console --> X works fine - Kernel in normale text mode --> Boom I'll leave it open, since this is a bit of a kludge but it works nonetheles
Michele, have you tried my 4.2.1 packages on p.r.c, or our latest phoebe beta, or my XFree86 CVS RPMs? I'm having Mach64 problems myself now that weren't in 4.2.0 or 4.2.1, and wondering if others are hit also.
Just gave Phoebe a spin. Exact same problems persist. Unusable screen, blanking white rectangle in the top left corner and black background. Booting with fb enabled fixes it. Mike, feel free to let me know if you need me to try out anything else
Try attaching this to the external monitor and booting the box with that, then switching to the internal display. I searched around to try to find anyone else having this problem, and I found one report on my google query that had similar info. Booting of external monitor seemed to work around for this person. Worth a shot. Lemme know if that helps at all.
Just gave Xfree86-4.3.0 a spin (compiled from scratch though) and apparently it is fixed (i.e. X can start safely without being in framebuffer). I'll leave the bug open until I can confirm it working on 8.1 (or whatever it'll be called ;) and eventually close it afterwards
Ok, closing the bug. All's fine with RH9/XF4.3 (Assuming Currentrelease is the right resolution here..)
Thanks Michele.