Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Mon, 2009-05-04 at 20:15 -0700, David Johnson wrote: > This topic has been recently discussed twice before in the past month and a > half, but without resolution. It now reappears on my system as I upgrade to > 7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I > am desperately hoping for a resolution. > > To reiterate the problem: Xorg will occassionally hang. This only happens > when > compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports > updated > to this morning. About a third of the time the kernel locks up, and I cannot > ssh into the system. The other half of the time I can ssh into the system. > There I notice that Xorg has the state of "drmwtq", with perhaps some other > GUI processes in the same state. > > The video card is a Radeon X1550. I have tried with and without AGPMode set, > and both XAA and EXA render modes. No change. > > You can look at my xorg.conf and Xorg log at: > http://www.usermode.org/misc/xorg.conf > http://www.usermode.org/misc/Xorg.0.log.old > > p.s. Posting to freebsd-stable, as this problem has been previously discussed > here. If this is no longer the appropriate list, please let me know. Unfortunately, hanging in drmwtq isn't really that informative... What this says is that we have submitted commands to the GPU and are waiting on it to process them. When userland tells us to wait for the event, we check to see if the card has already processed the command. If it has, then we just return immediately. If it hasn't, then we sleep waiting on an interrupt from the card once it has processed the command. We will sleep for at most 3 seconds, but userland (via libdrm) will just keep asking us over and over. This generally suggests that the GPU is locked up... Given that you say sometimes it locks up hard (usually a panic, that you can't see since X is running) and other times only X is stalled it might be related to this patch, if you haven't tried this on already. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch I would usually suggest that you try AGPMode 1, but since you have already tried PCI mode, that should rule that out. You should be using EXA on this card, but having tried XAA is also good for a sanity check. I rarely get to run a card for very long anymore... I end up swapping cards out a few times a day lately, but I have recently been running an x600 pcie (r300) with compiz for at least several hours without issue. If you can figure out a way to reproduce it, or manage to get a core file from one of the panics that would help. Preferably without involving KDE, since I don't run it... I have also run an x1650 PCI-E somewhat recently, which is the closest I have to your card, though I don't remember exactly how long ago it was that I ran it for more than an hour. Probably 2 or 3 weeks ago. robert. > Thank you, -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > This generally suggests that the GPU is locked up... Given that you say > sometimes it locks up hard (usually a panic, that you can't see since X > is running) and other times only X is stalled it might be related to > this patch, if you haven't tried this on already. > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch Nope, that didn't help. Still froze when I tried opening multiple windows at once. I'm backing out the patch to get back to a clean state. I also edited my xorg.conf to be closer to yours. No difference. What information do you need to go forward, and how do I collect it? p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if that helps any. Thanks for you time, -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > > This generally suggests that the GPU is locked up... Given that you say > > sometimes it locks up hard (usually a panic, that you can't see since X > > is running) and other times only X is stalled it might be related to > > this patch, if you haven't tried this on already. > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > Nope, that didn't help. Still froze when I tried opening multiple windows > at once. I'm backing out the patch to get back to a clean state. > > I also edited my xorg.conf to be closer to yours. No difference. > > What information do you need to go forward, and how do I collect it? > > p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if > that helps any. I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks in the dark. Any help would be greatly appreciated. Please let me know what information is needed and how I collect it. Thank you, -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Thu, 2009-05-07 at 22:29 -0700, David Johnson wrote: > On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: > > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > > > This generally suggests that the GPU is locked up... Given that you say > > > sometimes it locks up hard (usually a panic, that you can't see since X > > > is running) and other times only X is stalled it might be related to > > > this patch, if you haven't tried this on already. > > > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > > > Nope, that didn't help. Still froze when I tried opening multiple windows > > at once. I'm backing out the patch to get back to a clean state. > > > > I also edited my xorg.conf to be closer to yours. No difference. > > > > What information do you need to go forward, and how do I collect it? > > > > p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if > > that helps any. > > I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks > in the dark. Any help would be greatly appreciated. Please let me know what > information is needed and how I collect it. I still can't reproduce this... I updated the Xserver, libGL and dri ports yesterday, all of which could be related to locking up the GPU and worth a shot. Failing that, I need you to enabled drm debugging. Start the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 then startx. robert. > Thank you, > -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 07:35:45 am Robert Noland wrote: > I still can't reproduce this... I updated the Xserver, libGL and dri > ports yesterday, all of which could be related to locking up the GPU and > worth a shot. Failing that, I need you to enabled drm debugging. Start > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 > then startx. I've got all the updated ports as of last night, so that wasn't it. I turned AIGLX back on, and it promptly locked up again. This time, however, the screen went black instead of freezing, but otherwise the same as always. I then turned on hw.dri.0.debug, and messages quickly filled up with the following repeated message: [drm:pid1195:drm_ioctl] returning 4 [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Fri, 2009-05-08 at 14:58 -0700, David Johnson wrote:
> On Friday 08 May 2009 07:35:45 am Robert Noland wrote:
> > I still can't reproduce this... I updated the Xserver, libGL and dri
> > ports yesterday, all of which could be related to locking up the GPU and
> > worth a shot. Failing that, I need you to enabled drm debugging. Start
> > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
> > then startx.
>
> I've got all the updated ports as of last night, so that wasn't it.
>
> I turned AIGLX back on, and it promptly locked up again. This time, however,
> the screen went black instead of freezing, but otherwise the same as always.
> I then turned on hw.dri.0.debug, and messages quickly filled up with the
> following repeated message:
>
> [drm:pid1195:drm_ioctl] returning 4
> [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00,
> auth=1
>
This is too late to really see anything... This still just suggests that
the GPU is locked up. What is happening below is that we have emitted
an "irq" to the card and we are waiting on it to parse that. The return
value 4 is EINTR which says that we were interrupted while we were
waiting. When we return EINTR, libdrm just performs the ioctl over
again. We first read the register from the card to see if it has parsed
at least up to what we are looking for, if so we just return success and
don't sleep. If the register says that we haven't parsed the command,
then we sleep for a max of 3 seconds waiting on the card to catch up.
In your case, the card is never catching up, which suggests that the
card is hung and not processing the command stream anymore.
static int radeon_wait_irq(struct drm_device * dev, int swi_nr)
{
drm_radeon_private_t *dev_priv =
(drm_radeon_private_t *) dev->dev_private;
int ret = 0;
if (RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr)
return 0;
dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
DRM_WAIT_ON(ret, dev_priv->swi_queue, 3 * DRM_HZ,
RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr);
if (ret == -ERESTART)
DRM_DEBUG("restarting syscall");
return ret;
}
In order to guess what might be causing this, drm debugging needs to be
enabled before the hang, so that we can hopefully figure out what leads
up to the hung GPU.
robert.
--
Robert Noland
FreeBSD
signature.asc
Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: > In order to guess what might be causing this, drm debugging needs to be > enabled before the hang, so that we can hopefully figure out what leads > up to the hung GPU. Unfortunately that won't work, because turning on hw.dri.0.debug slows down compositing so much that it won't reproduce. -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: > In order to guess what might be causing this, drm debugging needs to be > enabled before the hang, so that we can hopefully figure out what leads > up to the hung GPU. I'm not able to do that, but I did manage to get debug turned on and dmesg captured early enough to catch some additional information. I've place the full file online at http://www.usermode.org/misc/dmesg.txt, but am including some snippets here. Hopefully this is enough to move forward. -- David Johnson ... [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_freelist_get] done_age = 102778 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1 [drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58 [drm:pid1822:drm_close] open_count = 2 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_cp_stop] [drm:pid1822:radeon_do_cp_flush] [drm:pid1822:radeon_do_cp_idle] [drm:pid1822:radeon_do_cp_stop] [drm:pid1822:radeon_do_engine_reset] info: [drm] Num pipes: 1 [drm:pid1822:radeon_do_cp_reset] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, auth=1 [drm:pid1822:drm_irq_uninstall] irq=16 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, auth=1 [drm:pid1822:radeon_do_cleanup_cp] [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, auth=1 [drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 2 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1 [drm:pid1822:drm_rmctx] 1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1 [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, auth=1 [drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x8001), flags = 0x [drm:pid1822:drm_close] open_count = 1 [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1 [drm:pid1822:drm_lastclose] [drm:pid1822:radeon_do_cleanup_cp] info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Num pipes: 1 info: [drm] Setting GART location based on new memory map info: [drm] Loading R500 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 [drm:pid6216:drm_ioctl] returning 4 ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote: > On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: > > In order to guess what might be causing this, drm debugging needs to be > > enabled before the hang, so that we can hopefully figure out what leads > > up to the hung GPU. > > I'm not able to do that, but I did manage to get debug turned on and dmesg > captured early enough to catch some additional information. I've place the > full file online at http://www.usermode.org/misc/dmesg.txt, but am including > some snippets here. Hopefully this is enough to move forward. > > -- > David Johnson This trace still looks odd... > ... > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, > auth=1 > [drm:pid1822:radeon_freelist_get] done_age = 102778 Things appear to be working at this point. > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, > auth=1 > [drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1 > [drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58 Now, open count is 2 and something is calling close. > [drm:pid1822:drm_close] open_count = 2 > [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, > auth=1 > [drm:pid1822:radeon_cp_stop] > [drm:pid1822:radeon_do_cp_flush] > [drm:pid1822:radeon_do_cp_idle] > [drm:pid1822:radeon_do_cp_stop] > [drm:pid1822:radeon_do_engine_reset] > info: [drm] Num pipes: 1 > [drm:pid1822:radeon_do_cp_reset] > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_irq_uninstall] irq=16 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, > auth=1 > [drm:pid1822:radeon_do_cleanup_cp] > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_rmctx] 2 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_rmctx] 1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, > auth=1 > [drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x8001), flags = > 0x Another close, followed by lastclose, so drm is fully shutdown. > [drm:pid1822:drm_close] open_count = 1 > [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1 > [drm:pid1822:drm_lastclose] > [drm:pid1822:radeon_do_cleanup_cp] Now, this looks like several vt switches... We don't see the open sequence here, so I assume that debugging was disabled at this point. > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R500 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] and here debugging was re-enabled after the problem has occurred. > [drm:pid6216:drm_ioctl] returning 4 > [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, > auth=1 > [drm:pid6216:drm_ioctl] returning 4 > [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, > au
Re: Xorg hangs with drmwtq in 7.2-RELEASE
On Tuesday 12 May 2009 08:17:51 am Robert Noland wrote: > On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote: > > On Friday 08 May 2009 03:31:04 pm Robert Noland wrote: > > > In order to guess what might be causing this, drm debugging needs to be > > > enabled before the hang, so that we can hopefully figure out what leads > > > up to the hung GPU. > > > > I'm not able to do that, but I did manage to get debug turned on and > > dmesg captured early enough to catch some additional information. I've > > place the full file online at http://www.usermode.org/misc/dmesg.txt, but > > am including some snippets here. Hopefully this is enough to move > > forward. > > > > -- > > David Johnson > > This trace still looks odd... This should have been a single trace, with debugging turned after X was hung. I turned debug on once, grabbed output of dmesg, then rebooted. 1) Run script to launch four windows in rapid succession. 2) Only two windows manage to make it up before X hangs. 3) Switch over to laptop, which is ssh'd into system 4) sysctl hw.drm.0.debug=1 5) dmesg > dmesg.txt 6) Done I may have made a mistake though, and briefly turned on debugging earlier in the session. I'll get another trace this evening when I have time, to double check. p.s. I've put 7.1-STABLE from March 13th on a different partition. I will add in commits until it breaks, to help narrow it down. I'm fairly sure it was something on the 15th or 16th. -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Tuesday 12 May 2009 11:52:29 am David Johnson wrote: > I may have made a mistake though, and briefly turned on debugging earlier > in the session. I'll get another trace this evening when I have time, to > double check. Yup, I must have turned on debugging earlier in that session. All I can get now is that repetitous drm_ioctl. -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
I don't know if this helps pinpointing my problem, but when I unload the drm module, I get the following message: May 15 19:57:52 radagast kernel: vgapci0: child drm0 requested pci_disable_busmaster May 15 19:57:52 radagast kernel: drm0: detached May 15 19:57:52 radagast kernel: Warning: memory type drm_bufs leaked memory on destroy (4 allocations, 128 bytes leaked). After this I can load the radeon and drm modules, but X will not start, complaining about no screen found. -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
After much rebuilding and testing, I have narrowed down the introduction of this bug to commit #189855. Most of this commit is related to r600/700 chips, but there are other changes. I don't understand the code and can't see anything obvious. But it is a place to start. Does this help any? Or should I keep banging my head against the wall? -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Sun, 2009-05-17 at 13:54 -0700, David Johnson wrote: > After much rebuilding and testing, I have narrowed down the introduction of > this bug to commit #189855. Most of this commit is related to r600/700 chips, > but there are other changes. I don't understand the code and can't see > anything obvious. But it is a place to start. > > Does this help any? Or should I keep banging my head against the wall? I'll review that commit... Hopefully before brain damage sets in for either of us... robert. -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: Xorg hangs with drmwtq in 7.2-RELEASE
I haven't heard anything on this in three weeks. I filed a bug report, but no acceptance yet. Does this imply that there is no intention to fix this problem? What is happening with this? Am I even posting to the right list? I'm completely in the dark here. -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Sun, 2009-05-31 at 00:12 -0700, David Johnson wrote: > I haven't heard anything on this in three weeks. I filed a bug report, but no > acceptance yet. Does this imply that there is no intention to fix this > problem? What is happening with this? Am I even posting to the right list? > I'm > completely in the dark here. Yes, your in the right place... I just can't reproduce it still and so it's problematic to track down. I reviewed the commit that you pointed out, but that is the r6/7xx import commit and involves a lot of code. robert. -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
