© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
Awesome! So per your results, the problem was introduced with the 2.6.36 series, in 2.6.36-rc1, which chronologically is the first one that fails.
Since 2.6.35 works fine (all the 2.6.35.x are maintenance releases for that series, done *after* work started on the 2.6.36 series) I think the problem must lie in one of the changes introduced in 2.6.36-rc1.
So the problem lies in one of the code changes done between those two releases.
Without any more knowledge about which file has the problem, we'd have to look at the changes one by one (and there are about 8000 of them). Looks like a bisection process would be the way to go.
I can point you to this document on how to do it:
https:/
One problem with that doc is that it assumes you're using the Ubuntu kernel source tree, whereas we'd prefer to use the mainline tree. Or you could use the Ubuntu tree (the one for Natty, for instance) and set v2.6.35 as your good point and v2.6.36-rc1 as the bad point. Compile and test each produced kernel and tell the bisect process whether they're good or bad to get the next kernel.
You'll probably have to test about 15 kernels for this, so it'll be a rather lengthy process :(
If you want to try this yourself (and I think you have the skills to do it) it's OK, but if you have any questions or would prefer me to compile the kernels and just upload them for you to test, please let me know; we're here to help.
Thanks!