From: Ray Glendenning <ray@hackery.demon.co.uk>
  To  : ggi-develop@eskimo.com
  Date: Sun, 30 Aug 1998 22:55:40 +0100 (BST)

Re: Virge lock ups

Hi

On Sun, 30 Aug 1998, Jon M. Taylor wrote:

> 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.
> 

I already tried a quick hack to use the trio driver on my virge DX, and as
you said, I still got the same locks. I think it is possibly timing or
incorrect order of programming. (speculation *8-( )

> 	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. 
> 

Yeah, I tried to fix this last year *8-)

> * 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.
> 

*8-( 

> 
> 	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.
> 

I would take over at least to collect patches as I'm still learning
myself, but if noone else wants the job, I'm here.

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


Ray Glendenning