(In reply to Veronica from comment #131)
> I too can't believe why this bug hasn't been fixed yet and honestly I don't
> understand what is the final fix/workaround for this bug.
> Some people claim the cstate arg work but for others don't work.
>
> Can someone please provide me a link to latest
My apologies Mr. Frühberger , I see that I've once again re-discovered
an already existing work around. In the first post for this bug, you
revealed the cstate workaround, almost a year ago.
I've tried your patch on my freeze prone 4.2.6. It did last longer (25
minutes vs. 5 vs.) The patch
I was surprised to experience a freeze while running Android_x86 4.4-rc3
on my 2 in 1 laptop. After digging a bit - I found that the android_x86
runs on a custom linux-4.0.8. There wasn't a cstate argument in the
command line. Too soon to know if it will help, but I no longer get the
I've been running several days without a freeze on my 4.2.6 kernel. I
simply added intel_idle.max_cstate=1 to my kernel arguments, no other
power arguments, and no more setting GPU frequency caps.
intel_idle.max_cstate=0 was effective too, but my system ran warm (not
hot) when idle. At
(In reply to John from comment #117)
> I've been running several days without a freeze on my 4.2.6.
>
Update: I found info suggesting cstate limits of 0,1 & 6(default) are valid,
maybe 3, but probably not 2.
I had to boot my CHI into the OEM. When I resumed linux, I omitted the
cstate
The notes for 4.2.6 claim to fix one problem that causes GPU locks.
When I added the incremental patch set, the longest it ran was about an
hour (usually it froze within 5 minutes.) I had just stopped a 6 day
run (24/7) on my (ASUS baytrail) T100 specific 4.2.5 kernel (no args,
50% GPU cap) (with
Same here with random freezes. Tried intel_pstate=disabled which works.
However, cutting the max GPU frequency to about 50% also works for me.
Video seems smoother compared to pstate=disabled. YMMV
Running 64 bit Mint 17.2/Cinnamon on ASUS T100-CHI linux-4.2.5 w/Ubuntu
base and T100 specific
To cap frequency I read the max (779 for mine) from
cat /sys/class/drm/card0/gt_max_freq_mhz
To set pick a lower value (as root)
echo 423 > /sys/kernel/debug/dri/0/i915_max_freq
I tried lower values in 100 Mhz steps until I found stability (to 423 in
my case).
I think you could just put back
Given Luka Karinja's results, I checked my kernel args to see if
something else could account for my results. I found -
i915.i915_enable_rc6=1 i915.lvds_downclock=1 i915.semaphores=1
i915.i915_enable_fbc=1.
rc6=1 seems to be known to add instability, perhaps the freq cap offset
that. I've
(In reply to Jani Nikula from comment #105)
> i915.i915_enable_rc6 and i915.i915_enable_fbc have been renamed
> i915.enable_rc6 and i915.enable_fbc, respectively, since v3.15 so those have
> had no impact.
>
> These days all of those are considered debug options, and we taint the
> kernel if
Same here with random freezes. Tried intel_pstate=disabled which works.
However, cutting the max GPU frequency to about 50% also works for me.
Video seems smoother compared to pstate=disabled. YMMV
Running 64 bit Mint 17.2/Cinnamon on ASUS T100-CHI linux-4.2.5 w/Ubuntu
base and T100 specific
11 matches
Mail list logo
