Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
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. -- Martin Kristensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On Wed, 10 Feb 2010 15:57:42 -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. > > Is that an HD5xxx? > > robert. > > No, HD4890. -- Martin Kristensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
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. I have tried loading radeon.ko manually before startx. 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 Kristensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
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". 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. > > 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 pciconf.out Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
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 addressmtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 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, th
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
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 0
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland wrote: > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > > On February 13, 2010, Robert Noland wrote: > > > Ok, I've put up a patch at: > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > > > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch > > This one should work on 8... > > robert. > > > > This is sort of a mega patch and includes: > > > > > > Re-worked drm mapping code, that ensures that we don't end up > > > incorrectly mapping certain maps with overlapping offsets. This > > > generally shows up as the ring buffer not being cleared > > > (contents != 0 in xorg.log) which leads to corruption and other > > > bad behavior. > > > > > > Re-written scatter gather allocation code. This interacts > > > directly with the VM system, rather than using bus_dma to allow > > > us to grab non-contiguous pages for the scatter gather backing of > > > the GART. It also makes it easier to handle the caching mode of > > > the backing pages. > > > > > > Disable cache snooping on radeon cards, since we have write > > > combining set properly now. > > > > > > I have at least done a test build on -CURRENT with this patch, > > > but I haven't had time to do much else without the rest of the > > > code in my tree. I've been running most all of this code for a > > > month or two now at least, so it is mostly just a question of > > > whether or not I got all of the conflicts sorted out properly > > > when I made this patch. > > > > > > The re-mapping code has the most widespread impact and has been > > > tested on radeon r600 amd64, intel g45 i386 and mga amd64. > > > > > > robert. The patch applied cleanly. I have applied the patch to a clean 8-STABLE environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. I still see the crashes when starting X with DRI on. This is what I see in messages: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7b000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7c000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7d000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7e000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7f000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0xc0286415, nr=0x15, dev 0xff0001a79400, auth=1 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = 0xfe8e, size = 0x0001, type = 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 0xfe8e/0x1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0x80106459, nr=0x59, dev 0xff0001a79400, auth=1 There has been one odd development. If I startx with DRI off or NoAccel set it starts as usual. If I then quit and to cli and restart, I see the same crash as if I had DRI on. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
