Bug 111271
| Summary: | Black stripe on screen with MGAG200 (PowerEdge R320) and modesetting | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Jean-Yves Faye (jean-yves.faye) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | normal | CC: | devzero, ville.syrjala |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
Xorg.0.log (4.4 kernel, disregard kernel command line) kernel config for our Dell R320 (no module) bisect log Picture of screen bisect log dumb patch |
||
Created attachment 201401 [details]
Xorg.0.log (4.4 kernel, disregard kernel command line)
Created attachment 201411 [details]
kernel config for our Dell R320 (no module)
Created attachment 201421 [details]
bisect log
I've ran bisect between 3.10.40 and 3.18, but still present on 4.4
Linux localhost.adm 4.4.0 #21 SMP Mon Jan 25 16:08:56 CET 2016 x86_64 Intel(R) Xeon(R) CPU E5-1410 v2 @ 2.80GHz GenuineIntel GNU/Linux
commit 9125e6186822b2698da17690416cd1b55c030115 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Jun 3 16:10:40 2013 +0300 drm: Add drm_plane_force_disable() just moves code around. So can't see how it could be related to this. Well, actually it does add a plane->fb NULL check, so I suppose that could be somehow related if something else is buggy and clears plane->fb while the plane is still enabled. But actually, the mgag200 driver doesn't even do planes (nor is the hardware even capable of turning off the primary plane independent of the crtc) so not sure why this would have anything to do with the problem. Without a picture it's a bit hard to know, but black horizontal lines at the left edge of the screen has a feel of underruns. I have seen such things plenty of times on my G550 when using the video overlay with eg. 1920x1080 mode with reduced blanking, if the overlay is postioned too close to the left edge of the screen. It's possible the hw cursor might suffer from similar issues. Looking at the driver the hiprilvl computations seem a bit dubious at best. Possibly by tweaking that stuff it might be possible to eliminate the underruns, but no guarantees. Created attachment 201431 [details]
Picture of screen
This was caught on a CRT monitor and is quite visible. The strip follow the mouse cursor on the edge. The white section of screen outside what should be the drawing zone may help you too.
Created attachment 202001 [details] bisect log After trying to printk around this commit, I noticed some strange behavior, just adding debug statements making the stripe disappear. I suspected some side effects in the compilation process. I've redone the bisect using mrproper instead of make clean between builds, copying my .config each time. I use make -j20 too. Bisect results makes much more send now Author: Christopher Harvey <charvey@matrox.com> Date: Wed Jun 5 15:24:26 2013 -0400 drm/mgag200: Hardware cursor support Created attachment 202021 [details]
dumb patch
Some experimentation lead me to this patch, this seems to resolve the problem, but I have no idead what this function should write in the register so I'm hoping for someone here to explain the problem.
there has been major rework in mgag200 since your report, could you perhaps retry with recent 6.1 or 6.6 kernel how that behaves? also mind that there is a patch on the way to get merged soon which fixes an issue cause by the driver rework https://bugzilla.kernel.org/show_bug.cgi?id=217790 |
Created attachment 201391 [details] dmesg I use Xorg with modesetting driver on a R320 PowerEdge Dell server. I've upgraded kernel from 3.10.40 to a newer version. With the upgrade, a black horizontal stripe appears next to the pointer when moving the mouse to the left edge of the screen. The stripe darker and wider on a CRT screen than a LCD screen it seems. I've tested on 4.4 and the problem is still present. I'm using Xorg with the modesetting driver, and the MGAG200 kernel module (dmesg and Xorg.log attached) I've run a git bisect on the kernel and identified the commit causing the regression : # first bad commit: [9125e6186822b2698da17690416cd1b55c030115] drm: Add drm_plane_force_disable() Unfortunately I'm not familiar with the GPU/DRM part of the kernel, so I can't get this any further.