Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-27 Thread Jakob Alvermark

On 26 mar 2015, at 22:00, Jakob Alvermark wrote:

 On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
 Hi,
 
 
 Without the attached kernel patch(es), Xorg starts consuming alot of CPU
 and becomes very unresponsive and unusable.
 
 Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
 over and over again with no apparent reason. It doesn't happen when using a
 simple window manager like blackbox. I was not able to use XFCE4 (9-stable
 userland) with 11-current kernel at all, after the latest DRM2 kernel
 updates. It worked fine before the update.
 
 I'm not sure what is causing it. Going through the new DRM2 code
 revealed that a mode sorting function did not take all parameters like
 interlaced or not into account, causing the mode list to be reshuffelled
 every time a new mode scan was done. Not sure if Xorg cares about this
 though.
 
 I got the same problem with XFCE4, Xorg at 100% CPU.
 
 Applied the patch and it works again.

Interestingly, xrandr now lists a lot more available modes than before the DRM 
code update.
I thought it was my cheap TV that only supported 1080i, but it turns out that 
now I can use 1080p@60Hz!

Jakob
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Hans Petter Selasky

On 03/26/15 22:37, Adrian Chadd wrote:

Is there a PR filed with this?




There is now:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198936

--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Adrian Chadd
Is there a PR filed with this?


-a


On 26 March 2015 at 14:00, Jakob Alvermark ja...@alvermark.net wrote:
 On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
 Hi,


 Without the attached kernel patch(es), Xorg starts consuming alot of CPU
 and becomes very unresponsive and unusable.

 Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
 over and over again with no apparent reason. It doesn't happen when using a
 simple window manager like blackbox. I was not able to use XFCE4 (9-stable
 userland) with 11-current kernel at all, after the latest DRM2 kernel
 updates. It worked fine before the update.

 I'm not sure what is causing it. Going through the new DRM2 code
 revealed that a mode sorting function did not take all parameters like
 interlaced or not into account, causing the mode list to be reshuffelled
 every time a new mode scan was done. Not sure if Xorg cares about this
 though.

 I got the same problem with XFCE4, Xorg at 100% CPU.

 Applied the patch and it works again.

 Jakob


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Jakob Alvermark
On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
 Hi,


 Without the attached kernel patch(es), Xorg starts consuming alot of CPU
 and becomes very unresponsive and unusable.

 Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
 over and over again with no apparent reason. It doesn't happen when using a
 simple window manager like blackbox. I was not able to use XFCE4 (9-stable
 userland) with 11-current kernel at all, after the latest DRM2 kernel
 updates. It worked fine before the update.

 I'm not sure what is causing it. Going through the new DRM2 code
 revealed that a mode sorting function did not take all parameters like
 interlaced or not into account, causing the mode list to be reshuffelled
 every time a new mode scan was done. Not sure if Xorg cares about this
 though.

I got the same problem with XFCE4, Xorg at 100% CPU.

Applied the patch and it works again.

Jakob


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Hans Petter Selasky

On 03/26/15 22:37, Adrian Chadd wrote:

Is there a PR filed with this?



No, do you want me to make one?

--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-23 Thread Hans Petter Selasky

Hi,

Without the attached kernel patch(es), Xorg starts consuming alot of CPU 
and becomes very unresponsive and unusable.


Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR 
over and over again with no apparent reason. It doesn't happen when 
using a simple window manager like blackbox. I was not able to use XFCE4 
(9-stable userland) with 11-current kernel at all, after the latest DRM2 
kernel updates. It worked fine before the update.


I'm not sure what is causing it. Going through the new DRM2 code 
revealed that a mode sorting function did not take all parameters like 
interlaced or not into account, causing the mode list to be reshuffelled 
every time a new mode scan was done. Not sure if Xorg cares about this 
though.


I can test patches if you have other suggestions.

--HPS

diff --git a/sys/dev/drm2/drm_crtc.c b/sys/dev/drm2/drm_crtc.c
index 318a764..d368e83 100644
--- a/sys/dev/drm2/drm_crtc.c
+++ b/sys/dev/drm2/drm_crtc.c
@@ -1499,15 +1499,18 @@ int drm_mode_getconnector(struct drm_device *dev, void *data,
 		}
 	}
 
