Bug 50732

Summary:	console color listing is muted after running X
Product:	[Retired] Red Hat Linux	Reporter:	Mike Vaillancourt <mikev>
Component:	XFree86	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED WONTFIX	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	mharris
Target Milestone:	---
Target Release:	---
Hardware:	ia64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-06-06 16:54:03 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:

Description Mike Vaillancourt 2001-08-02 17:41:01 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686)

Description of problem:
On a IA64 machine using a Quadro2-Pro video card, only after running X
windows, any color text is very dark, almost totally unreadable.

How reproducible:
Always

Steps to Reproduce:
1. boot system
2. startx
3. log out of x
4. do a "ls" with dirs. The blue will be very dark
	

Actual Results:  should be able to read all the listings.

Additional info:

I have the video card here if needed for testing.

Comment 1 Arjan van de Ven 2001-08-02 17:58:15 UTC

Mike: do you remember if X is supposed to restore the palette or was that the
kernel ?

Comment 2 Mike A. Harris 2001-08-09 19:16:47 UTC

Sorry for the delay.. just spotted this bug..  Yes, XFree86 drivers
handle palette setting when not using FBDev, etc..
Probably a bug in the nv driver palette setting code.  Can you test
this same card on a regular x86 box to see if it is a 64bitism?

Comment 3 Mike A. Harris 2001-08-09 19:32:29 UTC

Mike, please attach your X server log and config file for this card from
when it is failing so I can analyze the output.  I found some strange
looking bits in the NV driver that look like it might have been
cut and paste error, but no sense playing with it until I know
what video mode, yada yada.  If it is 16bit mode I have an idea..

Comment 4 Mike A. Harris 2001-08-09 22:18:15 UTC

I asked upstream with Mark Vojkovich and here is the information
he provided.  This might help track the problem down.


> With the nv driver, there seems to be a palette handling problem
> when switching from X to the console on ia64 hardware with
> geforce2.  I am trying to get someone to test it on x86 also to
> see if maybe it is just a 64bit issue..
>
> I looked at the nv palette changing code and this code looks odd
> to me:
 
   There's nothing wrong with this code.  On the ia64 list it sounds
like all drivers have problems switching to console on ia64.  From
the sound of those problems (console corruption) there is difficulty
writing to the VGA aperture.  When I first encountered that problem
it was because the OS wasn't mapping it uncached.
 
   As for palette corruption, it's probably something different
about the IA64 console driver, or interference from a framebuffer
device, if you have one.   Maybe Matthieu's change the made sure
VGA was unlocked earlier might fix that.   That went into the
"nv" driver 4 weeks ago.

Comment 5 Mike Vaillancourt 2001-08-10 13:56:59 UTC

I have already tested this on x86 and it does not have the problem. I will have
to put the card back i9n a machine to get you the output. I will try to do that
later today.

Comment 6 Mike A. Harris 2001-10-20 23:10:55 UTC

Not sure this card is supported at all.  The status document
does not list Quadro 2 Pro:  http://www.xfree86.org/4.1.0/Status22.html#22

4.1.0:
Support (accelerated) for the Riva 128, 128ZX, TNT, TNT2 (Ultra, Vanta,
M64), GeForce (DDR, 256), GeForce 2 (GTS, Ultra, MX), GeForce 3, Quadro,
and Quadro2 is provided by the "nv" driver.

The email above I sent to mark, I invertently gave him the wrong
hardware information...

Comment 7 Mike A. Harris 2003-06-06 16:54:03 UTC

Not sure why this bug got reassigned recently, since it is so old.  Nvidia
is saying it is a kernel bug, kernel people are saying it is an Nvidia driver
bug.  Bug ping pong at it's finest.  ;o)

If this card is actually supported by 4.1.0, and the XFree86 documentation is
merely accidentally not listing it, it is highly likely that the current
release of XFree86 4.3.0 fixes this problem.

I'm closing this bug as WONTFIX for now because:

1) Red Hat Linux 7.1/ia64 is no longer supported.

2) XFree86 4.1.0 is in maintenance mode, which means it will only receive
   important security updates from here on out, and only on supported operating
   system products.

3) There is no concensus of where the problem actually resides - in the nv
   driver or in the kernel, and the amount of effort it would require to
   determine this isn't worth the effort, in particular since nobody else
   has reported it.