DRI problems with ati/radeon on stable/7 r203425

[David Wolfskill]

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

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
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20100210/b1b0f56d/attachment.pgp