regarding (a) and (b): I am just waiting for a rpmbuild of an OL6 version of 3.13-rc3 to finish and will report back on my findings and include a dmesg output from that version.
Regarding (c):
Would'nt it make more sense than starting with 3.6 release and 3.7 release tags to first rule out the "mega commit"?
Can you give me the git commands (or point me to a doc that tells me how to produce them) for getting "ordinary kernel tarballs" out of the DRM nouveau git just like the ones published on
(1) for the version up to the immediate commit BEFORE the "mega commit"
(2) for the version exactly matching the "mega commit"?
Using these two kernel tarballs, I could then either confirm or rule out the "mega commit" as the root cause for the issue, and in the (unlikely) case the mega commit can indeed be ruled out, I could then concentrate on further narrowing down the commits
* either between 3.6 and the mega commit if build (1) is already broken
* or between the mega commit and 3.7 if build (2) still works, but 3.7 fails?
Sorry, but rather than pulling the whole git on my poor old laptop and starting a huge number of bisection attemps "into the blue", I think that this makes more sense and does not require me to become a git expert in order to try and help tracking this down... ;-)
What do you think?
I will report back shortly with my 3.13-rc3 results...
Hello Ilia,
regarding (a) and (b): I am just waiting for a rpmbuild of an OL6 version of 3.13-rc3 to finish and will report back on my findings and include a dmesg output from that version.
Regarding (c):
Would'nt it make more sense than starting with 3.6 release and 3.7 release tags to first rule out the "mega commit"?
Can you give me the git commands (or point me to a doc that tells me how to produce them) for getting "ordinary kernel tarballs" out of the DRM nouveau git just like the ones published on
https:/ /www.kernel. org/pub/ linux/kernel/ v3.0/testing/
for two points in time in between 3.6 and 3.7:
(1) for the version up to the immediate commit BEFORE the "mega commit"
(2) for the version exactly matching the "mega commit"?
Using these two kernel tarballs, I could then either confirm or rule out the "mega commit" as the root cause for the issue, and in the (unlikely) case the mega commit can indeed be ruled out, I could then concentrate on further narrowing down the commits
* either between 3.6 and the mega commit if build (1) is already broken
* or between the mega commit and 3.7 if build (2) still works, but 3.7 fails?
Sorry, but rather than pulling the whole git on my poor old laptop and starting a huge number of bisection attemps "into the blue", I think that this makes more sense and does not require me to become a git expert in order to try and help tracking this down... ;-)
What do you think?
I will report back shortly with my 3.13-rc3 results...
BR,
Andreas