There's a lot of code churn between 2.4.9 in Jammy and the 2.5 release, a bunch of which appears to be refactoring rather than straight bugfixes or new hardware support. It also appears to drop support for setting something(?) via a msr and will instead complain about needing a newer kernel - is the Jammy kernel new enough to avoid that codepath?
What effort has been made to cherry-pick the necessary fixes for these bugs?
This is not a "no", but since there's a fair amount of code churn here I think we need a more holistic test plan - how can we ensure that these changes don't break existing systems? Would it be less work overall to cherry-pick only the necessary fixes and need less thorough testing?
Ok.
Sorry for the delay in getting to this.
There's a lot of code churn between 2.4.9 in Jammy and the 2.5 release, a bunch of which appears to be refactoring rather than straight bugfixes or new hardware support. It also appears to drop support for setting something(?) via a msr and will instead complain about needing a newer kernel - is the Jammy kernel new enough to avoid that codepath?
What effort has been made to cherry-pick the necessary fixes for these bugs?
This is not a "no", but since there's a fair amount of code churn here I think we need a more holistic test plan - how can we ensure that these changes don't break existing systems? Would it be less work overall to cherry-pick only the necessary fixes and need less thorough testing?