-	if (out_resp-count_modes == 0) {
+	list_for_each_entry(mode, connector-modes, head)
+		mode_count++;
+
+	if (mode_count == 0) {
 		connector-funcs-fill_modes(connector,
 	 dev-mode_config.max_width,
 	 dev-mode_config.max_height);
-	}
 
-	/* delayed so we get modes regardless of pre-fill_modes state */
-	list_for_each_entry(mode, connector-modes, head)
-		mode_count++;
+		/* delayed so we get modes regardless of pre-fill_modes state */
+		list_for_each_entry(mode, connector-modes, head)
+			mode_count++;
+	}
 
 	out_resp-connector_id = connector-base.id;
 	out_resp-connector_type = connector-connector_type;
diff --git a/sys/dev/drm2/drm_modes.c b/sys/dev/drm2/drm_modes.c
index 4df8cb1..db06176 100644
--- a/sys/dev/drm2/drm_modes.c
+++ b/sys/dev/drm2/drm_modes.c
@@ -928,6 +928,10 @@ static int drm_mode_compare(void *priv, struct list_head *lh_a, struct list_head
 	if (diff)
 		return diff;
 	diff = b-clock - a-clock;
+	if (diff)
+		return diff;
+	diff = ((b-flags  DRM_MODE_FLAG_INTERLACE) != 0) -
+		((a-flags  DRM_MODE_FLAG_INTERLACE) != 0);
 	return diff;
 }
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-07 Thread Alexander Kabaev
On Tue, 03 Mar 2015 23:33:23 +0100
Jean-S'ebastien P'edron dumbb...@freebsd.org wrote:

 Hi!
 
 Here is a new patch to based on HEAD r279508:
 https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
 
 You can apply it to a Subversion checkout using the following command:
 svn patch drm-update-38.i.patch
 
 There are few changes:
 o  The panic reported by J.R. Oldroyd is fixed, but not the CP
 init problem.
 o  A lock assert was added, suggested by Konstantin Belousov
 
 I had several panics (Stray timeout) with a taskqueue used by TTM,
 but it didn't occur in the past 6 days. Maybe it was a problem
 outside of DRM.
 
 I would like people to test again and report :) If something fails,
 please post a full dmesg, taken after loading the relevant *kms
 module, or the core.txt.$N file if it's a panic.
 
 Hans Petter and Ed, I couldn't reproduce neither of your problems
 (HDMI hotplug events storm and VT-switch misbehaviour). However, they
 both involve callouts, like the Stray timeout panic I had with TTM.
 I suspect there was a transient problem with callouts in HEAD at the
 same time. Could you please test again with this patch and a very
 recent HEAD?
 
 Thank you to everyone!
 
 -- 
 Jean-S'ebastien P'edron
 

Just as a data point, 'stray timeout' happens in clean -current without
new patch as well. So whatever that is, it is not caused by the patch.

-- 
Alexander Kabaev


pgpg0MgLxRxxG.pgp
Description: OpenPGP digital signature


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-07 Thread Sam Fourman Jr.
 Just as a data point, 'stray timeout' happens in clean -current without
 new patch as well. So whatever that is, it is not caused by the patch.

 --
 Alexander Kabaev



I can confirm this, however, when it happens is RARE... it seems like it
happens when I am typing in the address bar of chromium.. im using HEAD
with a RAEDON on amd64

-- 

Sam Fourman Jr.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-04 Thread J.R. Oldroyd
On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron dumbb...@freebsd.org 
wrote:

 Hi!
 
 Here is a new patch to based on HEAD r279508:
 https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
 
 You can apply it to a Subversion checkout using the following command:
 svn patch drm-update-38.i.patch
 
 There are few changes:
 o  The panic reported by J.R. Oldroyd is fixed, but not the CP init
problem.
 o  A lock assert was added, suggested by Konstantin Belousov
 

Tested as requested: svn update to r279508 and applied the 38i patch.
Mixed results.

The first boot, done as a warm reboot command while running 10-stable
shows that the CP init failed again and I am back to the mtx_lock panic.

I then let it auto-reboot back into 10-stable (this is an old
10-stable at the time of r271969 10.1-BETA2 but it is one in which the
ring CP init still works).  That shows it boots fine and ring CP inits
OK - even as a warm reboot after the previous failure.

I then thought to try a power-off cold reboot into r279508.  This works,
both ring CP inits OK and no mtx_lock panic.  In fact, I am using it
now to send this report.

So, perhaps the previous fix for the mtx_lock panic wasn't right, but
just seemed to work because I happened to cold-boot those times.

The pattern that's emerging here is that older (mid-2014) kernels
boot and init fine, warm or cold.  The CP init problem started
somewhere mid-2014.  The mtx_lock panic is new, so I am guessing
related to the drm2-38 update.  BOTH CP init and mtx_lock problems
go away when cold booting.

