Comment 261 for bug 1470250
Revision history for this message
| Joseph Salisbury (jsalisbury) wrote | #261 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
@faulpeltz, so per you testing it looks like:
3.13 based kernel with dfbdac2e(Same commit as 89fb4cd, but using the Trusty SHA1) reverted fixes the bug.
4.2 based kernel with 89fb4cd reverted still exhibits the bug.
4.4 based kernel with 89fb4cd reverted still exhibits the bug.
This does seem to indicate that a merge or patch after 3.13 is re-introduce the logic added by commit dfbdac2e.
I directly compared trusty commit dfbdac2e and mainline commit 89fb4cd to confirm they are exactly the same. They only differ in the commit message.
Just to clarify, trusty is using a different SHA1 than the wily and xenial kernels because commit 89fb4cd1f was added to mainline in v3.16.
So it seems we are getting much closer, but further code inspection is needed to find the logic that is doing similar things in the 4.2 and 4.4 kernels. I'll dig in and see what I can find.