Date: Wed, 10 Feb 2010 05:06:42 -0800 From: David Wolfskill <david@catwhisker.org> To: Robert Noland <rnoland@FreeBSD.org> Cc: x11@FreeBSD.org Subject: Re: DRI problems with ati/radeon on stable/7 r203425 Message-ID: <20100210130642.GA391@bunrab.catwhisker.org> In-Reply-To: <1265802517.8609.25.camel@balrog.2hip.net> References: <20100208172654.GA391@bunrab.catwhisker.org> <1265764746.8609.18.camel@balrog.2hip.net> <20100210023558.GV391@bunrab.catwhisker.org> <1265802517.8609.25.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--d2IMS6fuC0p5eWIP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 10, 2010 at 05:48:37AM -0600, Robert Noland wrote:
> ...
> > > Are you under fairly severe memory pressure?
> > > ....
> >=20
> > 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"
=2E..
Load "record"
=2E..
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
--=20
David H. Wolfskill david@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.
--d2IMS6fuC0p5eWIP
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iEYEARECAAYFAktyr2IACgkQmprOCmdXAD0MHACfQy9E1b+cIDtWnPRpJjagN2aW
+NcAnAiixm4MMSp2yIIUkqhiF6Y141hG
=cpao
-----END PGP SIGNATURE-----
--d2IMS6fuC0p5eWIP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100210130642.GA391>