From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 16:43:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5861065694; Thu, 11 Feb 2010 16:43:52 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.freebsd.org (Postfix) with ESMTP id B6CB58FC0A; Thu, 11 Feb 2010 16:43:51 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepa.post.tele.dk (Postfix) with ESMTP id 46B26A50054; Thu, 11 Feb 2010 17:43:05 +0100 (CET) Date: Thu, 11 Feb 2010 17:41:24 +0100 From: Martin Kristensen To: Robert Noland Message-ID: <20100211174124.7573bb91@alpha.miknet.dk> In-Reply-To: <20100211145044.205a3e2b@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> <20100211114910.392f919e@alpha.miknet.dk> <1265890573.8609.151.camel@balrog.2hip.net> <20100211145044.205a3e2b@alpha.miknet.dk> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:43:52 -0000 On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen wrote: > On Thu, 11 Feb 2010 06:16:12 -0600 > Robert Noland wrote: > > > On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: > > > On Wed, 10 Feb 2010 20:17:43 -0600 > > > Robert Noland wrote: > > > > > > > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > > > > On Wed, 10 Feb 2010 16:01:58 -0600 > > > > > Robert Noland wrote: > > > > > > > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > > > > Andriy Gapon wrote: > > > > > > > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > > > > Robert Noland wrote: > > > > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently > > > > > > > > >>> disabling DRI helps; should I try rebuilding > > > > > > > > >>> xorg-server with HAL? > > > > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > > > > libthr regardless of HAL option. Unfortunately, I never > > > > > > > > came up with patch, nor have anyone else. Xorg server > > > > > > > > really uses pthreads when doing DRM and HAL brings in > > > > > > > > libthr dependency only as an accident. > > > > > > > > > > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > > > > > > > I have been running with NoAccel for a long time, since > > > > > > > disabling DRI alone would cause a complete deadlock > > > > > > > (screen to standby, no ssh, no response to keyboard, > > > > > > > etc.). > > > > > > > > > > > > > > However, I rebuilt xorg-server with HAL support, and now > > > > > > > simply disabling DRI allows me to start X. > > > > > > > > > > > > > > The card is RV790 based. > > > > > > > > > > > > Just checked... This card should work with Accel and DRI... > > > > > > At least on -CURRENT with updated ports. Check UPDATING, > > > > > > and set WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > > > > > > > robert. > > > > > > > > > > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > > > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > > > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > > > > libGL-7.6.1. > > > > > > > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as > > > > well, but just checking. 6 won't work. > > > > > > > I am on 8-STABLE. > > > > > I have tried loading radeon.ko manually before startx. > > > > > > > > What are the results? If things are not working, I'll want to > > > > see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri > > > > with X started if you can get it. > > > > > > > > robert. > > > > > > > > > > I have attached the output from pciconf -lvb, sysctl -a |grep > > > ^hw.dri reports: > > > > > > hw.dri.0.name: radeon 0x96 > > > hw.dri.0.vm: > > > hw.dri.0.clients: > > > hw.dri.0.vblank: > > > hw.dri.0.debug: 0 > > > > > > I loaded radeon.ko from within my X session, which was started > > > with DRI "OFF". > > > > Ok, if X doesn't try to open drm, then nothing will show up as being > > mapped. If you do a "sysctl hw.dri" it will show the mappings, but > > the above grep is cutting out most of the useful info. > > > Sorry, I did not understand what you wanted, here is "sysctl hw.dri": > hw.dri.0.name: radeon 0x96 > hw.dri.0.vm: > slot offset size type flags address > mtrr 0 0x00000000fe8e0000 0x00010000 REG 0x82 0xffffff00fe8e0000 no > > hw.dri.0.clients: > a dev pid uid magic ioctls > > hw.dri.0.vblank: > crtc ref count last enabled inmodeset > 00 00 00000000 00000000 00 00 > 01 00 00000000 00000000 00 00 > hw.dri.0.debug: 0 > > > If I run startx with DRI "True" or without an xorg.conf, the > > > screen goes into standby as if the pc is turned off, the mouse and > > > keyboard stops responding to keypresses (ie. numlock-led will not > > > respond to me pressing the key.) and I cannot ssh into the > > > machine. As far as I can tell it has crashed. > > > > > > There is nothing in /var/log/messages, which gives any indication > > > that something went wrong (If I boot the machine - startx and > > > force a reboot I get 2 x dmesg plus fsck messages). > > > > > > Xorg.0.log contains only messages from the last successful start > > > of xorg, and is a far as I can tell useless in tracking this down. > > > > This sounds suspiciously like a WITNESS issue... I wonder if I have > > accidentally MFC'd something that isn't safe. You don't get a core > > dump eventually do you? > > > > robert. > > > I have left it for at least the time it takes to boot my laptop and > try to ssh into the machine (5 min.). I have dumpdev defined. > > I will crash it and leave it for 15 min. to see if something happens. > Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. > > > > > If it will help, I can switch to -CURRENT to see if that > > > > > changes anything. > > > > > > > > > > Martin > > > > > > > > > > PS. Robert, in researching this I got some idea of the effort > > > > > you put into this, thanks! > > > > > > > > > > Martin > > > > > > -- Martin Kristensen