That seems like another message to hold things off and honestly, I am getting sick and tired of it.
This thread was started March 2015.
You started to be involved in the beginning of August 2016(!) and me half way.
You posted on the 23rd of August of 2016 that this was reported.
THAT IS OVER 3 MONTHS AGO.
How about you give an honest view of what is going on and stop trying to stall?
Do you not have the guts to admit we can all go screw ourselves with this hardware that is defect from the factory out?
I think everyone has been patient long enough.
Stop stalling and start answering please.
1 of 1 people found this helpful
Just an update. Esteban seems to have crawled away somewhere after holding off and asking for my contact details.
Great progress has been made and it seemed very obvious that it was not due to efforts from him or whatever management he mentioned.
I have attacked the way of handling this per personal message and will not further elaborate on it here
A RedHat employee has created patched for the Cherry trail platform, the essential one can be found here:
If you go back to patch 1 and apply them in order, this should fix freeze issues.
Please help out testing and confirming.
I mentioned it in:
Comment #144 : Bug #1575467 : Bugs : linux package : Ubuntu
For Bay trail there was a patch posted that seems to deal with the errata in the proper way.
It's attached to the original bug, it was for 4.7, I added one for 4.8, please find it here:
For Ubuntu users like myself, I put up compiled kernels with the Bay trail freeze fix:
Arch Linux also has a patched 4.8 kernel.
I hope the terrible way intel dealth with these errata regarding Linux users will not happen again.
I also hope not too many people abandoned Linux on both server and desktop for this dumb reason of a zillion dollar company being unsupportive. The options for AMD and ARM get interesting by the day.you
Thanks to all people collaborating on the fix, please update the kernel bugzilla and ubuntu bug with your findings!
Thank you for your feedback. I am very happy to read that it helped you. Can you share your hardware and software specifics that are applicable so we can get an idea of what is affected and fixed?
I asked the original creator (Jochen Hein) to post it on the kernel mailing list, which he did.
It may need some cleaning up, I am keeping an eye on it.
Looking forward to at least processor and kernel you tested and anything more relevant you can share.
Thanks for contributing!
I've been following this bug on bugzilla.com. I really appreciate your enthusiasm. I've put up the output of 3 commands ( uname -a, lshw, lscpu ) here.... http://pastebin.com/raw/nYBF9QCL
Let me know if you want anything else. I'd be glad to help.
That is great to read . As you may have noticed the discussion is still going on there.
I think it is a good idea to try and contribute there as much as possible in the line of bug report messages.
The discussion regarding the patch is going at the moment and Len Brown who is from intel is involved in it and he made some suggestions.
While the patch seems to fix the issue it may not be the best way to do it, so the discussion is still going on.
Would you be able to try a 4.9 kernel before and after the latest patch he posted?
This auto-demotion thing may actually also be a solution.
If that patch works, it will most likely end up in the main line soon.
To Esteban: why have you been silent? Would it be possible to involve the right intel engineer next time in a timely manner, as in, to learn from this rather bad way the issue was picked up?
It seems in the end that it is still intel who has the best information on this. I understand the company is big, but I hope you do know a bit on who does kernel work and open source things?
For every one still reading here, please read/subscribe to the bug:
Kernel developer Len Brown is posting patches and tools to try and track this down.
One promising patch is one that re-enables auto demotion.
I have supplied prebuilt kernels with those patches here:
To concentrate communication, it will be great if anyone reading this takes the time to read the bug and contribute by testing patches.
As mentioned by Len, the specific bug will be closed if we do no longer need the kernel parameter on Bay trail.
Bay trail processors are:http://ark.intel.com/products/codename/55844/Bay-Trail?q=bay%20trail#@All
Note the remarks regarding Cherry trail that Hans de Goede is working on and the request to file a NEW bug if you are having freezes on another platform. It will be of great help if you contribute!
So call to all Bay trail users to contribute by trying the auto demotion patches on Bay trail and report about:
- difference in stability if any
- effect of nano sleep / output of turbo stat
- a way to reproduce the issue in a very short time (minute(s) instead of hours would be very usefull).
Please refer to the bug report and thanks everyone for your help, the more people help, the more likely this issue can be found and fixed!
I'm following the kernel.org bug you mentioned, and just finished reading the whole thread. However, where is the mention of Hans de Goede working on Cherry Trail? (I'm asking because I'm seeing the problem on a bunch of Cherry Trail devices (Atom Z8350) and I'm wondering if there's another bug I should be watching too. Thanks...
Maybe I wasn't specific .
Some of his patches can be found here:
Bug 155241 – i2c_designware 808622C1:06: punit semaphore timed out, resetting
If you type up in the last url (end in 4,5 etc) you get the consecutive patches, which need to be applied in order.
I think the best is to see if the mentioned bug report applies to you, find another one that does match if it doesn't and file a new one if you can't find anything existing.
I know that the patches Hans made gave him stability on a Cherry trail based tablet, so it may work for yours too.
This message was posted on behalf of Intel Corporation
Thank you for your contribution, Peer.
At this point my recommendation would be to create a new thread to continue with the support for this matter.