Bug 54147

Summary: ATI Mach64 dropped from 16bpp to 8bpp with 4.0 server
Product: [Retired] Red Hat Linux Reporter: wdc
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: wdc
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-03-12 19:56:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The X server log indicating the failure
none
XF86Config-4 file with the failed configuration.
none
R3 config file that works fine. (Is in use at this moment.) none

Description wdc 2001-09-28 16:24:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913

Description of problem:
When I upgraded to RehHat 7.1, the default XFree86 4.0.3 refused to
give me the 1280x1024x16 that worked just fine under XFree86 3.
As the enclosure shows, the server thinks thta 8 bits is the most that
the hardware supports.

I've worked around this by doing the Xconfigurator --preferxf3 thing,
but I felt it my duty to report the problem.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.set anything other than 8 bit color in Xconfigurator.
2.start X (on my hardware.)
3.watch X fail to start
	

Additional info:

Comment 1 wdc 2001-09-28 16:28:09 UTC
Created attachment 32898 [details]
The X server log indicating the failure

Comment 2 wdc 2001-09-28 16:30:48 UTC
Created attachment 32899 [details]
XF86Config-4 file with the failed configuration.

Comment 3 wdc 2001-09-28 16:32:17 UTC
Created attachment 32900 [details]
R3 config file that works fine.  (Is in use at this moment.)

Comment 4 Mike A. Harris 2001-10-01 12:26:34 UTC
Your log shows the following:

(II) ATI:  Shared PCI Mach64 in slot 0:20:0 with sparse PIO base 0x02EC etected.
(II) ATI:  VGA Wonder at I/O port 0x01CE detected.
(II) ATI:  Shared PCI Mach64 in slot 0:20:0 assigned to active "Device" section
"ATI Mach64".
[snip]
(WW) Registering the following despite conflicts with estimated resources:
	[0] 0	0x000001ce - 0x0000f3fe  IS[S]

It appears you have multiple video adaptors in your system, possibly
conflicting.  Do you have a PCI card, and also an ISA or onboard video?
or even a VLB card?  Also, how much RAM is on the card?

Comment 5 wdc 2001-10-01 15:39:11 UTC
Interesting.

The motherboard is a SuperMicro SBA370, with no on-board video.
It has an AGP slot, but it's unused. 

I have a WinTV card in the system, but it's an input-only device.

No Vesa-Local bus on the motherboard.
No ISA video.

There is only the single VGA connector coming out of my ATI Card.
For the record it's a "Graphics Pro Turbo" card.
I see in the manual that it has two video port addressing modes: Fixed  I/O and
relocatable I/O. I believe the card offered a maximum of 4 Mb of VRAM, and
that's how much I have.

Resolution I've gotten from this card in the past is consistent with 
having 4 Mb:  1280x1024x16, and under Windos 1280x1024x24.  (The XFree86 
version 3 Mach64 did not support packed byte mode so it couldn't do
1280x1024x24.  I dimly remember experimenting with 1024x768x32 and deciding to
configure consistently on both the win95 boot and the Linux boot at 1280x1024.
16bpp under Linux and 24bpp under windows.

If I were to guess, I'd say the X Server is either double detecting the card
because of some inadvertent fall-through in the code, or that the Fixed
and Relocatable I/O is screwing us up.

If it is the latter, then I suggest the driver be changed to use Relocatable I/O
and to not try and find the fixed locations after that.  According to the
manual, the Fixed I/O video ports include 0x2e8-0x2ef which are normally used by
COM4.  The Relocatable I/O eliminates conflicts with COM4.


Comment 6 wdc 2001-10-12 03:54:53 UTC
Is there more I can do to help move this bug to resolution?
Is trying 4.1.0 recommended?


Comment 7 Mike A. Harris 2002-03-12 19:56:02 UTC
I can't reproduce this problem on any of 4 Mach64 cards I have tried, so
it almost certainly is specific to your exact hardware combination.

If you havent already, I recommend upgrading to 4.1.0-15 that we have
released as erratum.

Comment 8 Mike A. Harris 2002-07-30 01:59:11 UTC
All my Mach64 hardware works fine in current rawhide.  I've tested it
with a variety of resolutions.  There are also new Mach64 bugfix
patches present in rawhide.