Created attachment 130874 [details] Files used to build testcase in WRL8 environment. This was originally found with a Wind River Linux 8 system. I have attached a build.tar.gz file that was used to build the testcase. If the ability to build a WRL8 system exists for whoever is assigned to this bug, please feel free to contact me for information on how to build. While the testcase should be able to be run on other versions of Linux, it may be difficult to build due to dependencies. In order to prepare for this bugzilla report, the latest drm-tip was used. Once you have the board booted, perform the following steps to see the problem. 1. setting environment on target. a. login target and run "export DISPLAY=:0" b. ps -ef | grep X root 257 228 0 09:07 ? 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -auth /.serverauth.228 root 258 257 0 09:07 tty2 00:00:00 /usr/bin/X :0 -auth /.serverauth.228 root 355 297 0 09:36 ttyS0 00:00:00 grep X c. copy /.serverauth.228 to /root/.Xauthority 2. running xwininfo (such as xwininfo -root -tree). 3. observing testcase to see if distorted screen occur when second widget shows. This should show the behavior in the attached screenshot (JumbledGraphics.png). I have attached minnowboard.tar.gz which includes some log files collected on the target. root@localhost:~# uname -r 4.11.0-rc4 root@localhost:~# uname -m x86_64 root@localhost:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Atom(TM) CPU E3826 @ 1.46GHz stepping : 9 cpu MHz : 535.095 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syt bugs : bogomips : 2932.60 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Atom(TM) CPU E3826 @ 1.46GHz stepping : 9 cpu MHz : 535.990 cache size : 512 KB physical id : 0 siblings : 2 core id : 2 cpu cores : 2 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syt bugs : bogomips : 2943.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Created attachment 130875 [details] Screenshot of error.
Created attachment 130876 [details] Log files collected.
08:41 <mkuoppal> https://bugs.freedesktop.org/show_bug.cgi?id=100700 08:43 <ickle> try with the latest ddx (i.e. git) 08:44 <ickle> though that really doesn't look like a direct ddx bug 08:46 <ickle> it looks like the geometry is screwed 08:46 <ickle> it's not a random buffer, it's not tiling, it's not stride
Also note that playing with xorg.conf: Section "Device" Identifier "igfx" Driver "intel" Option "AccelMethod" "[sna|blt|none]" EndSection or s/Driver "intel"/Driver "modesetting"/ may give some more clues. If you do recompile from git, also use --enable-debug=full for assertions and extremely verbose logging.
Hi Chris, Our engineer gave the latest DDX driver a try and included the --enable-debug option in our build but it didn't seem to give any extra debug information in the dmesg or Xorg.log file. It seems that DDX is not helpful for the issue. However they did notice that kernel v4.11 from intel-tip-git seemed to decrease the issue's frequency. The distorted screen is different than it was with the previous kernel driver. I'll attach a new screenshot so that you can see the difference. Although this version worked better than the previous driver the testcase still fails to run due to a distorted screen in the end. Any other suggestions? Thanks, Jennifer
Created attachment 131415 [details] New screenshot May 18
Just wanted to add that on a call with customer today they indicated that they are still seeing this issue about once per month so any workarounds that they have implemented are not covering all instances of this issue. Any updates from your side? Thanks, Jennifer
Any updates? Thanks, Jennifer
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
Had a meeting with customer today during which they indicated that they are now seeing this on one type of their vehicles once a day rather than the once a month that they had previously reported. Anything that can be done to speed up this investigation would be appreciated. Thanks, Jennifer
Jennifer, related to Comment #4, did you try the following? Also note that playing with xorg.conf: Section "Device" Identifier "igfx" Driver "modesetting" Option "AccelMethod" "[sna|blt|none]" EndSection It's not clear from the comments if you tried modesetting to see if the issue was seen or not.
I assumed that the engineer had tried this comment since they also tried the enable-debug that was referenced in Comment 4. I will confirm and let you know.
Our engineer doesn't see the referenced change in the xorg.conf file. Is this something that should be added in if it doesn't exist? Does the fact that it doesn't exist indicate something about the system? Could you be more exact about where we should be seeing this to change? Thanks, Jennifer
Also, can you point out if there is any additional information that we need to attach to this bug? additional log info, etc. Thanks!
Hello, Last information about this case suggested that the bug was going to be follow up internally. Can we close this item then? Or still is going to be added more information in FDO? Thank you.
I understood that the IPS case that I opened might need to be helped by this bugzilla but will leave the decision about whether this should stay open or can be closed to Fred Moses or Nelson Chan. Thanks, Jennifer
Hi Chris I am working on this issue. I add a 1ms delay after gen7_render_composite() function finishing, then it works well. I think maybe there are conflicts with the two adjacent composite. Can you give me some advice? thanks very much! ruibin
Created attachment 133665 [details] attachment-22707-0.html Thank you for your email. I am OOO for the next few weeks. I will not have cell phone or email access. Please contact my manager Rob Marsh ( rob.marsh@intel.com) or Sujatha Sivamoothy ( sujatha.sivamoothy@intel.com ) if you need assistance. Thank you Fred ------------------------------------- Fred Moses Intel America's Inc. SMG IOT Technical Sales Senior Technical Sales Specialist Desk (978) 553-1463 Cell (978) 621-2508
Created attachment 133670 [details] attachment-32688-0.html I am out of the office until August 22nd and will not be checking emails. If you have an existing case and need immediate attention, please contact my manager Junaid Usmani at junaid.usmani@windriver.com. He will be able to re-assign your TSR to someone in the office. If you have a new question, please go to our online support site www.windriver.com/support and click on the Access Support link to choose your method of logging the issue. Have a good day! Jennifer Jennifer Ito, Customer Support, Member of Technical Staff, Wind River direct 978.553.7091 Tech Tips, FAQs, Discussion Groups, Proactive Alerts and more at: http://support.windriver.com/
Hi Chris, Since this defect is very critical, Would you bridge us with your peer from Intel? Regards. Huwen.
(In reply to jennifer.ito from comment #13) > Our engineer doesn't see the referenced change in the xorg.conf file. Is > this something that should be added in if it doesn't exist? Does the fact > that it doesn't exist indicate something about the system? Could you be more > exact about where we should be seeing this to change? (In reply to Chris Wilson from comment #4) > Also note that playing with xorg.conf: > > Section "Device" > Identifier "igfx" > Driver "intel" > Option "AccelMethod" "[sna|blt|none]" > EndSection > > or s/Driver "intel"/Driver "modesetting"/ may give some more clues. If you > do recompile from git, also use --enable-debug=full for assertions and > extremely verbose logging. This means add the configs to xorg.conf, and try with Option "AccelMethod" "sna", "blt", and "none", and see if they make a difference. Might also try Driver "modesetting" and see if that makes a difference.
hi, chery When I set the flag of DEBUG_SYNC true, the issue disappears. I don't know why? Can you help me to explain it? Regards thanks
Today I do more tests about this issue: (1)try [Option "AccelMethod" "[sna|blt|none]"] according to above suggestion: I write a simple xorg.conf as below (if anything wrong, please let me know), and change AccelMethod to sna, blt and none. The issue happens when setting to sna, and doesn't happen when setting to blt and none. Since there isn't enough time for me to do a long time test, every test is about 1-2 hours. cat /etc/X11/xorg.conf Section "Device" Identifier "igfx" Driver "intel" Option "AccelMethod" "sna" EndSection (2)try to use --enable-uxa instead of --enable-sna when configuring the source code. The issue happens when --enable-sna (default setting), and doesn't happen when --enable-uxa (In a test for about 2 hours by now, and I will go on with this uxa test over night.) Since I haven't enough knowledge about graphic and the document on internet about this is limited too, could the experts please give us some analysis about this (about sna/blt/uxa)? BTW, I see "SNA issues" in https://wiki.archlinux.org/index.php/intel_graphics. Not sure if it has anything to do with our issue.
@Jani Nikula: About [try Driver "modesetting"], could you please give some indication about how to do this? Thank you.
(In reply to Li Zhou from comment #24) > @Jani Nikula: > About [try Driver "modesetting"], could you please give some indication > about how to do this? Thank you. cat /etc/X11/xorg.conf Section "Device" Identifier "igfx" Driver "modesetting" EndSection
Thanks Jani. I test Driver "modesetting" for about 2 hours, and the error doesn't happen. I have a long test about uxa for about 2 days and the error doesn't happen. By now this issue only happens with sna. Is there any more suggestion from those results? Thanks.
Hi there, Just wanted to give an update from customer perspective. They tried the modesetting option but found that it caused other problems to occur on their production systems (more complex than the test case we have been using on the WR side of things for testing). With that they moved to the UXA solution and that allowed their system to run properly where the SNA did not. Is the SNA code something that is still maintained? Are there suggestions as to whether all customers should be moved to the UXA code instead of SNA at this point? Thanks for any help. Jennifer
Created attachment 134264 [details] attachment-10541-0.html I am currently away from the office, returning on September 25th. If you need immediate assistance, please contact my manager nicolas.marguet@windriver.com
SNA code is still being maintained as a public project. See https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ for the latest changes to the SNA driver, the last on Aug 22 of this year. As with most open source projects, a system designer has a number of options to choose from. In this case, UXA, SNA or Modesetting. There is no "one solution" that all users should move to. I'm glad for this issue a solution was found. I hope that you have filed bugs against SNA and Modesetting describing the bugs you have found. And, maybe Wind River can explore fixes that can be contributed to these projects?
Customer is fine using UXA solution at this point so nothing more is needed on this case from the customer perspective. This may be able to be used to test the SNA driver but from the customer side of things thing is closed. Don't know whether anything else needs to be done from the book-keeping side of things but this can be considered closed. Thanks, Jennifer
Thanks for the information. Then closing this bug.
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.