Index:
[thread]
[date]
[subject]
[author]
From: Brent Fulgham <bfulgham@xpsystems.com>
To : ggi-develop@eskimo.com
Date: Mon, 19 Jul 1999 13:14:53 -0700
RE: Request for Assistance: Anyone with RIVA128 kgicon success?
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------ =_NextPart_001_01BED223.5CC9F7F0
Content-Type: text/plain
Jon,
Thanks for the info. I'll play with it this evening when I get
home and see if I can come up with anything.
>
> Sounds like bad clock synthesis. Often when this
> happens, the green
> light on the front of youyr monitor will turn amber to
> indicate that the
> frequency limit of the monitor has been exceeded. Does this occur?
>
Hmm. I am at a bit of a disadvantage here because I am fairly
red-green color deficient. So, I may be able to notice a shift in
intensity but may not be able to provide a true reading of the "color".
Sorry! :-)
> Recompile with DEBUG_LEVEL=255 in all driver
> sourcefiles (chipset, ramdac, clockchip) and look at /var/log/messages.
Will do.
> > 7. I notice that the header files used in the kgicon source do not
reflect
> > the most recent versions provided by nVidia. I swapped these files out,
but
> > did not observe any benefit.
>
> Yeah, it sounds like the problem is something else.
>
Should I stick with the data in the header files as present in CVS
or continue using nVidia's version?
> can't get to first base with a driver is to modify it so that
> it loads and does a full register dump before and after the initial
> modeset. anything. I then load the driver on top of vesafb so that
> I can compare the two register dumps - usually the differences will
> jump right out. All of the infrastructure to do this should be in
> the driver code already - if not, I have some generic KGI
> register-dumping code I can easily adapt.
>
Sorry to have to ask this, but when you refer to "register dumping" I
assume you mean the registers in the graphic card itself, rather than
the system's processor, right? If so, I'm not sure how to go about
dumping these items. I don't have much experience debugging device
drivers -- I assume I can't just pull up gdb and read the registers.
Am I to assume that the source generally has a routine someplace that
will handle the dump if I enable it somehow?
Thanks for your help.
-Brent
------ =_NextPart_001_01BED223.5CC9F7F0
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.0.1460.9">
<TITLE>RE: Request for Assistance: Anyone with RIVA128 kgicon success?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Jon,</FONT>
</P>
<P><FONT SIZE=2>Thanks for the info. I'll play with it this evening when I get </FONT>
<BR><FONT SIZE=2>home and see if I can come up with anything.</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Sounds like bad clock synthesis. Often when this </FONT>
<BR><FONT SIZE=2>> happens, the green </FONT>
<BR><FONT SIZE=2>> light on the front of youyr monitor will turn amber to </FONT>
<BR><FONT SIZE=2>> indicate that the </FONT>
<BR><FONT SIZE=2>> frequency limit of the monitor has been exceeded. Does this occur?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>Hmm. I am at a bit of a disadvantage here because I am fairly</FONT>
<BR><FONT SIZE=2>red-green color deficient. So, I may be able to notice a shift in</FONT>
<BR><FONT SIZE=2>intensity but may not be able to provide a true reading of the "color".</FONT>
</P>
<P><FONT SIZE=2>Sorry! :-)</FONT>
</P>
<P><FONT SIZE=2>> Recompile with DEBUG_LEVEL=255 in all driver </FONT>
<BR><FONT SIZE=2>> sourcefiles (chipset, ramdac, clockchip) and look at /var/log/messages.</FONT>
</P>
<P><FONT SIZE=2>Will do.</FONT>
</P>
<P><FONT SIZE=2>> > 7. I notice that the header files used in the kgicon source do not reflect</FONT>
<BR><FONT SIZE=2>> > the most recent versions provided by nVidia. I swapped these files out, but</FONT>
<BR><FONT SIZE=2>> > did not observe any benefit.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Yeah, it sounds like the problem is something else.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>Should I stick with the data in the header files as present in CVS</FONT>
<BR><FONT SIZE=2>or continue using nVidia's version?</FONT>
</P>
<BR>
<P><FONT SIZE=2>> can't get to first base with a driver is to modify it so that </FONT>
<BR><FONT SIZE=2>> it loads and does a full register dump before and after the initial </FONT>
<BR><FONT SIZE=2>> modeset. anything. I then load the driver on top of vesafb so that </FONT>
<BR><FONT SIZE=2>> I can compare the two register dumps - usually the differences will </FONT>
<BR><FONT SIZE=2>> jump right out. All of the infrastructure to do this should be in </FONT>
<BR><FONT SIZE=2>> the driver code already - if not, I have some generic KGI </FONT>
<BR><FONT SIZE=2>> register-dumping code I can easily adapt.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>Sorry to have to ask this, but when you refer to "register dumping" I</FONT>
<BR><FONT SIZE=2>assume you mean the registers in the graphic card itself, rather than</FONT>
<BR><FONT SIZE=2>the system's processor, right? If so, I'm not sure how to go about</FONT>
<BR><FONT SIZE=2>dumping these items. I don't have much experience debugging device</FONT>
<BR><FONT SIZE=2>drivers -- I assume I can't just pull up gdb and read the registers.</FONT>
</P>
<P><FONT SIZE=2>Am I to assume that the source generally has a routine someplace that</FONT>
<BR><FONT SIZE=2>will handle the dump if I enable it somehow?</FONT>
</P>
<P><FONT SIZE=2>Thanks for your help.</FONT>
</P>
<P><FONT SIZE=2>-Brent</FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BED223.5CC9F7F0--
Index:
[thread]
[date]
[subject]
[author]