Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
Xorg.log after: #killall xdm #kldunload radeon #dmesg: info: [drm] Resetting GPU vgapci0: child drm0 requested pci_disable_busmaster info: [drm] MSI released drm0: detached Warning: memory type drm_bufs leaked memory on destroy (2 allocations, 64 bytes leaked). drm0: ATI Radeon HD 3450 on vgapci0 #kldload radeon #dmesg: drm0: ATI Radeon HD 3450 on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 #xdm after this procedure the X never come up, but the system not crashed, and the log attached. On 2/15/10, Robert Noland rnol...@freebsd.org wrote: On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland rnol...@freebsd.org 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. I'm really starting to think that this is a bug in the Xserver somewhere... If DRI is off, the kernel drm is not involved at all. The radeon driver does grope around on the pci bus (via libpciaccess) which could potentially cause issues, but... miwi and a few other folks have picked up the ball to get us up to xorg 7.5, since I just don't have time to do it all now. That might be a good thing to try, I expect that they will have a patch ready soon, like within a few days. robert. Martin -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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 ___ 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 Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland rnol...@freebsd.org 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
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland rnol...@freebsd.org 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. I'm really starting to think that this is a bug in the Xserver somewhere... If DRI is off, the kernel drm is not involved at all. The radeon driver does grope around on the pci bus (via libpciaccess) which could potentially cause issues, but... miwi and a few other folks have picked up the ball to get us up to xorg 7.5, since I just don't have time to do it all now. That might be a good thing to try, I expect that they will have a patch ready soon, like within a few days. robert. Martin -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch 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. But it's your call, you obviously know more about this than me anyway :) Bye, Uli -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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 February 13, 2010, Robert Noland wrote: Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch 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. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Feb 13 10:55:30 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LG (**) | |--Device Card0 (**) Option DontZap off (**) Option BlankTime 15 (**) Option StandbyTime 120 (**) Option SuspendTime 150 (**) Option OffTime 180 (**) Option AIGLX on (**) Option AllowEmptyInput false (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/cmpsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/cmpsfont). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/amspsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/amspsfont). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to /usr/local/lib/xorg/modules (**) Extension Composite is enabled (==) |--Input Device default pointer (==) |--Input Device default keyboard (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. (==) The core keyboard device wasn't specified explicitly in the layout. Using the default keyboard configuration. (II) Loader magic: 0x3f60 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
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 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. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) Ah, on 8 it just needs to use d_mmap2. That is only a couple of line change. IIRC, just change d_mmap to d_mmap2 in drm_drv.c and change the declaration of drm_mmap to the correct type. d_mmap2 in 8 is the same as d_mmap in HEAD. * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? (II) [drm] Mapping SAREA for DRM lock failed. (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Hrm... That shouldn't happen... but I'm not sure if I missed something in the patch or if it hasn't applied correctly to 8 robert. Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Feb 13 10:55:30 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LG (**) | |--Device Card0 (**) Option DontZap off (**) Option BlankTime 15 (**) Option StandbyTime 120 (**) Option SuspendTime 150 (**) Option OffTime 180 (**) Option AIGLX on (**) Option AllowEmptyInput false (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/cmpsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/cmpsfont). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/amspsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/amspsfont). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF,
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
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. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Feb 13 10:55:30 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LG (**) | |--Device Card0 (**) Option DontZap off (**) Option BlankTime 15 (**) Option StandbyTime 120 (**) Option SuspendTime 150 (**) Option OffTime 180 (**) Option AIGLX on (**) Option AllowEmptyInput false (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/cmpsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/cmpsfont). (WW) `fonts.dir' not found (or not valid) in /usr/local/share/fonts/amspsfont. Entry deleted from font path. (Run 'mkfontdir' on /usr/local/share/fonts/amspsfont). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to /usr/local/lib/xorg/modules (**) Extension Composite is enabled (==) |--Input Device default pointer (==) |--Input Device default keyboard (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. (==) The
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On February 13, 2010, 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... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev-agp_buffer_map-virtual 0xff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_vm_start 0xf000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xff00dfff 0FFF Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0xb956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x82128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x98b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x49a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. Cheers. -- Norbert Papke. npa...@acm.org ___ 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
The interest thing is, with the previous version of xorg-server never locked the system up... On 2/13/10, Norbert Papke npa...@acm.org wrote: On February 13, 2010, 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... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev-agp_buffer_map-virtual 0xff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_vm_start 0xf000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv-gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xff00dfff 0FFF Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0xb956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x82128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x98b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x49a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. Cheers. -- Norbert Papke. npa...@acm.org ___ 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 ___ 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 February 13, 2010, Norbert Papke wrote: I will repeat the experiment a few more times. After quite a number of trials, I never managed to get any further with the radeon driver. I also tried the radeonhd driver. It seems to behave a little differently. I usually get to an X screen with some incompletely rendered windows before the system hangs. Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106403, nr=0x03, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_by_busid] 1:0:0 = IRQ 260 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80086414, nr=0x14, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_install] irq=260 Feb 13 15:51:51 proven kernel: drm0: [ITHREAD] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x800c6455, nr=0x55, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80106459, nr=0x59, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106451, nr=0x51, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_getparam] pid=1833 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x20006441, nr=0x41, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:r600_do_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0602 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06021000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06022000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06023000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06028000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc010644d, nr=0x4d, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_cp_indirect] idx=2 s=0 e=14400 d=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] dwords:3600 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] offset 0xf0222000 I am not sure what to make of this. Cheers, -- Norbert. ___ 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 rnol...@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 rnol...@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 a...@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. 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, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... While that would make sense... And it might work more like that once I implement TTM/KMS (actually the whole memory requirements will change as pages will then get mapped in and out of the gart), but currently, the allocation of scatter gather memory to populate the gart is driven by userland. The only memory that is pre-allocated by the driver is the sarea, and the register maps are pre-allocated, but that is just address mapping. For everything else, userland tells us when and how much memory to allocate. On radeon (and Intel for that matter) most if not all cards can reference anything that the cpu can, (up to at least 36 bits, iirc, or maybe 40) so I might drop the 4GB limit. However, since all of this is done in the generic drm code, I don't actually know what card I'm allocating memory for when I do it, so I won't change that part until I need to. I'll try and get a cleaned up patch of the scatter gather rework out this weekend. I've abandoned the use of bus_dma entirely for allocating SG pages and interact with the VM directly, thus avoiding the contiguous requirements of bus_dma. robert. But it's your call, you obviously know more about this than me anyway :) Bye, Uli -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@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 rnol...@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 a...@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 rnol...@freebsd.org FreeBSD ___ 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 rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@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 rnol...@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 a...@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. 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, 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. 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 ___ 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 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@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 rnol...@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 a...@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. 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 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, 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
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 2010-02-11 at 17:41 +0100, Martin Kristensen wrote: On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@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 rnol...@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 a...@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. 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 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, 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. Hrm, ok... I'll try to dig into it this weekend... robert. If it will help, I can switch to
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
Oliver Pinter wrote: After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option DRI OFF' though, I will this evening. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. [1] http://tx97.net/~magv/dmesg-t40.80-p2.txt ___ 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, 2010-02-10 at 12:29 +0200, Vitaly Magerya wrote: Oliver Pinter wrote: After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option DRI OFF' though, I will this evening. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. robert. [1] http://tx97.net/~magv/dmesg-t40.80-p2.txt ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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
Robert Noland wrote: I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option DRI OFF' though, I will this evening. With DRI disabled, no hang occurs and I'm once again happy. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No pressure from me. I'm already grateful that you single-handedly keep the whole DRI-on-FreeBSD thing going. ___ 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 10/02/2010 12:29 Vitaly Magerya said the following: Oliver Pinter wrote: After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option DRI OFF' though, I will this evening. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. -- Andriy Gapon ___ 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
Andriy Gapon wrote: Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? ___ 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 10/02/2010 18:01 Vitaly Magerya said the following: Andriy Gapon wrote: Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Please try, if even just to see if it helps. -- Andriy Gapon ___ 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, 2010-02-10 at 18:01 +0200, Vitaly Magerya wrote: Andriy Gapon wrote: Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. 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. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. +(II) RADEON(0): [drm] removed 1 reserved context for kernel +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xff8014a6d000 at 0x8006d4000 +(II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f (II) RADEON(0): MC_AGP_LOCATION : 0x003f (==) RADEON(0): Backing store disabled -(II) RADEON(0): [DRI] installation complete -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 -(WW) RADEON(0): DRI init changed memory map, adjusting ... -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f is: 0x0003 -(II) RADEON(0): RADEONRestoreMemMapRegisters() : -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 -(II) RADEON(0): Direct rendering enabled -(II) RADEON(0): Setting EXA maxPitchBytes -(II) EXA(0): Offscreen pixmap area of 111050752 bytes -(II) EXA(0): Driver registered support for the following operations: -(II) Solid -(II) Copy -(II) Composite (RENDER acceleration) -(II) UploadToScreen -(II) DownloadFromScreen -(II) RADEON(0): Acceleration enabled +(WW) RADEON(0): Direct rendering disabled +(EE) RADEON(0): Acceleration initialization failed +(II) RADEON(0): Acceleration disabled (**) Option dpms (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled -(II) RADEON(0): Set up textured video +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP Output CRT2 disable success (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled Output UNIPHY1 transmitter setup success @@ -661,7 +634,7 @@ Mode 1920x1200 - 2080 1235 9 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 +(II) RADEON(0): MC_AGP_LOCATION : 0x003f freq: 15400 best_freq: 15390 best_feedback_div: 57 Pretty obvious what went wrong... Bye, Uli ___ 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, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. robert. +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. +(II) RADEON(0): [drm] removed 1 reserved context for kernel +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xff8014a6d000 at 0x8006d4000 +(II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f (II) RADEON(0): MC_AGP_LOCATION : 0x003f (==) RADEON(0): Backing store disabled -(II) RADEON(0): [DRI] installation complete -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 -(WW) RADEON(0): DRI init changed memory map, adjusting ... -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f is: 0x0003 -(II) RADEON(0): RADEONRestoreMemMapRegisters() : -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 -(II) RADEON(0): Direct rendering enabled -(II) RADEON(0): Setting EXA maxPitchBytes -(II) EXA(0): Offscreen pixmap area of 111050752 bytes -(II) EXA(0): Driver registered support for the following operations: -(II) Solid -(II) Copy -(II) Composite (RENDER acceleration) -(II) UploadToScreen -(II) DownloadFromScreen -(II) RADEON(0): Acceleration enabled +(WW) RADEON(0): Direct rendering disabled +(EE) RADEON(0): Acceleration initialization failed +(II) RADEON(0): Acceleration disabled (**) Option dpms (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled -(II) RADEON(0): Set up textured video +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP Output CRT2 disable success (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled Output UNIPHY1 transmitter setup success @@ -661,7 +634,7 @@ Mode 1920x1200 - 2080 1235 9 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x0003 +(II) RADEON(0): MC_AGP_LOCATION : 0x003f freq: 15400 best_freq: 15390
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
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. Unloading radeon also works, but the kernel prints this warning: Warning: memory type drm_bufs leaked memory on destroy (4 allocations, 128 bytes leaked). And Xorg fails on start afterward with: Fatal server error: no screens found (The number of allocations and the amount of leaked memory may vary; 32 bytes per allocation is constant though). I guess this means I should not unload it. ___ 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 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. -- Andriy Gapon ___ 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, 2010-02-11 at 06:58 +1100, Peter Jeremy wrote: On 2010-Feb-10 20:33:46 +0200, Andriy Gapon a...@icyb.net.ua wrote: 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. Try Ports/139011 - this adds an option to enable GLX TLS - which appears to be the underlying problem. GLX TLS, just plain does not work on FreeBSD. It has to be enabled in both the server and mesa and just makes bad things happen. I can make it all build, but having it actually work is a whole other matter. robert. http://www.freebsd.org/cgi/query-pr.cgi?pr=139011 -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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:33:46 +0200 Andriy Gapon a...@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. -- 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, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@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. Is that an HD5xxx? robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@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. -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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 2010-Feb-10 20:33:46 +0200, Andriy Gapon a...@icyb.net.ua wrote: 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. Try Ports/139011 - this adds an option to enable GLX TLS - which appears to be the underlying problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=139011 -- Peter Jeremy pgpQUbC0jKHAF.pgp Description: PGP signature
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 15:57:42 -0600 Robert Noland rnol...@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 a...@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. 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 rnol...@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 a...@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. 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, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@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 a...@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 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. 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! -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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.02.2010 at 12:08:12 -0600, Robert Noland wrote: On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window switching was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.0 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.0 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c0 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... But it's your call, you obviously know more about this than me anyway :) Bye, Uli ___ 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
