Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)

2003-02-04 Thread Vladimir Dergachev 
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

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)

2003-02-04 Thread Vladimir Dergachev 
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)

2003-02-03 Thread hy0 
- 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)

2003-02-02 Thread Michel Dänzer 
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)

2003-02-02 Thread Michel Dänzer 
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)

2003-02-01 Thread Michel Dänzer 
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;

Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)

2003-02-01 Thread hy0 
- 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