[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#193127: xserver-xfree86: Radeon 7500 - dri hangs system with ALI motherboard



On Thu, May 15, 2003 at 11:39:25AM +0200, Michel D?nzer wrote:
> On Die, 2003-05-13 at 07:06, Elladan wrote: 
> > Package: xserver-xfree86
> > Version: 4.2.1-6
> > Severity: normal
> > 
> > 
> > Using a Radeon 7500, I get insta-hang running dri applications.  
> > 
> > Eg, start X server with glx etc. enabled, run glxinfo (direct rendering
> > enabled).
> > 
> > Run glxgears - black window appears, system totally hangs.  Even sysrq
> > does nothing at all.
> 
> Are you sure this isn't any of the important bugs on
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xlibmesa3-gl ?

I just reviewed these reports.  The behavior is different - in their
case, bug apparently simply led to GL rendering not working.  In my
case, the system locks up hard.  I've never seen it actually work,
either.  Should this bug report go to xlibmesa3-gl instead, though?

> > I saw a report once of a possible AGP bug with the ALI motherboards, so
> > I suspect this may be related.
> 
> In that case, it may indeed be hard to do anything about it.

Yes, that would indicate a bug in the kernel modules.  Since the X
server handles resource allocation, and the kernel modules have to lock
against it, it's hard to localize of course.

> Anyway, you may want to try the snapshots described in
> http://dri.sourceforge.net/snapshots/README.Debian . You can even try
> without AGP with those using Option "ForcePCIMode". You'll need to build
> the DRM from drm-trunk-module-src though.

Ok, I'll investigate.

Last night, I tried installing XFree 4.3.0 and a more recent kernel
module.  The behavior is only slightly different: With 4.3.0 + new
module, the system still locks up hard eventually.  However, the pointer
continues to move until I try some sort of SysRQ (no other keyboard
sequence does anything).  After SysRQ, the system appears to be frozen
solid.  I expect this indicates that X/Kernel goes into a mostly
deadlocked state, but the silken mouse tap is still working and
interrupts are still processing.  Almost any sort of SysRQ seems fatal
though.

If I can find some time, and a proper cable, I'll attempt to get some
kernel information out through serial console, I guess.

I'll mess around with the snapshots too.  I've tried them in the past
with this card, and was never able to get it working to any sort of
functional degree.  I've seen the mouse working behavior before with 4.2
+ snapshot, and at one point with some bizarre fiddling with the display
mode and AGPMode/AGPSize/VideoRam settings, I was able to get it to run
Tuxkart for up to 30 seconds, after which the system would lock up hard
as before.





Reply to: