Hi all,

OK, I think I've got about as far as I can get with this card on my
own.  Time to dump the current status to the experts and see where we
go from here.

The basic problem is that X locks up at startup with a corrupt display
if the DRI is loaded.  I'm currently running a DRI built from CVS on
May 14th.  This same DRI works just fine with a Voodoo3.  The card I'm
currently trying to get working is a Radeon 64MB DDR ViVo, identified
by scanpci as 

  pci bus 0x1 cardnum 0x05 function 0x0000: vendor 0x1002 device 0x5144
   ATI Radeon QD
   CardVendor 0x1002 card 0x001a (ATI, Card unknown)

and the chipset is one a lot of people have had problems with: an AMD
IronGate AMD-751 (though most of the problems I've seen reported on
the lists have been Radeon+AMD-750, not 751).

The hardware is fine: I was finally able to verify that today by
gettin W98 installed on a scratch disk in the machine, and Quake 2
(the only openGL Linux app I own which also works under Windows!)
works like a charm using system GL.

The symptoms of the lockup are that immediately after X changes
display mode, the entire system locks hard (no irq activity, no
network response) and the display is corrupt.  Typically, if I just
run X directly, I get as far as a display at the correct resolution
with the weave background displayed, but the top inch or so of the
display slopes way off to the right of the monitor.

The *only* thing which makes a difference is

        Load  "dri"

in the XF86Config-4.  If I comment that out, then everything works:
the card performs beautifully, including newer features such as
XV-accelerated DVD playback (XV apertures verified by xvinfo).

However, if I load DRI, then things fail in the manner I described
above.  It doesn't matter if I have previously loaded the Windows
drivers and then rebooted.  Actually running DRI has no impact: if
the fault occurs, the lockup occurs immediately on X startup so I
never get as far as running a DRI application.  More interestingly, I
even get the fault if I don't load the kernel agpgart.o or radeon.o:
in that case, the X server DRM probe fails, resulting in the logs

(EE) RADEON(0): [agp] AGP not available
(EE) RADEON(0): [drm] failed to remove DRM signal handler
(II) RADEON(0): [drm] removed 1 reserved context for kernel
DRIUnlock called when not locked
(II) RADEON(0): [drm] unmapping 4096 bytes of SAREA 0xd0858000 at 0x40018000    
[....]
(II) RADEON(0): Direct rendering disabled                                       

but the server *still* locks up after the point 

Could not init font path element /usr/X11R6-DRI/lib/X11/fonts/Speedo/, removing!
Could not init font path element /usr/X11R6-DRI/lib/X11/fonts/Type1/            

in the logs.

In other words, merely loading the DRI module is guaranteed to cause
lockup on subsequent display initialisation, even if the DRI is not
successfully initialised.  The only reliable way to start X is to
comment out the "dri" module line in XF86Config-4 entirely, and even
that is not enough if I have previously tried loading the DRI and have
since soft-rebooted.  

I still have trouble getting X running even without DRI loaded, but
I'll update folks if I get a handle on a 100% sure pattern of letting
things start up successfully.  This lack of 100% reproducibility means
I can't be completely sure if it's just the DRI module which makes the
difference.

I've got logs of successful and unsuccessful startup attempts but
there is no visible difference between them (these are just logs of
the normal startx output redirected to serial console, not the more
verbose logs in /var/log; I only have verbose logs of the successful
startups).

I've also tried lspci -vvxxx both on successful and unsuccessful
attempts, and before and after running the Windows drivers, but there
is no difference in the AGP or Radeon PCI tables there (only the IDE
and NCR SCSI PCI tables seem to be set up differently if I've
previously run Windows.)

If you need more info, please just ask.  I _could_ just throw the card
into a non-Irongate machine and stick to the old Voodoo3 on this box,
but I'd really rather do the work to fix this problem.

Cheers,
 Stephen

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to