desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #132975
[Bug 1453298] Re: Xubuntu freeze once a day
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 <deepak.s@xxxxxxxxxxxxxxx>
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 Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1453298
Title:
Xubuntu freeze once a day
Status in xf86-video-intel:
Confirmed
Status in xserver-xorg-video-intel package in Ubuntu:
Triaged
Bug description:
Xubuntu Vivid crashes once a day with Intel Celeron J1900 / HD
Graphics, mainly when watching videos and more rarely during routine
tasks like surfing on firefox or during a skype call
- 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
I think it may be related with this bug https://bugs.freedesktop.org/show_bug.cgi?id=88012 (found via https://bbs.archlinux.org/viewtopic.php?id=195736 i have the same config but another distro)
I have tried to set "NoAccel" option to xorg conf file to true but same thing ...
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: xserver-xorg-video-intel 2:2.99.917-1~exp1ubuntu2.1
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: XFCE
Date: Sat May 9 00:11:14 2015
InstallationDate: Installed on 2015-05-02 (6 days ago)
InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422.1)
SourcePackage: xserver-xorg-video-intel
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: steve 1530 F.... pulseaudio
/dev/snd/controlC1: steve 1530 F.... pulseaudio
CurrentDesktop: XFCE
DistroRelease: Ubuntu 15.04
HibernationDevice: RESUME=UUID=fdcd8774-2dc2-4a6b-8fa8-9d3c6baa07a9
InstallationDate: Installed on 2015-05-02 (7 days ago)
InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422.1)
IwConfig:
eth0 no wireless extensions.
lo no wireless extensions.
MachineType: MEDION B269
Package: xserver-xorg-video-intel 2:2.99.917-1~exp1ubuntu2.1
PackageArchitecture: amd64
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic.efi.signed root=UUID=c1ef472e-75c1-4e99-9d2d-d8c5bdc94414 ro noprompt quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
RelatedPackageVersions:
linux-restricted-modules-3.19.0-16-generic N/A
linux-backports-modules-3.19.0-16-generic N/A
linux-firmware 1.143
RfKill:
Tags: vivid vivid
UdevLog: Error: [Errno 2] Aucun fichier ou dossier de ce type: '/var/log/udev'
Uname: Linux 3.19.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/26/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: BTLTW08.110
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: BTDD-LT
dmi.board.vendor: MEDION
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MEDION
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrBTLTW08.110:bd09/26/2014:svnMEDION:pnB269:pvr1.0:rvnMEDION:rnBTDD-LT:rvr1.0:cvnMEDION:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: B269
dmi.product.version: 1.0
dmi.sys.vendor: MEDION
To manage notifications about this bug go to:
https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1453298/+subscriptions
References
