Bug 19227

Changing Component to RPM Packages, because if kernel-4.8.0 doesn't get packaged, it won't be on the isos, and when it gets packaged, it'll be on the isos that are released afterwards.

Assigning to all packagers collectively, since the registered maintainer for this went MIA.

@ Shlomi, blino, pterjan

Do you think this should be a release blocker for, at least, the Live DVDs?

@ Shlomi

Can this bug be re-assigned to you?

CC: sysadmin-bugs => ennael1, mageia, marja11, pterjan, shlomif
Component: Release (media or process) => RPM Packages
Source RPM: (none) => kernel-4.7.0-2.mga6
Assignee: bugsquad => pkg-bugs
Keywords: (none) => 6RC

Hi all,

(In reply to Marja van Waes from comment #1)
> Changing Component to RPM Packages, because if kernel-4.8.0 doesn't get
> packaged, it won't be on the isos, and when it gets packaged, it'll be on
> the isos that are released afterwards.
> 
> Assigning to all packagers collectively, since the registered maintainer for
> this went MIA.
> 
> @ Shlomi, blino, pterjan
> 
> Do you think this should be a release blocker for, at least, the Live DVDs?
> 

no idea - it seems pretty serious.

> @ Shlomi
> 
> Can this bug be re-assigned to you?

I guess. Can we backport that commit into the 4.7.2 kernel?

(In reply to Shlomi Fish from comment #2)
> (In reply to Marja van Waes from comment #1)

> > @ Shlomi, blino, pterjan
> > 
> > Do you think this should be a release blocker for, at least, the Live DVDs?
> > 
> 
> no idea - it seems pretty serious.

Setting to release blocker to avoid missing one.... priority can be lowered later, if esteemed better.
> 
> > @ Shlomi
> > 
> > Can this bug be re-assigned to you?
> 
> I guess. Can we backport that commit into the 4.7.2 kernel?

Thanks a lot! Could you give it a try? (I haven't searched to see whether anyone already backported that commit, though)

Priority: Normal => release_blocker
Assignee: pkg-bugs => shlomif
Blocks: (none) => 15527

Hi!

The problem fixed by the commit is not present below kernel 4.8-rc1 and we have kernel 4.7.x, see:

<rindolf> Hi all! Does the commit referenced in https://bugs.mageia.org/show_bug.cgi?id=19227 affect kernel 4.7.3? I don't see arch/x86/lib/hweight.S in "git checkout v4.7" or in the tarball, but the commit is older than the tag in the git log. Any help will be appreciated.
<peterz> rindolf: nope, v4.8-rc1
<rindolf> peterz: OK, thanks!

(OFTC, #kernelnewbies )

Closing as INVALID. Thanks!

Status: NEW => RESOLVED
Resolution: (none) => INVALID

  It has not fixed 'the issue' but rather than this a bunch of issues like also:
https://bugzilla.kernel.org/show_bug.cgi?id=88801
https://bugs.freedesktop.org/show_bug.cgi?id=93887

  At least these two issues have been here with 4.5.0-rc6 and likely also before. I do not know which other issues have been affected; - but obviously not just 'the issue' present since 4.8-rc1.

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED

  It is correct that 4.8-rcX still has issues; nonetheless I`d still believe that waiting for 4.8.0 could be beneficial at least if you do not have any pressure to release quickly (see also: bug 19266).

Hi Elmar,
'
(In reply to Elmar Stellnberger from comment #5)
>   It has not fixed 'the issue' but rather than this a bunch of issues like
> also:
> https://bugzilla.kernel.org/show_bug.cgi?id=88801
> https://bugs.freedesktop.org/show_bug.cgi?id=93887
> 
>   At least these two issues have been here with 4.5.0-rc6 and likely also
> before. I do not know which other issues have been affected; - but obviously
> not just 'the issue' present since 4.8-rc1.

Reading the first link it seems the problem was not fixed by the particular patch in that particular commit directly, but rather was fixed by patches that were applied up to that point. The 65ea11ec6a82b1d44aba62b59e9eb20247e57c6e commit is a fix to an assembly routine that was introduce in 4.8-rc1 and references a file that is not present in the 4.7.x kernels, where a routine written in C was used instead. So we cannot "Cherrypick" it as is.

Please comment.

ok; if you can not cherrypick it then you can`t. Concerning the first bug (SCM PCMCIA reader) you may get a wrong impression by solely skimming through it as the main issue was in deed resolved by or before 65ea11ec6a...; the backtrace that took so long to be resolved did not cause any functional deficiencies though (and was resolved by a one liner replacing = by |= when setting the flags).

  However I need to confess that I have mainly tested the UltraHD capabilities of kernel 4.7.2 with nouveau and my NVIDIA Corporation G96GLM [Quadro FX 770M]. It is possible that everything works fine with radeon based cards.

  Besides this, some new issues lately appeared to have arosen between 4.8.0-rc1 and 4.8.0-rc4:
* https://bugs.freedesktop.org/show_bug.cgi?id=97614  ... not resolved with rc5+, yet
* https://bugzilla.kernel.org/show_bug.cgi?id=156251  ... might already be resolved though I am not sure about this

  As a consequence I can not guarantee when so far kernel 4.8.x may become sufficiently stable to ship it.

Have you tried the 4.8.1 we now have?

CC: (none) => fri

Fixed, we ship 4.8.2.

If it still doesn't work as expected, it should probably be further discussed upstream - we can of course still backport relevant patches when they exist.

Status comment: Reopened, OP wants us to upgrade to 4.8 when it's out to improve UltraHD support => We now ship 4.8.2.
Status: REOPENED => RESOLVED
Resolution: (none) => FIXED