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.
Created attachment 121831 [details] Rendering problem in Linux console (framebuffer) Zoom on it to view how the pixels and color rendering are wrong.
Created attachment 121841 [details] dmesg when nomodeset used.
Created attachment 121851 [details] dmesg when normal booting (KMS)
> (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.
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?
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?
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).
hsw is for paulo.
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.
Created attachment 122151 [details] Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Created attachment 122161 [details] Kernel drm-intel-nightly, at commit 0f21fbbc, booted with nomodeset video=efifb debug=0xe
Created attachment 122171 [details] Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
Created attachment 122181 [details] Kernel drm-intel-nightly, at commit 0f21fbbc, booted in KMS (i915) with debug=0xe
Any news on this? Were my reports enough to debug?
up?
I still have the problem. Why aren't they any answer/comment?
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.
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.
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).
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.
Created attachment 125771 [details] dmesg and intel_reg_dumper with different booting parameters with Linux dm_intel nightly branch, commit f5eceab
(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).
(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" :)
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
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.
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?
Created attachment 125881 [details] "intel_reg_read 0x40000 -c 65536" with problems
Created attachment 125891 [details] "intel_reg_read 0x40000 -c 65536" when ok (nomodset+video=efifb)
(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 :)
(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 :)
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.
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.
Any news?
Hm, another hsw edp where the panel colors are all funky ...
So… What can I do?
Is someone still working on this issue?
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.
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.
Created attachment 131361 [details] L70 registers in VESA mode (works OK until lockscreen/resume)
Created attachment 131371 [details] L70 registers in 'green screen' mode (looks like red and green are swapped)
Created attachment 131381 [details] L70 registers in flicker mode (green lines in console, flashing pixels in X)
Created attachment 131391 [details] L70 dmesg in 'green screen' mode
Created attachment 131401 [details] L70 dmesg in 'flicker' mode
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.
Hi, I have the same problem on Toshiba C75-A / Intel 4600M also. Computer is unusable. Any news, progress?
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.
It's 3.13.0-29-generic
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.
Please try current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel and report back.
I'll do it asap, it's not my computer, so it will be next time I visit the person.
Timeout, closing. Please feel free to reopen with results on latest kernels.
3.16 is worse. I can't easily install anything newer than that on Mint 17.
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.
3.16 doesn't work, 3.19 does...