Bug 70073 - Rage Mobiliy P/M rev 64 not working
Summary: Rage Mobiliy P/M rev 64 not working
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 79579 82779
TreeView+ depends on / blocked
 
Reported: 2002-07-30 00:01 UTC by Michele Baldessari
Modified: 2007-04-18 16:44 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-01 09:34:42 UTC
Embargoed:


Attachments (Terms of Use)
X configuration as set up by Xconfigurator (3.28 KB, text/plain)
2002-07-30 00:08 UTC, Michele Baldessari
no flags Details
XFree86.0.log (28.09 KB, text/plain)
2002-07-30 00:08 UTC, Michele Baldessari
no flags Details
lspci -vn (3.48 KB, text/plain)
2002-07-30 00:09 UTC, Michele Baldessari
no flags Details

Description Michele Baldessari 2002-07-30 00:01:58 UTC
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

Comment 1 Michele Baldessari 2002-07-30 00:08:01 UTC
Created attachment 67584 [details]
X configuration as set up by Xconfigurator

Comment 2 Michele Baldessari 2002-07-30 00:08:44 UTC
Created attachment 67585 [details]
XFree86.0.log

Comment 3 Michele Baldessari 2002-07-30 00:09:45 UTC
Created attachment 67586 [details]
lspci -vn

Comment 4 Michele Baldessari 2002-07-30 20:35:33 UTC
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

Comment 5 Michele Baldessari 2002-08-02 12:43:08 UTC
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

Comment 6 Michele Baldessari 2002-08-04 15:15:58 UTC
tried the xf-4_1_0 branch and it works ok

Comment 7 Michele Baldessari 2002-08-05 16:30:35 UTC
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

Comment 8 Mike A. Harris 2002-08-06 07:38:37 UTC
What about if it is compiled with our gcc 2.96?

Comment 9 Michele Baldessari 2002-08-06 17:46:37 UTC
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.

Comment 10 Michele Baldessari 2002-08-07 13:29:27 UTC
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

Comment 11 Mike A. Harris 2002-08-09 20:57:21 UTC
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.

Comment 12 Michele Baldessari 2002-08-12 18:43:55 UTC
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

Comment 13 Michele Baldessari 2002-08-12 18:45:27 UTC
closing since it appears to work ok now

Comment 14 Mike A. Harris 2002-10-16 23:07:02 UTC
Reopening bug report...  bug reporter was sniffing glue when closing
report... problem still exists.  ;o)

/me runs from michele

Comment 15 Michele Baldessari 2002-10-18 11:27:37 UTC
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

Comment 16 Mike A. Harris 2002-12-30 10:05:15 UTC
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.

Comment 17 Michele Baldessari 2003-01-15 19:21:31 UTC
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 

Comment 18 Mike A. Harris 2003-02-20 03:52:28 UTC
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.

Comment 19 Michele Baldessari 2003-03-02 13:03:34 UTC
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

Comment 20 Michele Baldessari 2003-04-01 09:34:42 UTC
Ok, closing the bug. All's fine with RH9/XF4.3
(Assuming Currentrelease is the right resolution here..)

Comment 21 Mike A. Harris 2003-04-01 12:10:59 UTC
Thanks Michele.


Note You need to log in before you can comment on or make changes to this bug.