freebsd7 (and 8), radeon, xorg-server -> deadlock or so

Robert Noland rnoland at FreeBSD.org
Thu Feb 11 12:16:21 UTC 2010


On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote:
> On Wed, 10 Feb 2010 20:17:43 -0600
> Robert Noland <rnoland at FreeBSD.org> wrote:
> 
> > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote:
> > > On Wed, 10 Feb 2010 16:01:58 -0600
> > > Robert Noland <rnoland at FreeBSD.org> wrote:
> > > 
> > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote:
> > > > > On Wed, 10 Feb 2010 20:33:46 +0200
> > > > > Andriy Gapon <avg at icyb.net.ua> 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.

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

> > > 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
> 
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD



More information about the freebsd-stable mailing list