I've uploaded info here:

http://opal.com/jr/freebsd/panic/r279508M/dmesg.txt
http://opal.com/jr/freebsd/panic/r279508M/core.txt.7

The dmesg shows the three boot sequences with annotations to make it
clear which is which.

Above is system with ATI Radeon RS690 X1270 IGP, RS690.

BTW, I now also have the ring CP init failure on a second system
that was just updated to 10.1-RELEASE-p6.  It has ATI Radeon HD 4200
which is RS780 and it also shows the ring init failure at CAFEDEAD
but in r600_ting_test().  Unfortunately, this system is a production
one so I can't easily play with it.  Note, no mtx_lock panic here.
Fortunately, the graphics not working isn't a problem on this system.

-jr


pgpZ9qNOg7N2y.pgp
Description: OpenPGP digital signature


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-04 Thread Hans Petter Selasky

On 03/03/15 23:33, Jean-Sébastien Pédron wrote:

Hi!

Here is a new patch to based on HEAD r279508:
 https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch

You can apply it to a Subversion checkout using the following command:
 svn patch drm-update-38.i.patch

There are few changes:
 o  The panic reported by J.R. Oldroyd is fixed, but not the CP init
problem.
 o  A lock assert was added, suggested by Konstantin Belousov

I had several panics (Stray timeout) with a taskqueue used by TTM, but
it didn't occur in the past 6 days. Maybe it was a problem outside of DRM.

I would like people to test again and report :) If something fails,
please post a full dmesg, taken after loading the relevant *kms module,
or the core.txt.$N file if it's a panic.

Hans Petter and Ed, I couldn't reproduce neither of your problems (HDMI
hotplug events storm and VT-switch misbehaviour). However, they both
involve callouts, like the Stray timeout panic I had with TTM. I
suspect there was a transient problem with callouts in HEAD at the same
time. Could you please test again with this patch and a very recent HEAD?


1) Callouts are not yet entirely fixed in HEAD yet. Fixes and 
discussions are still ongoing, see D1894. BTW: I'm using:


https://reviews.freebsd.org/D1438

2) Maybe you could consider adding SUBDIR_PARALLEL= to some of the 
drm2 Makefiles?


3) After a lot of digging I found the only way to get flicker free video 
with XVideo using the Intel driver was to configure X.org like this:


Section Device
   Identifier  Device0
   Driver intel
   Option AccelMethod sna
   Option TearFree true
EndSection

Maybe that could be the default?

4) High Xorg usage is not solved:

 1026 root  1  26099M 26928K 915gbr  0   1:03   8.89% Xorg

 1026 root  1 102099M 26936K CPU00   1:52  98.58% Xorg


info: [drm] Initialized drm 1.1.0 20060810
drmn0: Intel IvyBridge (M) on vgapci0
iicbus0: Philips I2C bus on iicbb0 addr 0xff
iic0: I2C generic I/O on iicbus0
iic1: I2C generic I/O on iicbus1
iicbus2: Philips I2C bus on iicbb1 addr 0x0
iic2: I2C generic I/O on iicbus2
iic3: I2C generic I/O on iicbus3
iicbus4: Philips I2C bus on iicbb2 addr 0x0
iic4: I2C generic I/O on iicbus4
iic5: I2C generic I/O on iicbus5
iicbus6: Philips I2C bus on iicbb3 addr 0x0
iic6: I2C generic I/O on iicbus6
iic7: I2C generic I/O on iicbus7
iicbus8: Philips I2C bus on iicbb4 addr 0x0
iic8: I2C generic I/O on iicbus8
iic9: I2C generic I/O on iicbus9
iicbus10: Philips I2C bus on iicbb5 addr 0x0
iic10: I2C generic I/O on iicbus10
iic11: I2C generic I/O on iicbus11
iicbus12: Philips I2C bus on iicbb6 addr 0x0
iic12: I2C generic I/O on iicbus12
iic13: I2C generic I/O on iicbus13
info: [drm] MSI enabled 1 message(s)
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
drmn0: taking over the fictitious range 0xe000-0xf000
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.VGA-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector HDMI-A-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.HDMI-A-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector DP-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.DP-1
info: [drm]   - kern.vt.fb.default_mode
fbd0 on drmn0
VT: Replacing driver vga with new fb.
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
error: [drm:pid1026:gen6_sanitize_pm] *ERROR* Power management 
discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1400, was 1206
info: [drm] GMBUS [gmbus dpd] timed out, falling back to bit banging on 
pin 6


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org