From owner-freebsd-x11@FreeBSD.ORG Wed Feb 10 14:59:07 2010 Return-Path: Delivered-To: x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB593106566C for ; Wed, 10 Feb 2010 14:59:06 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0FF8FC08 for ; Wed, 10 Feb 2010 14:59:06 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AEuqRO004528 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 09:56:56 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Wolfskill , x11@FreeBSD.org In-Reply-To: <20100210130642.GA391@bunrab.catwhisker.org> 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> <20100210130642.GA391@bunrab.catwhisker.org> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 08:56:45 -0600 Message-Id: <1265813805.8609.52.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Subject: Re: DRI problems with ati/radeon on stable/7 r203425 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 14:59:07 -0000 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 FreeBSD