Created attachment 73841 [details] dmesg output for drm-intel-nightly 2013-01-29 kernel I get either an out-of-range error or a colorful static pattern using this hardware: http://us.acer.com/ac/en/US/content/model/DT.VFGAA.001 This is regardless of connector, including VGA via DVI adapter. I suspect this is a factor: [ 2.249615] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x700 [ 2.249617] [drm:gen6_fdi_link_train], FDI train 1 done. [ 2.250267] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.250319] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.250371] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.250423] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.250475] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251023] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251074] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251126] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251178] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251230] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251779] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251831] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251882] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251935] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.251987] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252535] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252587] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252639] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252691] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252743] [drm:gen6_fdi_link_train], FDI_RX_IIR 0x0 [ 2.252794] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 2.252795] [drm:gen6_fdi_link_train], FDI train done. I'm currently testing with an Ubuntu mainline nightly build: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-01-29-raring/ It appears this has all of the available fixes from Daniel Vetter's drm-intel-fixes branch. I will do whatever I can to help debug. Thanks, Forest
Is this a regression, i.e. does an older kernel version work?
I am not aware of an olrder kernel version that works. I have tested a few kernels.
How often does this happen? What *does work* for you?
The issue occurs on every boot. I am not able to get useful video output on this hardware, regardless of which connector I use.
Wow nothing works? From the link you sent, it comes with Linux on it. Did you boot it? Did it work?
I did boot it, and it did work. Sorry, I should have mentioned that. Unfortunately, I did not take the time to look at the pre-installed Linux distro before replacing it. It may have been using one of the VESA drivers, but I'm really not sure. I don't know that I can recover the original distro, but I can try to get a fresh copy from Acer if that would be helpful.
Yeah, being able to compare with the working setup would be rather interesting, if it's not too much fuzz.
You can see the BIOS when you're booting, right? Please do the following: - Download and compile intel-gpu-tools (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) - Then boot your machine with i915.modeset=0, run tools/intel_reg_dumper, redirect its output to a file and attach the file here - Then boot your machine _without_ i915.modeset=0, run tools/intel_reg_dumper, redirect its output to a file and attach the file here - If you have any distribution live-cd that properly boots, loads our drivers and work, please do the same thing If you need any help on these steps, please ask questions. Thanks, Paulo
I'm using intel-gpu-tools git revision beb1bb8fd26b1b1c55242c3b2a3004a346d64b80 as newer revisions depend on a newer version of lidrm. Attached is intel_reg_dumper output with modesetting enabled. intel_reg_dumper triggers a kernel bug and crashes with modesetting disabled. The dmesg log is attached. Thanks, Forest
Created attachment 74074 [details] intel_reg_dumper output with modesetting enabled
Created attachment 74075 [details] dmesg output including kernel bug triggered by intel_reg_dumper with modesetting disabled
(In reply to comment #11) > Created attachment 74075 [details] > dmesg output including kernel bug triggered by intel_reg_dumper with > modesetting disabled Hi From this dmesg: - You're using Kernel 3.2. Can you please provide the logs using drm-intel-nightly? - You're using a lot of Kernel parameters, including "VIDEO=LVDS-1:d". Please remove this parameter on all tests and redo the tests (and also remove any other parameters that are not strictly needed). Thanks, Paulo
Sorry about that. I guess I re-imaged the machine and forgot to re-install the drm-intel-nightly kernel. With kms enabled, intel_reg_dumper failed with the following error: Couldn't map MMIO region: Resource temporarily unavailable dmesg for this case is attached. With kms disabled, intel_reg_dumper succeeded but complained as follows: Couldn't find path to dri/debugfs entry Dump output is attached. Thanks, Forest
Created attachment 74173 [details] intel_reg_dumper output with modesetting disabled (drm-intel-nightly 2013-02-02)
Created attachment 74174 [details] dmesg output with modesetting enabled (drm-intel-nightly 2013-02-02)
(In reply to comment #13) > Sorry about that. I guess I re-imaged the machine and forgot to re-install > the drm-intel-nightly kernel. > > With kms enabled, intel_reg_dumper failed with the following error: > > Couldn't map MMIO region: Resource temporarily unavailable You need a newer version of intel-gpu-tools for this. For new libdrm dependency: http://cgit.freedesktop.org/mesa/drm
Okay, attaching new dumps with latest intel-gpu-tools and libdrm.
Created attachment 74185 [details] intel_reg_dumper output with modesetting enabled (drm-intel-nightly 2013-02-02)
Created attachment 74186 [details] intel_reg_dumper output with modesetting disabled (drm-intel-nightly 2013-02-02)
Hi there, I can confirm this somewhat annoying bug on an Acer Revo RL80. I build a few 3.8 kernels, but could not figure what is causing the problem. I got the intel driver working with a kernel I build from the drm-intel-next repo, dating to 26. Dec. The last working commit was before the merge with kernel 3.8-rc1. Guess my build is around this tag: [1] I am currently on Arch Linux and a bit short on time. intel_drm_regdump with the working intel drivers here: [2] Hope it helps, Marvin [1] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next&id=c0c36b941b6f0be6ac74f340040cbb29d6a0b06c [2] https://gist.github.com/JanMarvin/4718115
Jan, from a quick googling it looks like your Acer has Intel HD graphics, which means ironlake. This bug here is about snb, which uses rather different fdi link training code. So there's a bit chance that you have a different bug (but similar symptoms). Can you please file a separate issue for your machine? Also, since it sounds like some older drm-intel-next tree worked for you, but more recent ones are broken: Can you please attempt to bisect where this regressions has been introduce? Thanks, Daniel
Hi, So Linpus works by setting i915.modeset=0. X.org uses the vesa driver. The same setup works for me (but I still need to get the i915 driver running on this hardware). I can provide dmesg and X.org logs under these circumstances if they would be useful. Thanks, Forest
Hi, I'm curious how complex this issue is i.e. would you expect a resolution in days/weeks/months? We just need to decide if we should abandon this hardware and move on to something else. Is there anything I can do to help out? Thanks very much, Forest
Seeing the exact same problems that Forest is having with the same hardware though I don't see exact same log output that he does... $ cat /var/log/syslog |grep -i drm [ 3.862876] [drm] Initialized drm 1.1.0 20060810 [ 3.926409] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.926411] [drm] Driver supports precise vblank timestamp query. [ 4.107004] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.469032] fbcon: inteldrmfb (fb0) is primary device [ 4.469171] fb0: inteldrmfb frame buffer device [ 4.469173] drm: registered panic notifier [ 4.490963] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.863145] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 4.085198] [drm] Initialized drm 1.1.0 20060810 [ 4.224252] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 4.224254] [drm] Driver supports precise vblank timestamp query. [ 4.350113] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.747364] fbcon: inteldrmfb (fb0) is primary device [ 4.748570] fb0: inteldrmfb frame buffer device [ 4.748573] drm: registered panic notifier [ 4.767205] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 5.016695] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 4.170906] [drm] Initialized drm 1.1.0 20060810 [ 4.180346] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 4.180348] [drm] Driver supports precise vblank timestamp query. [ 4.290139] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.674903] fbcon: inteldrmfb (fb0) is primary device [ 4.675086] fb0: inteldrmfb frame buffer device [ 4.675088] drm: registered panic notifier [ 4.686875] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.893052] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 3.773108] [drm] Initialized drm 1.1.0 20060810 [ 4.331410] [drm] Initialized drm 1.1.0 20060810 [ 4.426451] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 4.426453] [drm] Driver supports precise vblank timestamp query. [ 4.610839] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 5.003420] fbcon: inteldrmfb (fb0) is primary device [ 5.229910] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 5.261985] fb0: inteldrmfb frame buffer device [ 5.261986] drm: registered panic notifier [ 5.300979] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.529641] [drm] Initialized drm 1.1.0 20060810 [ 5.016751] [drm] Initialized drm 1.1.0 20060810 [ 5.116376] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 5.116377] [drm] Driver supports precise vblank timestamp query. [ 5.247292] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 6.113771] fbcon: inteldrmfb (fb0) is primary device [ 6.351215] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 6.385176] fb0: inteldrmfb frame buffer device [ 6.385177] drm: registered panic notifier [ 6.401633] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 638.239734] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! [ 832.705891] [drm:gen6_fdi_link_train] *ERROR* FDI train 2 fail! Likewise as Forest stated, if there is anything I can do to help out I would be interested.
Created attachment 77018 [details] [review] Possible fix Hi Can you please try this patch against today's drm-intel-next-queued tree? Does it solve the problem? Thanks, Paulo
Paulo, this patch applied to drm-intel-next-queued tree fixed the issue on my Acer Revo RL80 (Fedora 18, config from stock kernel with all defaults in 'make oldconfig'). Everything work fine! I've just registered to say thank you! Can you suggest when this patch may be pushed to upstream? Or maybe you can port it to released kernel version? Sorry for my English.
Hi Pualo, Sorry, I no longer have hardware available to test. But thank you for looking at this! Note that Kozinov's hardware is not exactly the same as what I was using. But I believe kaneda's is the same. Thanks, Forest
Well, sounds like Paulo's patch fixes at least one issue, so we should probably go ahead and push it...
kaneda, can you test the patch posted here?
Hey there, yeah we got the patch on Tuesday I believe. We had to do a little bit of adjusting to get it to work for our 3.2.16 kernel but it resolves the issue. Thanks a ton Paulo! -Kevin
Thanks, the proposed fix solved my problem. Marvin
I've tested this patch on vanilla 3.8.5 kernel with success. Thanks again!
*** Bug 62771 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > I've tested this patch on vanilla 3.8.5 kernel with success. Thanks again! Based on this closing the bug.
The patch isn't merged yet, so we can't close this yet.
Hello, I have the same problem with my Acer Revo RL80 (Intel i3 CPU, Intel HD 3000 GPU) The grub bootscreen is ok, then i only see a colorful static flicker. (HDMI, DVI, VGA). I'm using Ubuntu 12.04 and tested with Ubuntu 12.10, 13.x and Knoppix-Linux. Will this problem solved also in the 3.2.xx kernel ? thanks to all Frank
Created attachment 77628 [details] [review] New patch Hi This patch should be equivalent to the patch I posted earlier, so your systems should still be working with this one. The main difference is that this patch has a cleaner code. I also already sent it to development our mailing list and marked it as a candidate for the Kernel -stable trees, so if you could provide some additional testing on this specific patch, it would be good. Thanks, Paulo
ok, but my linux skills are not so good. i don't know how i apply this patch. But i can try to help. I have no access without "nomodeset", only with VNC remote access from a another device. Amazingly, on my other pc with the intel 3000 Chipset Linux work perfectly. sorry for my english thanks
I've tested new patch applied to vanilla 3.8.6 kernel. Everything works fine! Thanks!
Looking good w/ 3.9-rc6 on my revo. Though not really tested, just build and rebooted. Thanks Marvin
Hi. I've the same problem in Ubuntu 12.10 with my Revo RL80. How can i apply the patch on a Ubuntu Kernel? The files in the original Ubuntu Kernel are different to the files in Vanilla Kernel. Regards Max
Fix merged for -next with cc: stable commit 104e6100e4e59544f7604457fe234c2264601e28 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Mon Apr 8 15:48:07 2013 -0300 drm/i915: set CPT FDI RX polarity bits based on VBT
Just to confirm and for completeness: Last week, I have tried the patch with an Ubuntu 13.04 beta, with the Default Ubuntu kernel, on an Acer Revo RL80 that came with Windows 8, which I bought as a Linux HTPC. The patch finally and successfully fixed the boot problems. At last! :-)
Hi. How can i see, if the patch is implemented in Ubuntu? Thanks in advance. regards Max
I ended up getting some hardware again and wanted to confirm that my issue is now resolved. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.