Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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