Bug 64332

Created attachment 78996 [details]
xrandr --verbose output

Created attachment 78997 [details]
Xorg log

Created attachment 78998 [details]
dmesg starting with boot option drm.debug=0x06

Im having the same problem with the same laptop. I´ve tried the latest -nightly builds but that didnt help.

I also filed a bug report (before i saw yours) bug 64334.

*** Bug 64334 has been marked as a duplicate of this bug. ***

Hello,

 

i have a Samsung NP900x3e-06DE wih Core i7.

i installed ubuntu 13.04 and i have the same issue with black/white lines on display.

i can see the black/white lines on windows 8 too.

After shutting down laptop and wait an hour or so the lines are disappear.

nomodeset work for me but i can't change brightness via FN-Key or system.

the last kernel 3.9 doesn't solve this issue.

same issue with last ubuntu 13.10 release too.
 

Please help, i like Ubuntu more than windows 8.

 

Thanks

 

cpcpcp

Created attachment 79077 [details]
picture lines windows 8

Created attachment 79078 [details]
picture lines ubuntu 13.04

This is for Urs, murmlos, and cpcpcp:

(In reply to comment #0)
> move with it or disappear. Strangely, if a line was present for long, it can
> "stay" on the screen across reboots, being even visible in BIOS and in
> Windows 8 if I reboot in the other OS. Turning the machine totally off and
> letting it like that for a long time makes the artifact disappear.

Does booting to Windows ever cause the lines to appear if they were not previously present? I.e. is it only the Linux driver that makes them show up, or not?

> Starting the machine with kernel option noreboot (and also noacpi) makes the
> bug disappear. (Xorg starts using the FBDEV vesa driver)

Does using a lower resolution help?


Please try the drm-intel-nightly branch of http://cgit.freedesktop.org/~danvet/drm-intel/ - specifically I'm wondering if

commit a65851af59387146a28a928c3e7bb17dabc5db72
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Apr 23 15:03:34 2013 +0300

    drm/i915: Make data/link N value power of two

might help this.

No, Windows does not generate these artifacts. So yes its only the linux driver that causes this.

Lowering the resolution in general does not help. However when i tried 640x480 i waited almost 15 minutes and no artifact had appeared. When switching to something higher like 1024x768  the lines appeared almost instantly. 

I have tried the drm-nightly and it does not help :/ 


(In reply to comment #9)
> This is for Urs, murmlos, and cpcpcp:
> 
> (In reply to comment #0)
> > move with it or disappear. Strangely, if a line was present for long, it can
> > "stay" on the screen across reboots, being even visible in BIOS and in
> > Windows 8 if I reboot in the other OS. Turning the machine totally off and
> > letting it like that for a long time makes the artifact disappear.
> 
> Does booting to Windows ever cause the lines to appear if they were not
> previously present? I.e. is it only the Linux driver that makes them show
> up, or not?
> 
> > Starting the machine with kernel option noreboot (and also noacpi) makes the
> > bug disappear. (Xorg starts using the FBDEV vesa driver)
> 
> Does using a lower resolution help?
> 
> 
> Please try the drm-intel-nightly branch of
> http://cgit.freedesktop.org/~danvet/drm-intel/ - specifically I'm wondering
> if
> 
> commit a65851af59387146a28a928c3e7bb17dabc5db72
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Tue Apr 23 15:03:34 2013 +0300
> 
>     drm/i915: Make data/link N value power of two
> 
> might help this.

same issue here with ubuntu 13.10, nomodeset helps in the meantime, but restricts the usage of the machine. 

Let me know if I can help by posting configs and whatnots.

Sedrik

I have tried with ubuntu 12.04, 12.10 and 13.04 and I still haven't found a way around this problem except for using nomodeset...

(In reply to comment #10)
> No, Windows does not generate these artifacts. So yes its only the linux
> driver that causes this.
> 
> Lowering the resolution in general does not help. However when i tried
> 640x480 i waited almost 15 minutes and no artifact had appeared. When
> switching to something higher like 1024x768  the lines appeared almost
> instantly. 
> 
> I have tried the drm-nightly and it does not help :/ 

Please provide dmesg with drm.debug=0xe running drm-intel-nightly.

Urs' dmesg on 3.8 has some link training failures, but we've done some fixes since, so a new one might be useful.

Are you all experiencing this on Samsung NP900x3e?

(In reply to comment #14)
> Are you all experiencing this on Samsung NP900x3e?

Sorry if I wasn't clear about that - I am indeed using that laptop.

Just a guess to rule out one possibility: does the problem occur with i915.i915_enable_fbc=0 module parameter?

(In reply to comment #14)
> Are you all experiencing this on Samsung NP900x3e?

I can confirm this on the Samsung NP9003xe.

(In reply to comment #16)
> Just a guess to rule out one possibility: does the problem occur with
> i915.i915_enable_fbc=0 module parameter?

I have just tried and the problem persists with that option. It seems like the first couple of lines of pixels at the top of the screen are most affected. I am not sure how I am going to explain this, but it also seems like that specific area is impacted by whatever happens in the area below. For example I have just noticed that if I move a window (by clicking on the title and not releasing it, but moving it around), the area on top of the screen is directly impacted (looks like there is a reduced mapping of the pixels between these 2 areas).


Thanks for your help :)(In reply to comment #16)
> Just a guess to rule out one possibility: does the problem occur with
> i915.i915_enable_fbc=0 module parameter?


I have just tried and the problem persists with that option. It seems like the first couple of lines of pixels at the top of the screen are most affected. 

I am not sure how I am going to explain this, but it also seems like that specific area is impacted by whatever happens in the area below. For example I have just noticed that if I move a window (by clicking on the title and not releasing it, but moving it around), the area on top of the screen is directly impacted (looks like a reduced mapping of the pixels exists between these 2 areas).


Thanks for your help, and let me know if you need more info/tests :)

Created attachment 79254 [details]
dmesg drm.debu=0xe -nightly 5 may

Dmesg drm.debug=0xe

The link training looks suspicious:

[    9.709342] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
[    9.709347] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle
[    9.709357] [drm:ironlake_wait_panel_status], mask b800000f value 00000000 status 00000000 control abcd0000
[    9.709366] [drm:ironlake_edp_panel_vdd_on], PP_STATUS: 0x00000000 PP_CONTROL: 0xabcd0008
[    9.709368] [drm:ironlake_edp_panel_vdd_on], eDP was not running
[    9.765619] [drm:intel_dp_set_signal_levels], Using signal levels 09000000
[    9.767082] [drm:intel_dp_set_signal_levels], Using signal levels 0c000000
[    9.768537] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[    9.770000] [drm:intel_dp_set_signal_levels], Using signal levels 09000000
[    9.771453] [drm:intel_dp_set_signal_levels], Using signal levels 0c000000
[    9.772900] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[    9.774341] [drm:intel_dp_set_signal_levels], Using signal levels 09000000
[    9.775778] [drm:intel_dp_set_signal_levels], Using signal levels 0c000000
[    9.777214] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[    9.778650] [drm:intel_dp_set_signal_levels], Using signal levels 09000000
[    9.780093] [drm:intel_dp_set_signal_levels], Using signal levels 0c000000
[    9.781529] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[    9.782967] [drm:intel_dp_set_signal_levels], Using signal levels 09000000
[    9.784409] [drm:intel_dp_set_signal_levels], Using signal levels 0c000000
[    9.785842] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[    9.787314] [drm:intel_dp_start_link_train], too many full retries, give up
[    9.787317] [drm:ironlake_edp_panel_on], Turn eDP power on
[    9.787321] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle
[    9.787329] [drm:ironlake_wait_panel_status], mask b800000f value 00000000 status 00000000 control abcd0008
[    9.787335] [drm:ironlake_wait_panel_on], Wait for panel power on
[    9.787342] [drm:ironlake_wait_panel_status], mask b000000f value 80000008 status 0000000a control abcd000b
[   10.039218] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
[   10.039230] [drm:ironlake_panel_vdd_off_sync], PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd0003
[   10.062561] [drm:intel_dp_set_signal_levels], Using signal levels 0e000000
[   10.064366] [drm:intel_dp_complete_link_train], Channel EQ done. DP Training successfull

I´ll take your word for it ;)

Let me know if i you want me to try anything or need additional logs.

It might be useless information but i thought i'd share.

The artifacts seem to be linked to high contrast areas. So running chrome with google.com on a bright background image generates far less artifacts than running a black terminal window on a bright background.

Btw, is there anything i should test/try? I'm eager to help out if it leads to a bug-free driver ;)

Please provide a register dump using intel_reg_dumper when the problem occurs:
https://01.org/linuxgraphics/documentation/using-intel-reg-dumper-0

Created attachment 79621 [details]
intel_reg_dump

intel_reg_dump

Was the dump i attached useful in anyway? Do you need more logs or is there anything else that i can do to help solve this issue?

same here - anything I can do to help, let me know.

I am also experiencing problems with the 900X3E in Ubuntu 12.04.

I dont know whether this is helpful: The lines also appear in Windows 7, as long as the standard windows graphics driver is used. Once the Intel driver is installed, the lines disappear.

Hi guys,

Sorry I didn't show signs of life, I was traveling for work for a couple of weeks, hadn't access to my laptop for a while.

I came back, updated my machine to latest debian-sid, problem is still there.

So to answer some questions:
* problem is present with i915.i915_enable_fbc=0
* Never saw the problem appear under Windows by itself. Starting linux in a configuration that shows the bug and then rebooting under windows makes the problem visible under windows.
* Changing the resolution doesn't seem to have an effect.
* Dunno if different modelines could help? Looked to me like the one calculated with the vesa driver and the ones from the intel driver were different. Don't know if it's relevant, I'm not the expert.

What information can I provide? I'll attach the reg dump and dmesg. 
(After I reboot, now, I get "Couldn't map MMIO region: Resource temporarily unavailable". I did boot with drm.debug=0xe and i915.i915_enable_fbc=0. From other bugs, might be the case that my intel_reg_dumper is to old?)

I can look how to buid the drm nightly by hand for my debian system and get more logs if necessary.

I am facing the same problems. I am running 12.10 Ubuntu 64 bit. Starting with noreboot nomodeset xforcevesa noacpi did not help. This seems to be a problem that is affecting most/all Ubuntu(xserver?) users.

I found this information:
http://communities.intel.com/thread/30096

still have same on Fedora, tested with 3 other Devices from Type 900X3E-A02.

(In reply to comment #28)

> What information can I provide? I'll attach the reg dump and dmesg. 
> (After I reboot, now, I get "Couldn't map MMIO region: Resource temporarily
> unavailable". I did boot with drm.debug=0xe and i915.i915_enable_fbc=0. From
> other bugs, might be the case that my intel_reg_dumper is to old?)
> 

Is this with the latest intel-gpu-tools (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools)?

You have to be root to run the dumper IIRC.

Also, please try quick_dump if the above won't work. From the clone directory:
sudo ./tools/quick_dump/quick_dump.py -a

I got this:
[root@antal intel-gpu-tools]# ./tools/quick_dump/quick_dump.py -a
Traceback (most recent call last):
  File "./tools/quick_dump/quick_dump.py", line 8, in <module>
    import chipset
ImportError: No module named 'chipset'

(In reply to comment #32)
> I got this:
> [root@antal intel-gpu-tools]# ./tools/quick_dump/quick_dump.py -a
> Traceback (most recent call last):
>   File "./tools/quick_dump/quick_dump.py", line 8, in <module>
>     import chipset
> ImportError: No module named 'chipset'


Hmm, and you've done a ./autogen.sh && make? 
Can you show something like: ls -lrt tools/quick_dump/*chipset*

Was the reg_dump i attached in comment 24 useful? Has there been any development in the nightly-builds that might affect this issue that i can try?

(In reply to comment #33)
> (In reply to comment #32)
> > I got this:
> > [root@antal intel-gpu-tools]# ./tools/quick_dump/quick_dump.py -a
> > Traceback (most recent call last):
> >   File "./tools/quick_dump/quick_dump.py", line 8, in <module>
> >     import chipset
> > ImportError: No module named 'chipset'
> 
> 
> Hmm, and you've done a ./autogen.sh && make? 
> Can you show something like: ls -lrt tools/quick_dump/*chipset*

I'm sorry. I wasn't aware of doing this. On this machine i don't have all the tools. So i will before i install this ask if its helpful to provide this information too?

Created attachment 80410 [details]
reg dump when horizontal lines are visible.

Additional reg dump should not hurt.

Created attachment 80436 [details]
Intel reg dump when horizontal lines present

I finally got around to find out what was needed to get intel_gpu_tools to compile.

I ran
$ sudo ./tools/intel_reg_dumper > ~/intel_reg_dump.txt
See attachment for result.

Running the above command also shows this on stderr:
Couldn't find path to dri/debugfs entry
i915 loaded; not proceeding

Please tell me if I need to do anything else needed?

Many thanks,

Urs

Ah, as a side note I updated my Debian Sid system to:
$ uname -a
Linux shimmer 3.9-1-amd64 #1 SMP Debian 3.9.4-1 x86_64 GNU/Linux

Next thing on my list: compile the nigthly git for drm-intel

Also happens on Arch with 900X3E-A03. My question is is this because of mesa or because of the xf86-video-intel driver?

(In reply to comment #40)
> Also happens on Arch with 900X3E-A03. My question is is this because of mesa
> or because of the xf86-video-intel driver?

Neither. It's a combination of this particular machine and the kernel.

Any kind of timeline for a patched kernel?

We have no idea how the hardware can fail so badly that even a reset doesn't restore it.

So I can't expect a fixed kernel in a week or so? Because I just bought one and without proper video it's just sort of an expensive piece of hardware.

Due to the persistent nature of the bug, it is likely to be in the panel itself. Which suggests that one of our panel timing or aux controls is out of spec.An alternative is to avoid us doing any modesetting on the panel, and just use the mode as setup by the bios (presuming you have an EFI BIOS that sets up a native mode).

How does that work?

I agree with Felix that it would be annoying if that would not be fixed. Most annoyed would be my wife (because it's her laptop) who would need to run Windows on the thing. 

> Which suggests that one of our panel timing or aux controls is out of spec.

Can one ask somehow the Windows driver what timing it is using to drive the panel and then do it likewise? I am quite fluent in "patch < foo.patch; configure; make install" an can try builds, but I have very little clue about the internals of a graphics driver.

Regards,
Harald.

PS: Some webpages suggest that as a workaround you run nomodeset (which results in that vesa ist tried) on the thing instead, but if I try that I get a text-only console (Ubuntu 13.04). No fun.

Not only nomodeset, also forcevesa also check whether your xorg "Device" Section has any kind of Driver Setting that will also have to be set to vesa.


(In reply to comment #47)
> I agree with Felix that it would be annoying if that would not be fixed.
> Most annoyed would be my wife (because it's her laptop) who would need to
> run Windows on the thing. 
> 
> > Which suggests that one of our panel timing or aux controls is out of spec.
> 
> Can one ask somehow the Windows driver what timing it is using to drive the
> panel and then do it likewise? I am quite fluent in "patch < foo.patch;
> configure; make install" an can try builds, but I have very little clue
> about the internals of a graphics driver.
> 
> Regards,
> Harald.
> 
> PS: Some webpages suggest that as a workaround you run nomodeset (which
> results in that vesa ist tried) on the thing instead, but if I try that I
> get a text-only console (Ubuntu 13.04). No fun.

Has any of you tried the latest drivers and kernels?

I tried to patch the debian source kernel last thursday (3.9) with the latest intel-drm-testing. Being no expert in these kind of manipulatons, I wasn't sure I did patch everything correctly.

Today, I installed the lates kernel from debian experimental, version 3.10-rc4.

In both cases, I seem to have gotten rid of the horizontal lines.

Looking at Xorg.0.log, it looks like it loaded the intel drm driver. 

So, short of me making a dumb mistake that disabled the intel driver without me noticing, it looks like it's fixed. Can anyone else reproduce it on his machine?

I'll attach my Xorg.0.log. Tell me if you have any questions to ascertain that it works and identify what makes it work.

Thanks,

Urs

Created attachment 80591 [details]
Xorg.log on Debian with Linux 3.10-rc4, doesn't show horizontal lines

I can now confirm that my horizontal stripes are GONE!!!! after installing kernel 3.10rc5. Haven't configured anything to get this to work except upgrading from kernel 3.9 to 3.10

I installed a 3.10 rc5 kernel on my Ubuntu 13.04 and it did NOT help. Do you have any idea what version of what component actually makes a difference?

Thanks,
Harald.

Update to the comment above: Even if the lines were not gone after the reboot with the new kernel, there are no new lines and the old ones seem to disappear one by one over time. It kindof "heals". This is a VERY strange bug, but maybe fixed after all. Just to let you all know, don't despair if the reboot does not fix the lines promptly. Shuffle around some windows and see.

Harald.

(In reply to comment #53)
> Update to the comment above: Even if the lines were not gone after the
> reboot with the new kernel, there are no new lines and the old ones seem to
> disappear one by one over time. It kindof "heals". This is a VERY strange
> bug, but maybe fixed after all. Just to let you all know, don't despair if
> the reboot does not fix the lines promptly. Shuffle around some windows and
> see.
> 
> Harald.

So if you reboot are there still any horizontal lines appearing in high contrast/black background images?

I have turned my device completely off, and boot systemrescuecd and the lines are disappearing. After that boot as usual your os. The lines should gone now.

Dissappearing, meaning that they are not gone from the start?

I've tried 3.10-rc5 from kernel.org and the latest intel-drm-nightly.

And i can confirm that the lines are indeed gone!

Bloody fantastic! :)

As someone who is not fluent in building the kernel from source, could any of you tell me if I need to do that and patch with intel-drm-nightly, or if I could just grab these and install http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/ ?

If I need to patch and build the kernel myself, does anyone have a link to a guide? All the search terms I have tried so far are overloaded and yield little usable results :(

Looking forward to getting rid of those lines :)

Yes, you can download and install the newest mainline kernel build and install it using dpkg. There is a good tutorial at https://wiki.ubuntu.com/Kernel/MainlineBuilds .
(In reply to comment #58)
> As someone who is not fluent in building the kernel from source, could any
> of you tell me if I need to do that and patch with intel-drm-nightly, or if
> I could just grab these and install
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/ ?
> 
> If I need to patch and build the kernel myself, does anyone have a link to a
> guide? All the search terms I have tried so far are overloaded and yield
> little usable results :(
> 
> Looking forward to getting rid of those lines :)

(In reply to comment #59)
> Yes, you can download and install the newest mainline kernel build and
> install it using dpkg. There is a good tutorial at
> https://wiki.ubuntu.com/Kernel/MainlineBuilds .

Thank you.

This fixed the problem for me as well.

Thank you all for putting in all the effort for this

Ok, it sounds like this bug is fixed for real indeed in 3.10-rc5, but we seem to have no idea why exactly :( And since it's pretty time-consuming to decide whether a kernel version actually works I guess doing a reverse bisect won't be feasible.

So closing as "bug fixed, mystery unsolved". Thanks everyone for reporting and testing and please reopen in case this breaks again.

Worked for me too. Had the problem with Linux Mint Olivia 15 (cinnamon), Ubuntu 12.04.2 (gnome i think) and Knoppix 7.2 (KDE). Upgraded on my linux mint, and lines gone. Thank God! And you guys!