Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)
Michel, could you remind me what is that xxx_SAVE bit ? best Vladimir Dergachev On Sun, 3 Feb 2003, Michel [ISO-8859-1] Dänzer wrote: > On Son, 2003-02-02 at 12:51, Michel Dänzer wrote: > > On Son, 2003-02-02 at 06:09, hy0 wrote: > > > > > > Judging from current situation, we probably should take > > > RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the > > > cursor routines. > > > > I'd prefer fixing those functions instead. After some more thought, > > polling for _VBLANK_SAVE in both is probably safest for 4.3.0. > > Here's what I'm talking about, what do you think? > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility)
- Original Message - From: "Michel Dänzer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "hy0" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, February 02, 2003 7:31 PM Subject: Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility) > On Son, 2003-02-02 at 12:51, Michel Dänzer wrote: > > On Son, 2003-02-02 at 06:09, hy0 wrote: > > > > > > Judging from current situation, we probably should take > > > RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the > > > cursor routines. > > > > I'd prefer fixing those functions instead. After some more thought, > > polling for _VBLANK_SAVE in both is probably safest for 4.3.0. > > Here's what I'm talking about, what do you think? > Yes, this should work. Thanks. Hui > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility)
On Son, 2003-02-02 at 12:51, Michel Dänzer wrote:
> On Son, 2003-02-02 at 06:09, hy0 wrote:
> >
> > Judging from current situation, we probably should take
> > RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the
> > cursor routines.
>
> I'd prefer fixing those functions instead. After some more thought,
> polling for _VBLANK_SAVE in both is probably safest for 4.3.0.
Here's what I'm talking about, what do you think?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v
retrieving revision 1.24
diff -p -u -r1.24 radeon_reg.h
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h 2003/01/17 19:54:03 1.24
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h 2003/02/03 03:28:42
@@ -307,6 +307,10 @@
#define RADEON_CRTC2_PITCH 0x032c
#define RADEON_CRTC_STATUS 0x005c
# define RADEON_CRTC_VBLANK_SAVE (1 << 1)
+# define RADEON_CRTC_VBLANK_SAVE_CLEAR (1 << 1)
+#define RADEON_CRTC2_STATUS 0x03fc
+# define RADEON_CRTC2_VBLANK_SAVE (1 << 1)
+# define RADEON_CRTC2_VBLANK_SAVE_CLEAR (1 << 1)
#define RADEON_CRTC_V_SYNC_STRT_WID 0x020c
# define RADEON_CRTC_V_SYNC_STRT(0x7ff << 0)
# define RADEON_CRTC_V_SYNC_STRT_SHIFT 0
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.84
diff -p -u -r1.84 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2003/01/30 05:31:31 1.84
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2003/02/03 03:28:46
@@ -671,9 +675,13 @@ void RADEONWaitForVerticalSync(ScrnInfoP
unsigned char *RADEONMMIO = info->MMIO;
inti;
-OUTREG(RADEON_GEN_INT_STATUS, RADEON_VSYNC_INT_AK);
-for (i = 0; i < RADEON_TIMEOUT; i++) {
- if (INREG(RADEON_GEN_INT_STATUS) & RADEON_VSYNC_INT) break;
+/* Clear the CRTC_VBLANK_SAVE bit */
+OUTREG(RADEON_CRTC_STATUS, RADEON_CRTC_VBLANK_SAVE_CLEAR);
+
+/* Wait for it to go back up */
+for (i = 0; i < RADEON_TIMEOUT/1000; i++) {
+ if (INREG(RADEON_CRTC_STATUS) & RADEON_CRTC_VBLANK_SAVE) break;
+ usleep(1);
}
}
@@ -683,10 +691,14 @@ void RADEONWaitForVerticalSync2(ScrnInfo
RADEONInfoPtr info = RADEONPTR(pScrn);
unsigned char *RADEONMMIO = info->MMIO;
inti;
+
+/* Clear the CRTC2_VBLANK_SAVE bit */
+OUTREG(RADEON_CRTC2_STATUS, RADEON_CRTC2_VBLANK_SAVE_CLEAR);
-OUTREG(RADEON_GEN_INT_STATUS, RADEON_VSYNC2_INT_AK);
-for (i = 0; i < RADEON_TIMEOUT; i++) {
- if (INREG(RADEON_GEN_INT_STATUS) & RADEON_VSYNC2_INT) break;
+/* Wait for it to go back up */
+for (i = 0; i < RADEON_TIMEOUT/1000; i++) {
+ if (INREG(RADEON_CRTC2_STATUS) & RADEON_CRTC2_VBLANK_SAVE) break;
+ usleep(1);
}
}
Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility)
On Son, 2003-02-02 at 06:09, hy0 wrote: > > > On Mon, 2003-01-27 at 10:14, Nathaniel Gray wrote: > > > """ > > > I guess this doesn't happen with DRI disabled? Looks like pure luck to > > > me that RADEONWaitForVerticalSync() ever returns when the DRM handles > > > vertical blank interrupts. I'll look into fixing that if noone beats me > > > to it. > > > """ > > > > > > True, the problem doesn't occur unless DRI is enabled. > > > > This patch works for me with DRI enabled, can you (or anyone seeing the > > problem, for that matter) try it? > > > > There could still be an even worse problem if the vertical blank > > interrupt stops working for some reason (I've seen that happen after > > some weird 3D client crashes). Another possibility would be polling the > > CRTC_VBLANK_SAVE bit in the CRTC_STATUS register. Kevin, Hui, anyone > > interested, what do you think? > > It appears RADEONWaitForVerticalSync can cause some race conditon with DRM > WaitVBlank routine. Not specifically with that, the DRM installs an interrupt handler which acknowledges the interrupt flag. It's sheer luck that the X driver ever sees the flag before it's acknowledged. > If this is the case, Michel's patch should work. Since > the display driver can also use CRTC2 (different from CRTC1's vblank > condition) when DRI is enabled, this makes things more complicated. The DRM doesn't deal with the CRTC2 vblank interrupt (yet :) so this isn't urgent. > Judging from current situation, we probably should take > RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the > cursor routines. I'd prefer fixing those functions instead. After some more thought, polling for _VBLANK_SAVE in both is probably safest for 4.3.0. > The WaitForVerticalSync functions were added for avoiding > flickering problem when switching between ARGB and BW cursors. BTW, I still see that problem (if very rarely) with WaitForVerticalSync, is the idea to update the registers during vertical retrace? > This problem is much less severe than having WaitForVerticalSync to time out, > particularly if ARGB cursor is not used as default (has this been decided?). I hope there will be a less disruptive ARGB theme by default. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)
- Original Message - From: "Michel Dänzer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 01, 2003 6:39 PM Subject: Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility) > On Mon, 2003-01-27 at 10:14, Nathaniel Gray wrote: > > """ > > I guess this doesn't happen with DRI disabled? Looks like pure luck to > > me that RADEONWaitForVerticalSync() ever returns when the DRM handles > > vertical blank interrupts. I'll look into fixing that if noone beats me > > to it. > > """ > > > > True, the problem doesn't occur unless DRI is enabled. > > This patch works for me with DRI enabled, can you (or anyone seeing the > problem, for that matter) try it? > > There could still be an even worse problem if the vertical blank > interrupt stops working for some reason (I've seen that happen after > some weird 3D client crashes). Another possibility would be polling the > CRTC_VBLANK_SAVE bit in the CRTC_STATUS register. Kevin, Hui, anyone > interested, what do you think? It appears RADEONWaitForVerticalSync can cause some race conditon with DRM WaitVBlank routine. If this is the case, Michel's patch should work. Since the display driver can also use CRTC2 (different from CRTC1's vblank condition) when DRI is enabled, this makes things more complicated. Judging from current situation, we probably should take RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the cursor routines. The WaitForVerticalSync functions were added for avoiding flickering problem when switching between ARGB and BW cursors. This problem is much less severe than having WaitForVerticalSync to time out, particularly if ARGB cursor is not used as default (has this been decided?). We can work this thing out after 4.3 release. Hui > > > """ > > > 2. I was using KDM and after exiting X my machine would lock up as it > > > tried to restart the login screen. I think that even without KDM I > > > couldn't restart X after I started it once. I'm not positive about > > > this though. > > > > Can you verify that? Would be interesting to know. > > """ > > > > Nope, I can't verify it. I guess my system just got into a bad state > > somehow. I'm using 4.2.99.4 right now and have successfully restarted > > X many times. > > So you have verified that it only happens with a display manager. :) > > > I haven't tried using KDM again though. > > Probably still happens with that? One possibility is one or more > processes keeping the DRM open (Qt comes to mind) long enough to prevent > the next server generation from enabling the DRI. That causing a lockup > would still be a bug, but this might give opportunities for workarounds. > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)
On Mon, 2003-01-27 at 10:14, Nathaniel Gray wrote:
> """
> I guess this doesn't happen with DRI disabled? Looks like pure luck to
> me that RADEONWaitForVerticalSync() ever returns when the DRM handles
> vertical blank interrupts. I'll look into fixing that if noone beats me
> to it.
> """
>
> True, the problem doesn't occur unless DRI is enabled.
This patch works for me with DRI enabled, can you (or anyone seeing the
problem, for that matter) try it?
There could still be an even worse problem if the vertical blank
interrupt stops working for some reason (I've seen that happen after
some weird 3D client crashes). Another possibility would be polling the
CRTC_VBLANK_SAVE bit in the CRTC_STATUS register. Kevin, Hui, anyone
interested, what do you think?
> """
> > 2. I was using KDM and after exiting X my machine would lock up as it
> > tried to restart the login screen. I think that even without KDM I
> > couldn't restart X after I started it once. I'm not positive about
> > this though.
>
> Can you verify that? Would be interesting to know.
> """
>
> Nope, I can't verify it. I guess my system just got into a bad state
> somehow. I'm using 4.2.99.4 right now and have successfully restarted
> X many times.
So you have verified that it only happens with a display manager. :)
> I haven't tried using KDM again though.
Probably still happens with that? One possibility is one or more
processes keeping the DRM open (Qt comes to mind) long enough to prevent
the next server generation from enabling the DRI. That causing a lockup
would still be a bug, but this might give opportunities for workarounds.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c,v
retrieving revision 1.30
diff -p -u -r1.30 xf86drm.c
--- programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c 2002/12/14 02:44:06 1.30
+++ programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c 2003/02/02 02:21:15
@@ -1105,6 +1105,7 @@ int drmWaitVBlank(int fd, drmVBlankPtr v
do {
ret = ioctl(fd, DRM_IOCTL_WAIT_VBLANK, vbl);
+ vbl->request.type &= ~DRM_VBLANK_RELATIVE;
} while (ret && errno == EINTR);
return ret;
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h,v
retrieving revision 1.6
diff -p -u -r1.6 drm_dma.h
--- programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h 2003/01/29 23:00:43 1.6
+++ programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h 2003/02/02 02:21:16
@@ -628,6 +628,7 @@ int DRM(wait_vblank)( DRM_IOCTL_ARGS )
switch ( vblwait.request.type & ~_DRM_VBLANK_FLAGS_MASK ) {
case _DRM_VBLANK_RELATIVE:
vblwait.request.sequence += atomic_read( &dev->vbl_received );
+ vblwait.request.type &= ~_DRM_VBLANK_RELATIVE;
case _DRM_VBLANK_ABSOLUTE:
break;
default:
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.84
diff -p -u -r1.84 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2003/01/30 05:31:31 1.84
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2003/02/02 02:21:24
@@ -664,13 +668,26 @@ static int RADEONINPAL(int idx)
}
#endif
-/* Wait for vertical sync on primary CRTC */
+/* Wait for vertical sync on primary CRTC; try using the DRM ioctl for this
+ * and poll if that fails
+ */
void RADEONWaitForVerticalSync(ScrnInfoPtr pScrn)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
unsigned char *RADEONMMIO = info->MMIO;
inti;
+#ifdef XF86DRI
+if (info->directRenderingEnabled && info->irq) {
+ drmVBlank vbl;
+
+ vbl.request.type = DRM_VBLANK_RELATIVE;
+ vbl.request.sequence = 1;
+
+ if (!drmWaitVBlank(info->drmFD, &vbl)) return;
+}
+#endif
+
OUTREG(RADEON_GEN_INT_STATUS, RADEON_VSYNC_INT_AK);
for (i = 0; i < RADEON_TIMEOUT; i++) {
if (INREG(RADEON_GEN_INT_STATUS) & RADEON_VSYNC_INT) break;
