DRI problems with ati/radeon on stable/7 r203425

[Robert Noland]

On Wed, 2010-02-10 at 05:06 -0800, David Wolfskill wrote:
> On Wed, Feb 10, 2010 at 05:48:37AM -0600, Robert Noland wrote:
> > ...
> > > > Are you under fairly severe memory pressure?
> > > > ....
> > > 
> > > The machine has 2GB RAM, so I doubt it:
> > .,,
> > Ok, what I was thinking was that any memory allocations that have
> > M_WAITOK will sleep forever waiting for resources.  If it is a pci based
> > card, it might be waiting for 32MB of contiguous ram for the GART as
> > well.  I have a reworked scatter gather allocation that removes the
> > contiguous requirement.
> 
> I'm certainly willing to try experimental code.  I'm presently bringing
> the machine up to r203751, after which I intend to update any installed
> ports that have had commits in the last 24 hrs.
> 
> That said, my "feel" for the behavior is that there appears to be some
> condition such that it's waiting on something, and when certain
> interrupts occur, it's suddenly able to proceed.  But until that
> interrupt pattern does occur, it waits in such a way that one can't use
> the keyboard to switch to a different vty, one can't login via ssh
> (though it responds to ping), and response to an attempt to login via
> serial port appears to fail as well (but is actually just extremely slow
> -- often slow enough to time out instead of work).

Right, it sounds like the other person is having interrupt issues.  Does
moving the mouse / touchpad have any impact?  Or, possibly disabling
msi? (adding hw.drm.msi=0 to loader.conf)

robert.

> Unlike another correspondent reporting otherwise rather similar
> symptoms, I seem to be able to avoid the "lockup" symptoms by disabling
> DRI in xorg.conf (though the resulting performance leaves somewhat to be
> desired, it isn't as bad as turning the laptop into an expensive,
> fragile brick).
> 
> I did try crfeating a new xorg.conf after the recent update to the X.org
> port(s); I noticed that the newly-created xorg.conf specified a couple
> of things that weren't in my old one:
> 
> Section "Module"
> ...
>         Load  "record"
> ...
>         Load  "dri2"
> 
> so I tried experimenting a bit with those (without success).
> 
> Naturally, the freshly-created xorg.conf failed spectacularly, as it
> didn't include the stanza that I use to un-require hald & dbus:
> 
> Section "ServerFlags"
>         Option      "AutoAddDevices" "False"
> EndSection
> 
> I'm even willing to try requiring hald & dbus, if it's likely that
> it might help (though I'll need to remember to start them first,
> as well as delay starting xdm until they are not only started, but
> actually capable of responding to requests).
> 
> And while I don't intend to go back to FreeBSD 6.x, I note that DRI
> worked in that environment on this hardware for quite a while.  (For
> that matter, it worked in a FreeBSD 4.x environment, as well.)
> 
> (While I also run stable/8 & head on the laptop, I use a common
> /usr/local, so the ports in all cases (other than compat7x) are built
> under stable/7.)
> 
> Peace,
> david
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD