From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sun, 30 Aug 1998 14:19:35 -0700 (PDT)

Re: Virge lock ups

On Sun, 30 Aug 1998, Ray Glendenning wrote:

> Hi
> 
> When I try to use the virge driver, it consistently locks my machine solid
> after a random number of console switches (of mode switches ie running a
> libggi proggie).  This happens if I compile kgicon and the kernel for both
> SMP (not sure if this is safe) or UP.  I have even compiled kgicon into
> the kernel (using my own patch) to see elimenate vgacon from the equation
> (well, you never know!).
> 
> It crashes just after 'dump_state' finishes printing its stuff (I have a
> dumb terminal as console), so it is somewhere in the chip programming
> part.  I'm willing to crash my machine some more if someone can tell me
> where to put debugging stuff so we can eliminate this crash (or am I the
> only one this is happening to???)
> 
> Cheers for any help

	The Virge driver is largely a straight copy of the Trio64 driver. 
The Trio64 driver also exhibits this behavior.  When I was using my
Trio64V+ to do the initial kgicon development, my machine would lock hard
approximately every sixth or seventh time I inserted the kgicon.o module. 
This pattern persisted across reboots, so I'm doubting that the problem is
cruft building up in the driver.  More likely is that some registers are
being programmed incorrectly somewhere in a way which is somehow
cumulative, and after a certain number of modesets the problem reaches a 
critical point and the next modeset locks the bus.

	There are a lot of things that the Trio and Virge drivers do
wrong, incompletely or not at all: 

* The Trio64 RAMDAC driver does not program the DAC, the chipset driver
does.  And it does it SVGALib bang-the-registers-as-you-go style, not the
(much better) store-the-registers-and-save-them-all-at-once KGI style.  
These chipsets have a wierd access method for the DAC registers (they are 
mapped to SR11-SR18 and to higher CRxx registers also) and they are not 
saved with the rest of the registers.

* The clockchip driver is almost an exact clone of the S3 SDAC driver. 
The Trioxx and Virge family integrated DACs are quite similar to the SDAC,
but there are some differences, and those differences are not currently
taken into account.

* There are three well-known Trio64xx chipset bugs which need to be
accounted for and are not currently.  One of them affects my card, and I
can't get 8bpp modes to work above YRES > 600 without the fix.  The fix is
easy, but it is only applicable to certain revisions of the hardware.

* Horizontal pixel clocks need to be doubled for 15/16bpp modes to work. 
They are not, so those modes don't work right (or at all in some
resolutions).  That is why you get out-of-range timings for those modes -
the slow pixel clock effectively doubles the vertical refresh rate.  When
I do get in-range 15/16bpp modes, they have vert refresh rates of like
140Hz(!) and I can only see them because I have a nice 17" monitor. 

* The extended (8514-type) acceleration registers are never set in the
chipset driver and there's no Trioxx or Virge accel drivers yet.  So, no
accelerations are present.


	Lots of work needs to be done on these drivers.  But I have been
fighting with the Trio driver off and on for two years now and I have
gotten to the point where I get nauseous just thinking about working on
them again.  The buggy brain-deadness of that hardware family is nothing
short of monumental.  If anyone out there would like to step forward and
replace me as the official Trio driver maintainer, I would welcome it
greatly.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed