Bug 68651

Summary: [hsw edp] KMS+Intel 9600M on Toshiba C75 A 13Q has discolored lines and flashing
Product: Drivers Reporter: Cyrille Pontvieux (jrd)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED INSUFFICIENT_DATA    
Severity: normal CC: alan, bugzilla, daniel, intel-gfx-bugs, przanoni, rafael.raccuia
Priority: P3    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.12.6, 3.13-rc7, drm-intel-nightly (24ed7daa) Subsystem:
Regression: No Bisected commit-id:
Attachments: Config file of Linux kernel 3.13-rc7
Rendering problem in Linux console (framebuffer)
dmesg when nomodeset used.
dmesg when normal booting (KMS)
Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
dmesg and intel_reg_dumper with different booting parameters with Linux dm_intel nightly branch, commit f5eceab
"intel_reg_read 0x40000 -c 65536" with problems
"intel_reg_read 0x40000 -c 65536" when ok (nomodset+video=efifb)
possible patch
Dithering and Blinking, video URL
L70 registers in VESA mode (works OK until lockscreen/resume)
L70 registers in 'green screen' mode (looks like red and green are swapped)
L70 registers in flicker mode (green lines in console, flashing pixels in X)
L70 dmesg in 'green screen' mode
L70 dmesg in 'flicker' mode

Description Cyrille Pontvieux 2014-01-13 14:34:22 UTC
Created attachment 121821 [details]
Config file of Linux kernel 3.13-rc7

I recently acquired a Toshiba laptop with a Intel Graphics 4600M in it (8086:0416, subsystem 1179:fa82).
This Toshiba system is provided with UEFI (EFI Insyde H2O 1.30).
I compiled and use Linux kernel 3.13-rc7 (config.gz attached). I also tried branch drm-intel-nightly on http://cgit.freedesktop.org/~danvet/drm-intel git repo.
This system is provided with Windows 8.1 OS and the gpu/monitor is working fine under it.
There are strange problems on pixels rendering in Linux, both in the console (framebuffer) and in Xorg.
The problem is that the colors are not "right" depending on the position of the pixel on the screen. For example, on white-on-black text, the white text is never rendered white but with an alternance of red, green, blue (cyan ?) and magenta pixels. If you look far enough, it looks white. There also appear to have maybe one pixel shifting or bluring, hard to tell.
I also attached a photo to better explain the problem. Please zoom on it to see it.

The problem is exactly the same in framebuffer console or in Xorg.
It appears early in the boot process. Before that, the rendering is correct. Linux penguins are shown correctly before a screen reset is done and then the problem appears (when KMS is applied I think).
I also attached the output of dmesg for that case.

If I boot by disabling KMS (with nomodeset), the rendering is ok in
Linux console, but I cannot run Xorg:
  (EE) open /dev/dri/card0: No such file or directory
  (EE) VESA(0): V_BIOS address 0x0 out of range
  (EE) Screen(s) found, but none have a usable configuration.
But maybe this is normal and the Xorg driver now need KMS only. I build latest intel Xorg drivers (2.99.907).
I also attached the output of dmesg for that case.

I could provide more input, or compile a custom/patched kernel to help
correcting the problem.
One more thing: contrary to what occurs recently with some i915 driver
users, my gpu never hangs.
If I connect an external monitor to the VGA port, the rendering is ok on this one.

Regards,
Cyrille Pontvieux.
Comment 1 Cyrille Pontvieux 2014-01-13 14:35:50 UTC
Created attachment 121831 [details]
Rendering problem in Linux console (framebuffer)

Zoom on it to view how the pixels and color rendering are wrong.
Comment 2 Cyrille Pontvieux 2014-01-13 14:36:22 UTC
Created attachment 121841 [details]
dmesg when nomodeset used.
Comment 3 Cyrille Pontvieux 2014-01-13 14:36:44 UTC
Created attachment 121851 [details]
dmesg when normal booting (KMS)
Comment 4 Alan 2014-01-13 15:38:15 UTC
>  (EE) open /dev/dri/card0: No such file or directory
 > (EE) VESA(0): V_BIOS address 0x0 out of range
 > (EE) Screen(s) found, but none have a usable configuration.
 > But maybe this is normal and the Xorg driver now need KMS only. I build latest intel Xorg drivers (2.99.907).
 > I also attached the output of dmesg for that case.


That bit is expected on such a platform - it has no VESA legacy interfaces and is pure UEFI. You may be able to boot and get unaccelerated video using the efifb and frame buffer drive until someone can debug X.
Comment 5 Cyrille Pontvieux 2014-01-13 16:03:13 UTC
Ok that makes sense. I'll try video=efifb.

But there is still a problem in Linux console with i915 driver, even without X. This should probably be fixed.
As an external monitor seems to work ok, maybe it's a problem in the information provided by the internal monitor (bad data or bad protocol). How can we check that? Is this relevant to the rendering I have?
Comment 6 Cyrille Pontvieux 2014-01-14 09:47:07 UTC
Hi again.

So booting with nomodeset and video=efifb + specify efifb to Xorg did the trick.
No artefact anymore, good colors and alignment.
Ok, but this means no Xgl, no video in fullscreen and awful perfs of course.
This is ok for a start and for using the computer, but this does not fix the bug.
What can I do to help debug it?
Comment 7 Daniel Vetter 2014-01-14 10:26:39 UTC
This looks funny. In the off-chance that anything has been fixed for you, can you please try to boot the latest drm-intel-nightly git branch from

http://cgit.freedesktop.org/~danvet/drm-intel/

Also please boot that one with drm.debug=0xe added to your kernel cmdline and attach the complete output.

Finally please grab latest intel-gpu-tools and attach the output of the intel_reg_dumper tool both for the working case (nomodeset+efifb) and the broken case (i915.ko in kms mode).
Comment 8 Daniel Vetter 2014-01-14 10:27:07 UTC
hsw is for paulo.
Comment 9 Cyrille Pontvieux 2014-01-14 22:54:48 UTC
I needed to update libdrm from 2.4.46 to 2.4.51 in order to compile intel_reg_dumper.
I compiled the kernel from the drm-intel-nightly git branch.
I booted (with KMS) and the colors were ok once, still with flickering though. So I thought it was fixed...but no, next reboot and same problems with the rendering.
So 
I attached the output of dmesg and intel_reg_dumper when booting with nomodeset+efifb and with KMS (i915).
Hope it helps.
Comment 10 Cyrille Pontvieux 2014-01-14 22:57:24 UTC
Created attachment 122151 [details]
Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Comment 11 Cyrille Pontvieux 2014-01-14 22:57:59 UTC
Created attachment 122161 [details]
Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Comment 12 Cyrille Pontvieux 2014-01-14 22:58:40 UTC
Created attachment 122171 [details]
Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
Comment 13 Cyrille Pontvieux 2014-01-14 22:58:55 UTC
Created attachment 122181 [details]
Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
Comment 14 Cyrille Pontvieux 2014-01-17 00:45:43 UTC
Any news on this?
Were my reports enough to debug?
Comment 15 Cyrille Pontvieux 2014-01-20 16:12:59 UTC
up?
Comment 16 Cyrille Pontvieux 2014-02-10 11:19:56 UTC
I still have the problem.
Why aren't they any answer/comment?
Comment 17 Daniel Vetter 2014-02-11 10:38:39 UTC
In the off-chance that we've fixed this, can you please try the latest drm-intel-nightly git branch from

http://cgit.freedesktop.org/drm-intel

I'll poke Paulo to have a look meanwhile.
Comment 18 Paulo Zanoni 2014-02-11 17:40:47 UTC
Hi

Just to confirm: this problem does not happen on the HDMI output, right?

Another question: if you just try to change the screen resolution to something that's not the original one, does it work fine? What happens if you get back to the initial resolution?


I see the BIOS boots with real 18bpp, no dithering:

[    6.383733] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A
[    6.383734] [drm:intel_dump_pipe_config], cpu_transcoder: P
[    6.383735] [drm:intel_dump_pipe_config], pipe bpp: 18, dithering: 0
[    6.383736] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[    6.383738] [drm:intel_dump_pipe_config], dp: 1, gmch_m: 3627723, gmch_n: 8388608, link_m: 201540, link_n: 524288, tu: 64
[    6.383739] [drm:intel_dump_pipe_config], requested mode:
[    6.383741] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 1600 0 0 0 900 0 0 0 0x0 0x0
[    6.383742] [drm:intel_dump_pipe_config], adjusted mode:
[    6.383744] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0xa
[    6.383746] [drm:intel_dump_crtc_timings], crtc timings: 0 1600 1648 1680 1860 900 902 908 930, type: 0x0 flags: 0xa
[    6.383747] [drm:intel_dump_pipe_config], port clock: 0
[    6.383748] [drm:intel_dump_pipe_config], pipe src size: 1600x900
[    6.383749] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[    6.383751] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[    6.383752] [drm:intel_dump_pipe_config], ips: 0


But later we try to configure 18bpp with dithering:

[    6.396748] [drm:intel_dump_pipe_config], [CRTC:3][modeset] config for pipe A
[    6.396749] [drm:intel_dump_pipe_config], cpu_transcoder: P
[    6.396750] [drm:intel_dump_pipe_config], pipe bpp: 18, dithering: 1
[    6.396751] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[    6.396753] [drm:intel_dump_pipe_config], dp: 1, gmch_m: 3023102, gmch_n: 4194304, link_m: 167950, link_n: 262144, tu: 64
[    6.396754] [drm:intel_dump_pipe_config], requested mode:
[    6.396756] [drm:drm_mode_debug_printmodeline], Modeline 0:"1600x900" 60 103790 1600 1648 1680 1860 900 902 908 930 0x48 0xa
[    6.396757] [drm:intel_dump_pipe_config], adjusted mode:
[    6.396759] [drm:drm_mode_debug_printmodeline], Modeline 0:"1600x900" 60 103790 1600 1648 1680 1860 900 902 908 930 0x48 0xa
[    6.396761] [drm:intel_dump_crtc_timings], crtc timings: 103790 1600 1648 1680 1860 900 902 908 930, type: 0x48 flags: 0xa
[    6.396762] [drm:intel_dump_pipe_config], port clock: 162000
[    6.396762] [drm:intel_dump_pipe_config], pipe src size: 1600x900
[    6.396764] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[    6.396765] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[    6.396766] [drm:intel_dump_pipe_config], ips: 0
[    6.396766] [drm:intel_dump_pipe_config], double wide: 0

This is probably yet another bug about eDP 18bpp configuration.
Comment 19 Cyrille Pontvieux 2014-02-11 22:14:25 UTC
Thank you for taking time

I'm building the latest drm-nightly to do more tests.
Actually, I used the VGA out connection. Didn't test yet with HDMI, but I will by connecting it to my TV (I don't have a monitor that can handle HDMI).
How can I boot to another resolution? Using vga= VESA parameters?

In fact it is exactly the word "dithering" that I was searching for. It looks like this is it.
When kernel's ready, I boot and log it, and report it here, with different resolutions if possible, both with internal monitor and HDMI (and possibly VGA too, to compare).
Comment 20 Cyrille Pontvieux 2014-02-12 16:37:33 UTC
Ok, I booted in normal mode: KMS, no video parameter.
At first, it worked (I don't know what I did before turning off the computer that did put the graphic card in a specific state). It flickered a lot with garbage on the screen sometimes, but the colors and pixels were ok (Linux console and Xorg)
I saved the ouptput of dmesg in that case but forget to do it for intel_reg_dumper. So you'll see only dmsg.normal.ok file and no intel_reg_dumper.ok file in the archive.
I rebooted, and the problem reappeared. This are the files dmesg.normal-fail and intel_reg_dumper.normal_fail.
I also rebooted and tested with the following video parameters:
- 1600x900 (native resolution)
- 1024x768 (the resolution applied as I had black borders)
- efifb
You have dmesg and intel_reg_dumper output for these three cases in the attached archive.

In all cases, at any moment, if I plug an external monitor on VGA output, or my TV on HDMI output, I get normal video content on it, without flickering nor dithering.

BTW, what is eDP 18bpp configuration? My internal monitor is show as eDP1 by xrandr, but I don't know what "bpp" means.
Comment 21 Cyrille Pontvieux 2014-02-12 16:39:14 UTC
Created attachment 125771 [details]
dmesg and intel_reg_dumper with different booting parameters with Linux dm_intel nightly branch, commit f5eceab
Comment 22 Paulo Zanoni 2014-02-12 19:34:50 UTC
(In reply to Cyrille Pontvieux from comment #19)
> Thank you for taking time
> 
> I'm building the latest drm-nightly to do more tests.
> Actually, I used the VGA out connection. Didn't test yet with HDMI, but I
> will by connecting it to my TV (I don't have a monitor that can handle HDMI).

Testing VGA will have the same effect as testing HDMI for me. I was just looking for something that's not eDP :)

> How can I boot to another resolution? Using vga= VESA parameters?

What I meant was: boot the machine in the "bugged" state, then, after X is running, run something like "xrandr --output eDP1 --mode 1024x768", see if it's still bad-quality, then run "xrandr --output eDP1 --auto" and see if it's still bad quality.

> 
> In fact it is exactly the word "dithering" that I was searching for. It
> looks like this is it.
> When kernel's ready, I boot and log it, and report it here, with different
> resolutions if possible, both with internal monitor and HDMI (and possibly
> VGA too, to compare).
Comment 23 Paulo Zanoni 2014-02-12 19:40:51 UTC
(In reply to Cyrille Pontvieux from comment #20)
>
> BTW, what is eDP 18bpp configuration? My internal monitor is show as eDP1 by
> xrandr, but I don't know what "bpp" means.

I mentioned this mostly as a documentation for possible other developers investigating this bug :)

When your BIOS boots, it configures your screen in a way that every pixel has 18 bits (18bpp = 18 bits per pixel). So the framebuffer in memory has 18bpp, and the panel displays them as 18bpp: no conversion needed.

When our driver loads, it uses a framebuffer that has 24bpp, but since the eDP panel needs to receive 18bpp, we have to convert the 24bpp of the memory to 18bpp for the panel, and we call this "dithering" :)
Comment 24 Paulo Zanoni 2014-02-12 20:59:19 UTC
Hi

Time to bring the cannon:

Please boot in the "bugged case", then run "sudo ./intel_reg_read 0x40000 -c 65536 > registers-bad.txt", then boot on the "non-bugged nomodeset case", and run the same command, redirecting its output to another file, then attach both files here.

Do you have a way to boot this machine in legacy BIOS non-UEFI mode? Maybe perhaps through some distro live-cd, a pendrive or a spare hard drive? Can you reproduce the bug with it? If no, please run the command above and attach its output here too.

Thanks,
Paulo
Comment 25 Cyrille Pontvieux 2014-02-12 21:48:08 UTC
Ok. I've done switching resolution with xrandr.
Sometimes it's bad-quality, sometimes it comes back to ok.
I still have a blinking line on the top.
In console I have more lines (both vertical and horizontal) that blinks, and sometimes even blocks full of garbage that blinks with real video content. Maybe the content of a double buffer?
The blinking is not regular.

How could that be so erratic? But it seems you pinpoint where the bug could be.
Comment 26 Cyrille Pontvieux 2014-02-12 22:00:21 UTC
Yes I can boot this machine in BIOS mode (compatibility).
I have a live cd with grub2 on it, so I can boot my exact same distro (Salix) in BIOS mode very easy.
Do you want I test with other distro?
Comment 27 Cyrille Pontvieux 2014-02-13 09:25:52 UTC
Created attachment 125881 [details]
"intel_reg_read 0x40000 -c 65536" with problems
Comment 28 Cyrille Pontvieux 2014-02-13 09:27:26 UTC
Created attachment 125891 [details]
"intel_reg_read 0x40000 -c 65536" when ok (nomodset+video=efifb)
Comment 29 Paulo Zanoni 2014-02-13 12:33:49 UTC
(In reply to Cyrille Pontvieux from comment #25)
> Ok. I've done switching resolution with xrandr.
> Sometimes it's bad-quality, sometimes it comes back to ok.
> I still have a blinking line on the top.
> In console I have more lines (both vertical and horizontal) that blinks, and
> sometimes even blocks full of garbage that blinks with real video content.
> Maybe the content of a double buffer?
> The blinking is not regular.
> 
> How could that be so erratic? But it seems you pinpoint where the bug could
> be.

I know I'm already requesting a lot of stuff, but having a video of this would be useful :)
Comment 30 Paulo Zanoni 2014-02-13 12:34:44 UTC
(In reply to Cyrille Pontvieux from comment #26)
> Yes I can boot this machine in BIOS mode (compatibility).
> I have a live cd with grub2 on it, so I can boot my exact same distro
> (Salix) in BIOS mode very easy.
> Do you want I test with other distro?

As long as it uses a Linux Kernel, it's fine. Of course, the newest the better :)
Comment 31 Paulo Zanoni 2014-02-13 13:47:20 UTC
Created attachment 125931 [details]
possible patch

Could you please try this patch?

Your description on comment #25 sounds way too crazy. Maybe we're messing with bad memory, and stolen memory is the first I can imagine.
Comment 32 Cyrille Pontvieux 2014-02-13 22:23:29 UTC
Created attachment 125981 [details]
Dithering and Blinking, video URL

In this video, you can see from booting to X desktop, then after changing resolution (fixvideo is a script around the trick with xrandr)
You can see blinking lines and blocks. It's more apparent in Linux console.

And this is with the kernel patched with your diff. So didn't make a difference unfortunately.
Comment 33 Cyrille Pontvieux 2014-02-26 13:27:29 UTC
Any news?
Comment 34 Daniel Vetter 2014-03-03 09:08:28 UTC
Hm, another hsw edp where the panel colors are all funky ...
Comment 35 Cyrille Pontvieux 2014-03-06 09:02:19 UTC
So… What can I do?
Comment 36 Cyrille Pontvieux 2014-03-10 14:44:55 UTC
Is someone still working on this issue?
Comment 37 Edward M. Grant 2014-04-04 01:53:49 UTC
I'm seeing something similar on my Toshiba L70-A-04g. There seem to be three different ways that it fails:

1. Colours are offset by a pixel or so, giving blurry coloured edges around text.
2. Colours are just wrong, as though the RGB byte order has been swapped or one of them isn't being displayed at all. The login screen that usually has a lot of brown shows up largely green.
3. While booting, I get green lines flashing down the screen. The login screen is OK. When switching to the desktop, I get the green lines again and half a ghost cursor offset a few hundred pixels from the real one. Then the desktop is OK except for flashing pixels on the top line.

VESA works pretty well, except if I use lockscreen and log back in, I get occasional flashing black lines across the screen.

This is on Linux Mint 16 (3.11 kernel), but I just tried the Ubuntu 14.04 beta (3.13 kernel), and pretty much the same thing happens.

Clearly it is possible to get a solid display on the LCD because the VESA driver manages it, but the HD 4600 driver can't.

BTW, I'm booting this machine in legacy BIOS mode, not EFI. I could live with VESA mode even though video playback sucks, but not when I get flashing lines there after using lockscreen.
Comment 38 Edward M. Grant 2014-04-04 02:01:04 UTC
Oh, one other thing, if I use the HD4600 driver, the machine often gets stuck when shutting down. If I use the VESA driver, shutdown and reboot always seem to work.
Comment 39 Edward M. Grant 2014-04-04 02:17:13 UTC
Created attachment 131361 [details]
L70 registers in VESA mode (works OK until lockscreen/resume)
Comment 40 Edward M. Grant 2014-04-04 02:17:58 UTC
Created attachment 131371 [details]
L70 registers in 'green screen' mode (looks like red and green are swapped)
Comment 41 Edward M. Grant 2014-04-04 02:19:06 UTC
Created attachment 131381 [details]
L70 registers in flicker mode (green lines in console, flashing pixels in X)
Comment 42 Edward M. Grant 2014-04-04 02:29:34 UTC
Created attachment 131391 [details]
L70 dmesg in 'green screen' mode
Comment 43 Edward M. Grant 2014-04-04 02:30:05 UTC
Created attachment 131401 [details]
L70 dmesg in 'flicker' mode
Comment 44 Edward M. Grant 2014-04-04 02:32:47 UTC
I've attached register dumps in VESA and two failure modes, and dmesg dumps with debug=0xe for both failures. Looks like I'm running driver version 2.99.904.
Comment 45 Blindekinder 2014-06-19 23:15:47 UTC
Hi, I have the same problem on Toshiba C75-A / Intel 4600M also.
Computer is unusable. Any news, progress?
Comment 46 Edward M. Grant 2014-06-24 05:04:08 UTC
What kernel are you running? I'm sure I saw some changes listed for 3.15 which looked like they might help; I was planning to use the driver installer to try the latest driver on this machine for testing before I wipe it and upgrade to Mint 17 in a few weeks.
Comment 47 Blindekinder 2014-06-24 07:11:32 UTC
It's 3.13.0-29-generic
Comment 48 Edward M. Grant 2014-06-25 01:18:56 UTC
Yeah, mine's 3.11. If anything, 3.13 seemed to make the display worse when I tried it. I haven't tried anything beyond that.
Comment 49 Jani Nikula 2014-09-12 09:44:45 UTC
Please try current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel and report back.
Comment 50 Blindekinder 2014-09-15 09:01:57 UTC
I'll do it asap, it's not my computer, so it will be next time I visit the person.
Comment 51 Jani Nikula 2015-01-28 14:07:19 UTC
Timeout, closing. Please feel free to reopen with results on latest kernels.
Comment 52 Edward M. Grant 2015-03-21 16:33:27 UTC
3.16 is worse. I can't easily install anything newer than that on Mint 17.
Comment 53 Edward M. Grant 2015-05-24 06:32:31 UTC
I installed 3.19 today, and so far it all seems to be working. I've rebooted about a dozen times and always got perfect video.
Comment 54 Blindekinder 2016-03-27 20:57:59 UTC
3.16 doesn't work, 3.19 does...