Launchpad has imported 72 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=88012.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2015-01-04T10:07:13+00:00 Fritsch-b wrote: We experienced strange full system freezes on Asrock Q1900 hardware with our OpenELEC 5.0 release. No errors were visible via netconsole, the whole system just fully hung. We then started to bisect between kernel 3.13 and 3.18 stable. It was verified before that 3.19-rc2 is also affected. Commit: 31685c258e0b0ad6aa486c5ec001382cf8a64212 drm/i915/vlv: WA for Turbo and RC6 to work together was found to be the first bad commit in that bisect. A manual workaround was to set the max cstate to C1 (via BIOS), which workarounded this bug. We currently have > 10 users that are affected by this bug (mostly Asrock Q1900 users). You can see the complete bisecting steps here: https://github.com/OpenELEC/OpenELEC.tv/issues/3726#issuecomment-68626603 I will ask that user to subscribe to this tracker. As we freeze very hard, it's not possible to add logfiles as the netconsole stays empty for us. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/0 ------------------------------------------------------------------------ On 2015-01-04T14:34:07+00:00 Dnv wrote: Created attachment 111723 dmesg output from boot till crash (drm.debug=0xe debug ignore_loglevel) ASRock Q2900-ITX is affected, too. Log is crated by using netconsole. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/1 ------------------------------------------------------------------------ On 2015-01-04T19:39:54+00:00 Ben-chgtaa3qpp0 wrote: Created attachment 111734 Be more careful with punit reads It's a bit of a long shot, but let's see what happens. I have only compile tested this patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/2 ------------------------------------------------------------------------ On 2015-01-04T23:13:22+00:00 Openelec wrote: Created attachment 111739 111723: dmesg output from boot to hung (drm.debug=0xe debug ignore_loglevel) Good day, I did the bisect, see attached my dmesg. System: Zotac CI320 Nano, FW Version 2K141128, Intel HD Graphics, Intel Celeron N2930 (quad-core, 1.83 GHz) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/3 ------------------------------------------------------------------------ On 2015-01-05T10:34:22+00:00 Chris Wilson wrote: I had some patches to improve the vlv rps: http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=bug88012 They incorporated the change Ben suggested and reduce the number of interrupts required by the manual RPS tuning, as well as making it much more responsive to gfx workload (not that byt has that great a range). It doesn't explain a system hang though... Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/4 ------------------------------------------------------------------------ On 2015-01-05T13:01:24+00:00 Openelec wrote: Created attachment 111767 dmesg output from boot to hung (drm.debug=0xe debug ignore_loglevel) I build the Kernel (3.18.1-bw1+) from Peters git with Ben Widawski experimental patch. Unfortunately I had the freeze / hung again after ~10 minutes of running a movie. Attached is the dmesg log via netconsole until the System freeze. If you need more Information or Logs - of course I will support as mutch is possible. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/5 ------------------------------------------------------------------------ On 2015-01-05T18:53:58+00:00 Fritsch-b wrote: @Juergen Froehler: Please give ickle's branch a try, I forked it on my github (as freedesktop's git was really slow in the past): git clone https://github.com/fritsch/linux.git git checkout bug88012 make localmodconfig make-kpkg --append-to-version "-ickle1" --initrd linux-headers linux-image And give it a good test. Btw. As your base OS is Ubuntu 14.04, you might need to upgrade the linux-firmware (or ignore warnings about it a bit). Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/6 ------------------------------------------------------------------------ On 2015-01-06T00:59:56+00:00 Openelec wrote: Created attachment 111800 ickle1 - dmesg output from boot to hung (drm.debug=0xe debug ignore_loglevel) Hello, first I updated the Ubuntu firmware to linux-firmware_1.140 and build the new Kernel based on ~ickle (3.19.0-rc2-ickle1+). The System hung was after 5 min runtime. The Logfile was created via netconsole from boot > freeze. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/7 ------------------------------------------------------------------------ On 2015-01-06T09:07:15+00:00 Chris Wilson wrote: Have you tried i915.enable_rc6=0? Or maybe using intel_pstate? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/8 ------------------------------------------------------------------------ On 2015-01-06T09:13:26+00:00 Openelec wrote: Created attachment 111836 ickle1 - dmesg output with trace on the end (drm.debug=0xe debug ignore_loglevel) today morning I had this nice one, but this happend bevor I run any movie. I have to say that I want to do an refernce test (to see if the workaround still works) and limited in Bios the C State to C3. Kernel: 3.19.0-rc2-ickle1+ (the one I build last night from ickle git) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/9 ------------------------------------------------------------------------ On 2015-01-06T09:33:48+00:00 Openelec wrote: (In reply to Chris Wilson from comment #8) > Have you tried i915.enable_rc6=0? Or maybe using intel_pstate? not this time, but I will do testing it now and give feedback soon. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/10 ------------------------------------------------------------------------ On 2015-01-06T10:24:24+00:00 Openelec wrote: Created attachment 111842 dmesg with i915.enable_rc6=0 (3.19.0-rc2-ickle1+) Ok, here the result of the first test with i915.enable_rc6=0 I checked twice to be sure it was disabled once in the dmesg: [ 2.626518] [drm] RC6 disabled, disabling runtime PM support [ well it looks like the same as when I limit 3.799990] [drm:intel_print_rc6_info] Enabling RC6 states: RC6 off and once in the parameters: /sys/module/i915/parameters/enable_rc6=0 Well it looks like as the same when I limit in the Bios the C State to C3. There is a trace on the end of the attached Logfile and if I run an mkv it freeze after some minutes. the next test will be with intel_pstate=disable actually the settings looks like: for i in /sys/devices/system/cpu/intel_pstate/*; do echo $i=$(cat $i); done /sys/devices/system/cpu/intel_pstate/max_perf_pct=100 /sys/devices/system/cpu/intel_pstate/min_perf_pct=100 /sys/devices/system/cpu/intel_pstate/no_turbo=0 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/11 ------------------------------------------------------------------------ On 2015-01-06T11:33:34+00:00 Openelec wrote: Created attachment 111844 no freeze - dmesg with intel_pstate=disable (3.19.0-rc2-ickle1+) This time I did a test with intel_pstate=disable. I had no freeze during a 45 minute run of a file which usually freeze. Anyway I attached the dmesg of it if you like to verify. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/12 ------------------------------------------------------------------------ On 2015-01-07T07:54:14+00:00 Ben-chgtaa3qpp0 wrote: Do other governors also cause a hang? For instance: for g in /sys/devices/system/cpu/cpu[0-9]/cpufreq/scaling_governor; do echo powersave > $g; echo cpu$i: $(cat $g); ((i++)); done Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/13 ------------------------------------------------------------------------ On 2015-01-07T09:19:10+00:00 Openelec wrote: (In reply to Ben Widawsky from comment #13) > Do other governors also cause a hang? For instance: > > for g in /sys/devices/system/cpu/cpu[0-9]/cpufreq/scaling_governor; do > echo powersave > $g; echo cpu$i: $(cat $g); ((i++)); done Hello Ben, will do the test tonight and give then feedback Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/14 ------------------------------------------------------------------------ On 2015-01-07T22:03:09+00:00 Openelec wrote: Created attachment 111932 no freeze - dmesg with governor=powersave (3.19.0-rc2-ickle1+) Hello Ben, Here the result of my test with governor=powersave. first I set the governor to powersave and checked it after reboot: for g in /sys/devices/system/cpu/cpu[0-9]/cpufreq/scaling_governor; do echo $g=$(cat $g); done /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor=powersave /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor=powersave /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor=powersave /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor=powersave Booted Kernel regular (without i915.enable_rc6=0 and without intel_pstate=disable) Kernel build from ickle git: 3.19.0-rc2-ickle1+ #1 SMP Tue Jan 6 00:57:18 CET 2015 x86_64 x86_64 x86_64 GNU/Linux I had run some files over a time of almost 2 hour now without a freeze. In the attached logfile there is just one Kernel trace (perhaps interesting for Ickle), but it seems to have no impact during the test. The CPU was during the run mostly like: cat /proc/cpuinfo | grep "cpu MHz" cpu MHz : 499.741 cpu MHz : 499.741 cpu MHz : 499.741 cpu MHz : 499.741 Well I will do another test now with the "regular" Kernel 3.17.7 and governor=powersave just to see if it freeze or also run more "stable". Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/15 ------------------------------------------------------------------------ On 2015-01-07T22:51:39+00:00 Ben-chgtaa3qpp0 wrote: (In reply to Juergen Froehler from comment #15) > Well I will do another test now with the "regular" Kernel 3.17.7 and > governor=powersave just to see if it freeze or also run more "stable". Can you also confirm you are unable to hit this without GPU, and just CPU stress tests (I do not have any recommendations for which test)? I see a a similar sounding problem, but it is very intermittent for me. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/16 ------------------------------------------------------------------------ On 2015-01-07T23:40:44+00:00 Openelec wrote: (In reply to Ben Widawsky from comment #16) > (In reply to Juergen Froehler from comment #15) > > > Well I will do another test now with the "regular" Kernel 3.17.7 and > > governor=powersave just to see if it freeze or also run more "stable". > > Can you also confirm you are unable to hit this without GPU, and just CPU > stress tests (I do not have any recommendations for which test)? I see a a > similar sounding problem, but it is very intermittent for me. What I can say and what I have most intensive tested on the generic Kernels (3.13.0 > 3.17.7 and also on the ickle Kernel 3.19.rc2 was to disable HW Acceleration (VAAPI) in Kodi and running movies over several hours without a freeze/hung. The hung happens only when HW Acceleration in Kodi is enabled. In the meantime I was running 3.17.7-generic with governor=powersave for over an hour now without a freeze, but the logfile runs quickly full with the aggresiv drm:valleyview_set_rps but no freeze yet... will let it run some time more I did also some days ago a long memtest run over 6 PASS 0 Errors which took over ~8 hours to be sure there is no HW issue. Well for a CPU stress test, I will look around if there is something I can use without killing it Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/17 ------------------------------------------------------------------------ On 2015-01-08T05:19:11+00:00 3ddd wrote: Maybe Prime95 can be user for CPU Stress tests? http://www.mersenne.org/download/#stresstest Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/18 ------------------------------------------------------------------------ On 2015-01-08T11:09:14+00:00 Openelec wrote: (In reply to DDD from comment #18) > Maybe Prime95 can be user for CPU Stress tests? > http://www.mersenne.org/download/#stresstest I plan the CPU stress test for tonight and will give feedback. Found several good Information for stress testing in the Ubuntu Wiki. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/19 ------------------------------------------------------------------------ On 2015-01-08T17:32:10+00:00 Openelec wrote: CPU stress test: using stress with a runtime of 1200 seconds which should be a nice cpu burn test if our intend is to figgure out if there is an CPU issue. Under normal circumstances with running Kodi 14 on this box I never have seen this high cpu usage over this time periode. --- stress --cpu 4 --timeout 1200 stress: info: [4387] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd stress: info: [4387] successful run completed in 1200s CPU > max speed (switched off Turbo mode in Bios to avoid killing my CPU) cat /proc/cpuinfo | grep "cpu MHz" cpu MHz : 1832.600 cpu MHz : 1832.600 cpu MHz : 1832.600 cpu MHz : 1832.600 top during test run %Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st 4388 root 20 0 7316 100 0 R 100.0 0.0 19:49.05 stress 4389 root 20 0 7316 100 0 R 100.0 0.0 19:48.16 stress 4390 root 20 0 7316 100 0 R 100.0 0.0 19:52.30 stress 4391 root 20 0 7316 100 0 R 97.4 0.0 19:48.88 stress sensors coretemp-isa-0000 Adapter: ISA adapter Core 0: +58.0°C (high = +105.0°C, crit = +105.0°C) Core 1: +58.0°C (high = +105.0°C, crit = +105.0°C) Core 2: +62.0°C (high = +105.0°C, crit = +105.0°C) Core 3: +61.0°C (high = +105.0°C, crit = +105.0°C) Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/20 ------------------------------------------------------------------------ On 2015-01-12T07:59:30+00:00 Openelec wrote: good day together, over the weekend I had some time to do several tests and I like to share my findings. 1. I did several different CPU & memory stress tests and all went fine, therefor i think the CPU & memory itself is fine. 2. kernels tested between 3.13 - 3.16 runs stable no freeze 3. I tested several mainline generic Kernels between 3.17 > 3.19RC2 & the Ickle 3.19RC2 with governor=powersave & C6/7 enabled in Bios. the findings are: it runs more stable, freeze are very sporadic happens. I was not able to figure out under which circumstances it happens or not. Sometimes the test files runs over 2 hours without a freeze, sometimes 4 freezes in 1 hour. The Logfiles give no hint about the freeze. I am very sorry that I was not able to get more Logfile information out of the System, but if you have more test Scenarios - I am glad to support. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/21 ------------------------------------------------------------------------ On 2015-02-04T16:34:08+00:00 Openelec wrote: good day together, I kindly ask all, if there is something we can do to push this Topic a bit forward. As I already wrote I will support as far as possible. kind regards Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/22 ------------------------------------------------------------------------ On 2015-02-05T10:43:37+00:00 Jani-nikula wrote: So the regressing commit is commit 31685c258e0b0ad6aa486c5ec001382cf8a64212 Author: Deepak S <deepa...@linux.intel.com> Date: Thu Jul 3 17:33:01 2014 -0400 drm/i915/vlv: WA for Turbo and RC6 to work together. Deepak, Ville, do you have any ideas? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/23 ------------------------------------------------------------------------ On 2015-02-05T10:48:58+00:00 Chris Wilson wrote: That bisect appears to be a red herring though. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/24 ------------------------------------------------------------------------ On 2015-02-05T11:22:47+00:00 Adf-lists wrote: (In reply to Chris Wilson from comment #24) > That bisect appears to be a red herring though. As someone who is also affected by this I can well believe that. Though I wasn't bisecting Kernel at the time (and still haven't) I've had runs of 12 hours without a lock - the same setup locked < 2H next day. Having test quite hard since this bug was filed with released kernels I am 99.9% sure the issue is between 3.16.7 and 3.17.0. I also think that gpu load is needed - I use LFS and have compiled plenty on bad kernels + mprime torture test and never locked. Do you have any guesses of what the bad commit could be between those - if you have then people could test that and someone will hopefully call bad quickly then extended test on the one before. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/25 ------------------------------------------------------------------------ On 2015-02-05T23:03:35+00:00 Openelec wrote: (In reply to Chris Wilson from comment #24) > That bisect appears to be a red herring though. well to be honest - yes can be a red herring, because to make the decision if the Biscet step was good or bad wasn't easy, but I have tested each step at least >2 hours, but mostly the freeze was much earlier . However, what I 100% can say is, I am running my device with Ubuntu 14.04.1 & Kernel 3.16.7-031607-generic now since 20 days as my daily beast without any freeze/hang and of course with VAAPI HW Acceleration enabled in kodi and C6/7 Idle state enabled in Bios - therefore I believe it is not a Hardware issue. With a 3.17x Kernel no way... it start freeze with the same settings under 1 hour. If someone has a suggestion or Idea how we can narrow down this issue - I am glad to support and test. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/26 ------------------------------------------------------------------------ On 2015-02-06T05:52:20+00:00 Dnv wrote: (In reply to Chris Wilson from comment #24) > That bisect appears to be a red herring though. With the help of peter, i built 2 kernels about 30 days ago. First one with git reset --hard 31685c258e0b0ad6aa486c5ec001382cf8a64212 Second one by a followed git revert 31685c258e0b0ad6aa486c5ec001382cf8a64212 The first one crashed every time i was testing it, the second one was running fine for a few hours and didn't crash at all. If you want to, i can test the second one as my standard kernel to be surer, that this commit is the right one. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/27 ------------------------------------------------------------------------ On 2015-02-10T15:59:54+00:00 Openelec wrote: I just tested latest mainline Kernel 3.19.0 to confirm the freeze still exist. unfortunately this issue exist now since 3.17.x. kind regards Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/28 ------------------------------------------------------------------------ On 2015-02-14T15:15:32+00:00 Devilstrike wrote: Is not only the q1900/j1900 also the j1800 same problem from time to time, just hangs without any errors. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/29 ------------------------------------------------------------------------ On 2015-03-05T17:28:37+00:00 1dreambox wrote: same shit j1900 shit intel never again Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/30 ------------------------------------------------------------------------ On 2015-03-05T18:15:23+00:00 Jesse Barnes wrote: Juergen sounds certain that this commit affects this issue, and I can believe it. The punit provides several services, including CPU and GPU power management, and the code in question changes how we interact with the Punit to a degree. So it's possible a BIOS upgrade (which would include a new Punit firmware) might help. It's also possible that we're not validating the result of Deepak's code enough and end up feeding some bad values to the Punit as as result of the new calculations. Or the simple fact that we're reading a new Punit reg fairly frequently is enough to cause trouble. In that case, throttling the vlv_c0_residency reads of the CZ timestamp may be enough to avoid this. (I don't think the C0 count reads should cause trouble, but it's possible they trigger additional punit activity as well, just by being enabled for read out in the control reg.) Deepak, Ben, or Chris, any other ideas? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/31 ------------------------------------------------------------------------ On 2015-03-05T20:30:51+00:00 Adf-lists wrote: I don't know about others but for me using Asrock Q1900dc-itx I put the latest bios (1.20) on as soon as I got it - there is nothing newer as of today. I hadn't tried a new kernel since mid Jan (a nightly) but did today and todays nightly and fixes don't boot getting ahci failed to stop engine then oops. Haven't had time to see when it changed. Can boot with pci=nocrs. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/32 ------------------------------------------------------------------------ On 2015-03-06T03:31:48+00:00 Deepak-s-8 wrote: Hi Jesse, I am suspecing the voltage change after GPU frequencey request. Can we try below options. 1. Keep the frquency at min (RPn) & run the workload. This will ensure we run at contant GPU voltage. a) cat /sys/class/drm/card0/gt_RPn_freq_mhz b) echo "value from above cmd" >/sys/class/drm/card0/gt_max_freq_mhz 2) Switch back to legacy turbo. diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 9baecb7..0dac413 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4292,12 +4292,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(&dev_priv->rps.work, gen6_pm_rps_work); INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); - /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, i915_hangcheck_elapsed); Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/33 ------------------------------------------------------------------------ On 2015-03-06T10:32:08+00:00 Adf-lists wrote: (In reply to Deepak S from comment #33) > Hi Jesse, > > I am suspecing the voltage change after GPU frequencey request. > > Can we try below options. > 1. Keep the frquency at min (RPn) & run the workload. This will ensure we > run at contant GPU voltage. > a) cat /sys/class/drm/card0/gt_RPn_freq_mhz > b) echo "value from above cmd" >/sys/class/drm/card0/gt_max_freq_mhz This alone does not fix for me - if anything it locked sooner, but then I only did 2 runs. Will try patch alone soon. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/34 ------------------------------------------------------------------------ On 2015-03-06T11:26:19+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #32) > ahci failed to stop engine then oops. > > Haven't had time to see when it changed. Can boot with pci=nocrs. In case anyone else testing on ASrock Qxxxx hits this, I bisected and there is already a bug filed - https://bugzilla.kernel.org/show_bug.cgi?id=94221 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/35 ------------------------------------------------------------------------ On 2015-03-06T16:17:14+00:00 Openelec wrote: (In reply to Deepak S from comment #33) > Hi Jesse, > > I am suspecing the voltage change after GPU frequencey request. > > Can we try below options. > 1. Keep the frquency at min (RPn) & run the workload. This will ensure we > run at contant GPU voltage. > a) cat /sys/class/drm/card0/gt_RPn_freq_mhz > b) echo "value from above cmd" >/sys/class/drm/card0/gt_max_freq_mhz Hi together, did testing Option 1 - but still the System freeze and no chance to get some relevant output in the log. ~# cat /sys/class/drm/card0/gt_RPn_freq_mhz 167 ~# cat /sys/class/drm/card0/gt_max_freq_mhz 854 ~# echo "167" >/sys/class/drm/card0/gt_max_freq_mhz ~# cat /sys/class/drm/card0/gt_max_freq_mhz 167 kind regards Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/36 ------------------------------------------------------------------------ On 2015-03-06T16:41:46+00:00 Fritsch-b wrote: Here is an OpenELEC build with option 2) integrated: https://dl.dropboxusercontent.com/u/55728161/OpenELEC- Generic.x86_64-devel-20150306172724-r20368-gb822824.tar Kernel 3.19 is used Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/37 ------------------------------------------------------------------------ On 2015-03-06T23:00:19+00:00 Adf-lists wrote: (In reply to Deepak S from comment #33) > Can we try below options. > 2) Switch back to legacy turbo. 2 is good for me so far, been running almost 12 hrs. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/38 ------------------------------------------------------------------------ On 2015-03-06T23:43:23+00:00 Openelec wrote: (In reply to Peter Frühberger from comment #37) > Here is an OpenELEC build with option 2) integrated: > https://dl.dropboxusercontent.com/u/55728161/OpenELEC-Generic.x86_64-devel- > 20150306172724-r20368-gb822824.tar > > Kernel 3.19 is used This Version runs now >2 hour without an freeze. I let it run now over night and give feedback tomorrow. kind regards Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/39 ------------------------------------------------------------------------ On 2015-03-07T08:02:45+00:00 Fritsch-b wrote: @Deepak S: What are the disadvantages for other intel processors? Can we savely include this patch in our 3.17.x backports without introducing regressions for other non BYT intel hardware? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/40 ------------------------------------------------------------------------ On 2015-03-07T08:25:36+00:00 Openelec wrote: (In reply to Juergen Froehler from comment #39) > (In reply to Peter Frühberger from comment #37) > > Here is an OpenELEC build with option 2) integrated: > > https://dl.dropboxusercontent.com/u/55728161/OpenELEC-Generic.x86_64-devel- > > 20150306172724-r20368-gb822824.tar > > > > Kernel 3.19 is used > > This Version runs now >2 hour without an freeze. I let it run now over night > and give feedback tomorrow. > > kind regards > Juergen Ok it runs now over 9 hours continuously without a freeze @Deepak S - it looks like you hit the bull's eye Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/41 ------------------------------------------------------------------------ On 2015-03-07T08:41:17+00:00 Deepak-s-8 wrote: @Peter Frühberger, The changes is specific to BYT. it should not impact any other platform. @Jesse, Shall we enable legacy turbo on BYT until we have rootcause on BYT WA? Also, Chris has submitted a cleaned up patch for "WA for Turbo and RC6 to work together" for review. Thanks Deepak Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/42 ------------------------------------------------------------------------ On 2015-03-14T20:32:43+00:00 AlexN wrote: (In reply to Juergen Froehler from comment #41) > (In reply to Juergen Froehler from comment #39) > > (In reply to Peter Frühberger from comment #37) > > > Here is an OpenELEC build with option 2) integrated: > > > https://dl.dropboxusercontent.com/u/55728161/OpenELEC-Generic.x86_64-devel- > > > 20150306172724-r20368-gb822824.tar > > > > > > Kernel 3.19 is used > > > > This Version runs now >2 hour without an freeze. I let it run now over night > > and give feedback tomorrow. > > > > kind regards > > Juergen > > Ok it runs now over 9 hours continuously without a freeze > @Deepak S - it looks like you hit the bull's eye Unfortunately I had a freeze after about 4 hours :-( Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/43 ------------------------------------------------------------------------ On 2015-03-14T20:46:49+00:00 AlexN wrote: S(In reply to Alex N from comment #43) > (In reply to Juergen Froehler from comment #41) > > (In reply to Juergen Froehler from comment #39) > > > (In reply to Peter Frühberger from comment #37) > > > > Here is an OpenELEC build with option 2) integrated: > > > > https://dl.dropboxusercontent.com/u/55728161/OpenELEC-Generic.x86_64-devel- > > > > 20150306172724-r20368-gb822824.tar > > > > > > > > Kernel 3.19 is used > > > > > > This Version runs now >2 hour without an freeze. I let it run now over > > > night > > > and give feedback tomorrow. > > > > > > kind regards > > > Juergen > > > > Ok it runs now over 9 hours continuously without a freeze > > @Deepak S - it looks like you hit the bull's eye > > Unfortunately I had a freeze after about 4 hours :-( Sorry, just recognized, that my system hasn't been updated correctly! Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/44 ------------------------------------------------------------------------ On 2015-03-15T06:17:43+00:00 Openelec wrote: Ok, now I use the patched Kernel from Peter 3.19.1-legacy-turbo+ since 1 week and had no freeze. Therefore I would say this works so far as a interim fix until the root cause is found. If you have new findings or upcoming patches to test out I am glad to support as much as I can. kind ragrds Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/45 ------------------------------------------------------------------------ On 2015-03-18T11:22:28+00:00 Daniel-ffwll wrote: Deepak, can you pls submit a proper patch for option 2), maybe restricted to just vlv to intel-gfx? Hanging machines are a pretty serious regression, I'd like to see this resolved. We'd need to make sure that this isn't an issue on chv ofc, but that can happen after the functional revert. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/46 ------------------------------------------------------------------------ On 2015-03-18T14:52:53+00:00 Deepak-s-8 wrote: @Daniel, I will submit the patch & Also, WA not enabled for CHV so there should be any problem. Btw, Chris has cleaned up patches for "WA for Turbo and RC6 to work" should we try that? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/47 ------------------------------------------------------------------------ On 2015-03-18T14:55:40+00:00 Chris Wilson wrote: They are worth trying again afterwards. I don't think they avoid the fundamental issue here which appears to be the PCU itself. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/48 ------------------------------------------------------------------------ On 2015-03-19T16:28:09+00:00 Adf-lists wrote: (In reply to Deepak S from comment #47) > @Daniel, I will submit the patch & Also, WA not enabled for CHV so there > should be any problem. > > Btw, Chris has cleaned up patches for "WA for Turbo and RC6 to work" should > we try that? I noticed some new patches went into a nightly (18th). c4d390d drm/i915: Use down ei for manual Baytrail RPS calculations 168ebd7 drm/i915: Improved w/a for rps on Baytrail It's a bit early to say anything conclusive, but I have so far not locked running that, but then I only did a few hours yesterday + currently up to 7 today. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/49 ------------------------------------------------------------------------ On 2015-03-25T14:45:47+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #49) > (In reply to Deepak S from comment #47) > > @Daniel, I will submit the patch & Also, WA not enabled for CHV so there > > should be any problem. > > > > Btw, Chris has cleaned up patches for "WA for Turbo and RC6 to work" should > > we try that? > > I noticed some new patches went into a nightly (18th). > > c4d390d drm/i915: Use down ei for manual Baytrail RPS calculations > 168ebd7 drm/i915: Improved w/a for rps on Baytrail > > It's a bit early to say anything conclusive, but I have so far not locked > running that, but then I only did a few hours yesterday + currently up to 7 > today. I've done many hours of running since and I am still stable. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/50 ------------------------------------------------------------------------ On 2015-03-25T21:33:38+00:00 Jesse Barnes wrote: Ok, looks like we worked around this one then with the commits mentioned. Thanks a lot for testing Juergen. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/51 ------------------------------------------------------------------------ On 2015-03-29T08:12:43+00:00 Openelec wrote: Thank you all for supporting here my personal summary after long time test period: mainline kernel between 3.13 -> 3.16 do not have the freeze issue every mainline Kernel between 3.17.x -> 3.19.2 the freeze appear fast & frequently mainline Kernel 3.19.3 (without legacy turbo fix) - rarely random freeze (I had just one in 4 days - still early to say more) but less as before patched Kernel 3.19.x + legacy turbo fix - running rock solid = no freeze over long time period therefore the Kernel with the legacy turbo fix is for me in the moment the best result for daily usage. I did not test any of the 4.x Kernels yet - if needed I will do. kind regards Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/52 ------------------------------------------------------------------------ On 2015-03-31T06:32:02+00:00 Openelec wrote: a short update & feedback from my side, perhaps it might be worth knowing. I had time to run the latest mainline Kernel 4.0.0-040000rc5.201503230035 during the last 2 days and my findings are that the freeze still exist. kind regards Juergen Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/53 ------------------------------------------------------------------------ On 2015-03-31T07:34:28+00:00 Adf-lists wrote: (In reply to Juergen Froehler from comment #53) > a short update & feedback from my side, perhaps it might be worth knowing. I > had time to run the latest mainline Kernel 4.0.0-040000rc5.201503230035 > during the last 2 days and my findings are that the freeze still exist. >From what I can see the fixes above that I am still running aren't in drm-intel-fixes so I guess not anything mainline? They are in drm-intel- next-fixes. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/54 ------------------------------------------------------------------------ On 2015-04-08T17:15:22+00:00 Adf-lists wrote: Todays nightly 2015-04-08 locks again. I've been running nightly from 03-18 without issue till now - tested new kernel as I noticed that some more Baytrail changes went in eg. Agressive downclocking on Baytrail I'll try reverting it and running later. FWIW when I hard lock the picture is always still on screen - just thought I'd mention it. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/55 ------------------------------------------------------------------------ On 2015-04-08T18:34:48+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #55) > Todays nightly 2015-04-08 locks again. > Agressive downclocking on Baytrail > > I'll try reverting it and running later. Still locks with that reverted. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/56 ------------------------------------------------------------------------ On 2015-04-08T22:06:42+00:00 Openelec wrote: @ Andy I still use heavily the patched 3.19.1 kernel from Fritsch as my daily beast without any freeze. And to confirm - same on my device when the freeze happens within the unpatched Kernels the last pictures is visible - it looks like just "frozen" Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/57 ------------------------------------------------------------------------ On 2015-04-08T22:56:48+00:00 Adf-lists wrote: (In reply to Juergen Froehler from comment #57) > @ Andy > I still use heavily the patched 3.19.1 kernel from Fritsch as my daily beast > without any freeze. > And to confirm - same on my device when the freeze happens within the > unpatched Kernels the last pictures is visible - it looks like just "frozen" Yea, I was stable with the patch on here or with the nightly that didn't have the patch but did have the commits I mentioned above. Something regressed - It seems trying to bisect the nightly tree isn't going to work - the first try was bad and I got "the merge base xxxx is bad this means the bug was fixed between xxxx and yyyy" :-( Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/58 ------------------------------------------------------------------------ On 2015-04-10T18:43:12+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #56) > (In reply to Andy Furniss from comment #55) > > Todays nightly 2015-04-08 locks again. > > > Agressive downclocking on Baytrail > > > > I'll try reverting it and running later. > > Still locks with that reverted. I tried again a bisect on a different branch = drm-intel-next-queued I managed to arrange not to hit any merges and the bisect did call 8fb55197e64d5988ec57b54e973daeea72c3f2ff drm/i915: Agressive downclocking on Baytrail In fact while sitting on that commit for the first time ever I locked without the use of kodi. Just fast scrolling in a maximised xterm from a make modules_install. Generally the locks were much quicker than I am used to - 5-10 mins with kodi. Just to confuse things, on the older nightly, as I said above, I still locked with this reverted - on the new branch (which has more new commits since I tested the nightly) I so far haven't locked with it reverted. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/59 ------------------------------------------------------------------------ On 2015-04-13T19:23:20+00:00 Mazout360 wrote: Q1900DC-ITX here. Been having GPU hangs since 3.19 on kodi/chrome, but it stopped right after a self-compiled 4.0.0-rc6 kernel from drm-intel-nightly (right before the 70 patch set by Chris Wilson). I can confirm that the newer >RC7 regressed and the GPU hangs "seems" to happen quicker. I also noticed some serious intermittent stuttering on some videos (ie. CBS.com online) every ~1-2 minutes with the patchset. I can provide logs if required. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/60 ------------------------------------------------------------------------ On 2015-04-13T20:14:50+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #59) > Just to confuse things, on the older nightly, as I said above, I still > locked with this reverted. I recreated the test on nightly where I thought I still locked with 8fb55197e64d5988ec57b54e973daeea72c3f2ff drm/i915: Agressive downclocking on Baytrail reverted and I didn't lock, so it seems I messed up somewhere for that test initially. So reverting above alone does make me stable on both the nightly I first tested with and drm-intel-next-queued (tested as it was over the weekend). Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/61 ------------------------------------------------------------------------ On 2015-04-15T13:36:51+00:00 Mazout360 wrote: (In reply to Andy Furniss from comment #61) > 8fb55197e64d5988ec57b54e973daeea72c3f2ff > drm/i915: Agressive downclocking on Baytrail > > reverted and I didn't lock, so it seems I messed up somewhere for that test > initially. > > So reverting above alone does make me stable on both the nightly I first > tested with and drm-intel-next-queued (tested as it was over the weekend). Maybe not. I just tried this (latest drm-intel-next-queued with the commit reverted) and I locked after ~2 hours uptime (couldn't get logs, everything hung up including ssh). Definitely more stable without the commit (less stutter in 1080p video playback), but I had over 50 hours of uptime with 4.0.0-RC6 without any issue. Maybe there's something wrong elsewhere ? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/62 ------------------------------------------------------------------------ On 2015-04-16T17:16:56+00:00 Adf-lists wrote: (In reply to Maxime Bergeron from comment #62) > (In reply to Andy Furniss from comment #61) > > 8fb55197e64d5988ec57b54e973daeea72c3f2ff > > drm/i915: Agressive downclocking on Baytrail > > > > reverted and I didn't lock, so it seems I messed up somewhere for that test > > initially. > > > > So reverting above alone does make me stable on both the nightly I first > > tested with and drm-intel-next-queued (tested as it was over the weekend). > > Maybe not. I just tried this (latest drm-intel-next-queued with the commit > reverted) and I locked after ~2 hours uptime (couldn't get logs, everything > hung up including ssh). Definitely more stable without the commit (less > stutter in 1080p video playback), but I had over 50 hours of uptime with > 4.0.0-RC6 without any issue. Maybe there's something wrong elsewhere ? Yea, I updated yesterday after seeing this and did manage to lock next- queued. Possibly not anything recent, though, as it seems whether I lock or not now depends on how I test - 1080i30 (+deint) with some 1080p60 on 60Hz display = lock. I had been testing before with 1080p24 or 1080i25 and retried like this today - it's still running after 9 Hours. Given the above the next commit I will try reverting in addition to aggressive downclock = 6ad790c0f5ac55fd13f322c23519f0d6f0721864 drm/i915: Boost GPU frequency if we detect outstanding pageflips and I will run samples where frame/field rate = refresh. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/63 ------------------------------------------------------------------------ On 2015-04-28T09:39:22+00:00 Adf-lists wrote: (In reply to Andy Furniss from comment #63) > (In reply to Maxime Bergeron from comment #62) > > (In reply to Andy Furniss from comment #61) > > > 8fb55197e64d5988ec57b54e973daeea72c3f2ff > > > drm/i915: Agressive downclocking on Baytrail > > > > > > reverted and I didn't lock, so it seems I messed up somewhere for that > > > test > > > initially. > > > > > > So reverting above alone does make me stable on both the nightly I first > > > tested with and drm-intel-next-queued (tested as it was over the weekend). > > > > Maybe not. I just tried this (latest drm-intel-next-queued with the commit > > reverted) and I locked after ~2 hours uptime (couldn't get logs, everything > > hung up including ssh). Definitely more stable without the commit (less > > stutter in 1080p video playback), but I had over 50 hours of uptime with > > 4.0.0-RC6 without any issue. Maybe there's something wrong elsewhere ? > > Yea, I updated yesterday after seeing this and did manage to lock > next-queued. > > Possibly not anything recent, though, as it seems whether I lock or not now > depends on how I test - 1080i30 (+deint) with some 1080p60 on 60Hz display = > lock. I had been testing before with 1080p24 or 1080i25 and retried like > this today - it's still running after 9 Hours. > > Given the above the next commit I will try reverting in addition to > aggressive downclock = > > 6ad790c0f5ac55fd13f322c23519f0d6f0721864 > drm/i915: Boost GPU frequency if we detect outstanding pageflips > > and I will run samples where frame/field rate = refresh. Time passes - I had been slowly trying to find a guilty commit, but I gave up as the history for drm-intel-next-queued looks totally different depending where I am so it's hard to find anything. I can lock on the commit before Agressive downclocking on Baytrail but not with kodi - the only way I found was "make modules_install" which is quite strange - I made a prog that scrolls at variable rates but that didn't work. Trying to test with make going back in the history didn't get very far as I soon found that history is inconsistent due to the merges so I would test a commit (git reset --hard) fail, look at the history and choose an earlier commit then find that when reset on that the history was totally different and I was testing without the commits that "fixed" the issue in the first place c4d390d drm/i915: Use down ei for manual Baytrail RPS calculations 168ebd7 drm/i915: Improved w/a for rps on Baytrail even though the previous history/log had them way down after the new place I wanted to try. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/64 ------------------------------------------------------------------------ On 2015-04-28T22:54:38+00:00 Mazout360 wrote: (In reply to Andy Furniss from comment #64) > Trying to test with make going back in the history didn't get very far as I > soon found that history is inconsistent due to the merges so I would test a > commit (git reset --hard) fail, look at the history and choose an earlier > commit then find that when reset on that the history was totally different > and I was testing without the commits that "fixed" the issue in the first > place > > c4d390d drm/i915: Use down ei for manual Baytrail RPS calculations > 168ebd7 drm/i915: Improved w/a for rps on Baytrail > > even though the previous history/log had them way down after the new place I > wanted to try. Yes indeed it gets complicated with merges. Personally if I compile virgin/testing/drm-intel as of today, I get a GPU hang on kodi boot (attached dmesg-4.0.0 and crashlog-4.0.0) with a segmentation fault. Else, if I revert before the patchset including: 8fb55197e64d5988ec57b54e973daeea72c3f2ff drm/i915: Agressive downclocking on Baytrail It does work, although with the patchset too but it ends up hanging with >=1080p videos. That's weird as this commit doesn't seem to be linked to the original problem, so it's like if this was simply exacerbating another underlying, older issue that might've been missed. For now I'm running 4.1 from Linus github and it works fine...for now. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/65 ------------------------------------------------------------------------ On 2015-04-28T22:55:20+00:00 Mazout360 wrote: Created attachment 115414 Crashlog GPU Hang on drm-intel-nightly 4.0.0 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/66 ------------------------------------------------------------------------ On 2015-04-28T22:55:58+00:00 Mazout360 wrote: Created attachment 115415 Dmesg - drm-intel-nightly 4.0.0 Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/67 ------------------------------------------------------------------------ On 2015-05-04T10:22:14+00:00 Adf-lists wrote: I tried a kernel.org 4.1-rc1 tar over the weekend and though I didn't lock with kodi, I could quite easily lock with a few "make modules_install" in a row. I do this after kodi has been running some time. Of course my ddx and measa are new so likely different to other peoples - but I have so far still failed to lock 3.16.7 using the same test method with the same currentish ddx/mesa. Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/68 ------------------------------------------------------------------------ On 2015-05-05T05:46:50+00:00 Openelec wrote: Well I have the next days some free time, therefore I am able to do some tests. On which Tree I should jump to do Kernel testing on my device to get a qualified feedback for the Devs? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/69 ------------------------------------------------------------------------ On 2015-07-29T15:15:58+00:00 Jesse Barnes wrote: Deepak, any update here? Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/87 ------------------------------------------------------------------------ On 2015-07-29T15:30:02+00:00 Deepak-s-8 wrote: Hi Jesse, I thought improved rps patches from Chris helped us to resolve the issue. Can enable the legacy turbo back and see if it helps? diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 9baecb7..0dac413 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4292,12 +4292,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(&dev_priv->rps.work, gen6_pm_rps_work); INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work); - /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work, i915_hangcheck_elapsed); based on the comments looks like we are hitting the issue after enabling aggressive downclocking. I will check the patch again to see if we can potential fix. 8fb55197e64d5988ec57b54e973daeea72c3f2ff drm/i915: Agressive downclocking on Baytrail Thanks Deepak Reply at: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video- intel/+bug/1453298/comments/88 ** Changed in: xserver-xorg-video-intel Status: Unknown => Confirmed ** Changed in: xserver-xorg-video-intel Importance: Unknown => Medium ** Bug watch added: Linux Kernel Bug Tracker #94221 http://bugzilla.kernel.org/show_bug.cgi?id=94221 -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-video-intel in Ubuntu. https://bugs.launchpad.net/bugs/1453298 Title: Xubuntu freeze once a day To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1453298/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
