[Bug 70254] [snb dp hotplug] Pipe B, PCH transcoder B FIFO underrun

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Mar 11 13:00:36 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=70254

--- Comment #44 from rubin110 <rubin at starset.net> ---
TL;DR The patch seems to correct my issue, which I've been directed to this bug
after complaining about it on the Intel-gfx list. However my issue isn't
exactly identical. I'm providing compiling instructions for Robert N to verify
with also.

Some months ago I bought a cheap 27" S-IPS display off of ebay. The panel
supports DVI, Displayport, and some others, and its native resolution is QHD
2560x1440. The display shipped from Korea, I plugged it into my Thinkpad X220
running Debian Sid and had a slew of issues. The seller went back and forth
with me on trying to fix the issues, and provided replacement boards for the
inside of the display, but ultimately the seller stalled and the one month
period to request a refund flew by.

There are two issues I encounter...

Through a direct Displayport connection from my X220 to the monitor at full
resolution, if there's a lot of motion on the screen (a full screen video or
scrolling a web page back and forth) for about 60 seconds, the screen will
blank out and return a few times until it acts as though the Displayport cable
has been disconnected and there's no signal. Eventually the display will give
up and go to sleep.

Through Displayport to Dual Link DVI via one of those adapters that requires
power over USB, the display was more usable. During a lot of motion on the
screen it wouldn't blank out, however after about 5 minutes of that all the
pixels on the screen would vibrate together back and forth about 200px
horizontally for half a second. This will repeat anywhere between every 30
seconds to 5 minutes. Again never blanking out.

If I drive the display at a smaller resolution like 1080p, I have no issues.
The same goes with pushing over HDMI, but the max solution here is 1080p
anyhow. Additional I haven't noticed this issue on most actual name brand
displays, namely the higher priced Dell displays.

Recently I was getting fed up with this issue and started looking for a
replacement monitor. After realizing that blowing another $500 sort of sucks,
so I decided to do a little more testing. Using a spare Mac Mini I keep around
for testing, I tested out Displayport to Displayport, playing a 1080p video on
the display at full resolution. I encountered no issues (other than the Mac
Mini simply dropping frames from the large video). Plugging in a spare drive I
keep around with a bootable copy of Windows 7 into my Thinkpad X220, I again
was able to drive the display playing full screen video with zero issues over
Displayport.

Through out all my issues, I was never once able to find any sort of error or
debug output in any logs. This includes kern.log, syslog and Xorg. Due to this
I'm not sure if my issue is the same as Robert N's, and there for I would like
it if he verified the fix too unless the devs here can safely say my issue
described is the same.

So at this point I started to poke people on lists and bug some of my smarter
kernel hacker friends, which has brought me to this bug.

After grabbing a copy of the drm-intel nightly source, applying the patch,
compiling and giving it a spin, I was able to play a full screened video at
full display resolution without issue over Displayport. I left the video
playing for 2 hours, no blank outs, no shaking. I have not tested Dual Link DVI
yet.


My kernel compiling steps, for Robert N:

# Some packages you might need, I'm most likely missing things here that I
already have, you can figure it out
sudo apt-get install libncurses5-dev kernel-package

# Let's make a directory to get messy in
mkdir ~/temp-kernel
cd ~/temp-kernel

# Grab a copy of the patch
wget -O bug70254.patch https://bugs.freedesktop.org/attachment.cgi?id=94766

# Grab a copy of the nightly source, this will take a little while
git clone --depth=1 -b drm-intel-nightly
git://people.freedesktop.org/~danvet/drm-intel

# Apply the patch
cd drm-intel
patch -p1 < ../bug70254.patch

# Copy your current kernel's config, this'll be different for you
cp /boot/config-3.12-1-amd64 .config

# Get the config ready for the new kernel, once this opens simply select save,
save it at .config, and exit
make menuconfig

# We're now going to compile using fakeroot make-kpkg. This is a more sensible
Debian way of putting together and installing kernels. In the end you should
have two deb packages which you can later on apt-get remove easily if you want
to. This (should) also takes care of updating grub.

# Provide the number of cores you want to dedicate to compiling, if you don't
know just select 1
export CONCURRENCY_LEVEL=3

# Start compiling and build a pair of deb packages for you, this will take a
long while
fakeroot make-kpkg --initrd
--append-to-version=-custom-drm-intel-nightly-bug70254 kernel-image
kernel-headers modules_image

# You should now have two deb packages, linux-image and linux-headers, named
along with the version number
cd ..
ls -la

# Install the new packages, which should be the only two debs in the current wo
sudo dpkg -i linux-*.deb

# Reboot , there is a chance you need to select the kernel by hand when grub
pops up during boot. I'm not sure how that all works in the Ubuntu world but
I'm sure you can figure it out.

# When you've booted up, verify you've running they new patched kernel
uname -a

# I see: Linux lines 3.13.0-custom01+ #1 SMP Tue Mar 11 10:51:56 PDT 2014
x86_64 GNU/Linux
# Test away!


With all that being said if this patch gets accepted, approximately how soon
till it might end up in a stable release of mainline kernel? Though honestly
this current nightly kernel seems to be running a-ok thus far.

Additionally if I got a new fangled Lenovo dock with two Displayports, will I
be able to drive two of the same displays at full resolution with this patch? I
do understand I'll have to disable the laptop display to make the second
external work.

Thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140311/54c2cfa2/attachment.html>


More information about the intel-gfx-bugs mailing list