Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Linux kernel 4.19 #48828

Closed
NeQuissimus opened this issue Oct 22, 2018 · 14 comments
Closed

Linux kernel 4.19 #48828

NeQuissimus opened this issue Oct 22, 2018 · 14 comments
Labels
6.topic: kernel 8.has: package (new) 8.has: package (update) 9.needs: changelog 9.needs: community feedback
Milestone
19.03

Comments

@NeQuissimus
Copy link
Member

NeQuissimus commented Oct 22, 2018 •
edited
Loading

I just added the kernel version 4.19 in 2bb68c7.

Since 4.19 is meant to become the next LTS kernel.
Because of this, we should keep track of the breakage the above commit causes to kernel modules etc.
I highly encourage testing with 4.19 and reporting back here.

Edit: Just updated my P320 ThinkStation and everything looks good.
@NeQuissimus NeQuissimus added this to the 19.03 milestone Oct 22, 2018
@dtzWill
Copy link
Member

dtzWill commented Oct 24, 2018 •
edited
Loading

Been working well for me here -- Dell XPS 9560.

When would it make sense to bump the headers to 4.19 as well?

@NeQuissimus
Copy link
Member Author

Any time is fine with me.

@c0bw3b
Copy link
Contributor

c0bw3b commented Nov 21, 2018

One issue with nvidiaLegacy340 : #50707

@aszlig
Copy link
Member

aszlig commented Dec 7, 2018

We also have another issue with our tests that seems to have to do with the overlayfs changes in kernel 4.19. After a bisect, I found this commit to be the culprit and after reverting said commit plus fixing the arguments of d_real(), our kernel-latest test succeeds.

@aszlig
Copy link
Member

aszlig commented Dec 7, 2018

Just reported this to the upstream maintainer.

@aszlig
Copy link
Member

aszlig commented Dec 16, 2018

As a temporary mitigation to those who run into that issue, you can use this NixOS module which contains the revert (and fix of the d_real function args) of the commit introducing the issue.

@domenkozar
Copy link
Member

4.19 was set as default in master, but we've missed the patch. @samueldr is investigating.

samueldr added a commit to samueldr/nixpkgs that referenced this issue Dec 26, 2018
@samueldr
linuxPackages_4_{19,20}: works around bug with overlayfs.
de86af4 
See: NixOS#48828 (comment)
@samueldr samueldr mentioned this issue Dec 26, 2018
Merged
domenkozar pushed a commit that referenced this issue Dec 26, 2018
@samueldr @domenkozar
linuxPackages_4_{19,20}: works around bug with overlayfs.
889ef35 
See: #48828 (comment)
@samueldr samueldr mentioned this issue Dec 28, 2018
Merged
@periklis
Copy link
Contributor

periklis commented Jan 4, 2019 •
edited
Loading

i can report having trouble with i915 on my T480 with 4.19. CPU load peaks and makes the system unusable.

Edit: My configuration uses the xorg intel drivers according to the log.

@gebner
Copy link
Member

gebner commented Jan 4, 2019

@periklis Are you using dmcrypt by chance? I'm also experiencing high CPU loads which make the system unresponsive (mainly when running nixos-rebuild). This feels a lot like the issue described here: https://bugzilla.kernel.org/show_bug.cgi?id=199857

@periklis
Copy link
Contributor

periklis commented Jan 4, 2019

@gebner Yes i've a luks encrypted zfs-formatted disk.

@periklis
Copy link
Contributor

periklis commented Jan 4, 2019 •
edited
Loading

However i am not sure if it is an issue with the mentioned bug. I have not observed any dmcrypt process or so like hammering my CPU. Only some kworker processing events producing high load.

Edit: I am seeing the cpu load behavior when i connect an external monitor and run xrandr to configure it.

@periklis
Copy link
Contributor

periklis commented Jan 9, 2019

@gebner i found the cause of my issue. I can confirm that it is not the linux kernel but the missing xorg nvidia driver on my T480 causing the freezes.

@ElvishJerricco
Copy link
Contributor

@aszlig Can you link your bug report?

@vcunat
Copy link
Member

vcunat commented Jan 29, 2019

I'd go here: #54509

samueldr added a commit to samueldr/nixpkgs that referenced this issue Feb 2, 2019
@samueldr
Revert "linuxPackages: 4.14 -> 4.19"
048c36c 
This reverts commit b861ebb.

The current issues (See NixOS#54509 and NixOS#48828) are causing headaches to
users of the unstable branches.
@samueldr samueldr mentioned this issue Feb 2, 2019
Merged
@aszlig aszlig closed this as completed in 12efcc2 Mar 18, 2019
aszlig added a commit that referenced this issue Mar 21, 2019
@aszlig
Merge overlayfs fix, LTS kernel bump and test
a36b965 
In Linux 4.19 there has been a major rework of the overlayfs
implementation and it now opens files in lowerdir with O_NOATIME, which
in turn caused issues in our VM tests because the process owner of QEMU
doesn't match the file owner of the lowerdir.

The crux here is that 9p propagates the O_NOATIME flag to the host and
the guest kernel has no way of verifying whether that flag will lead to
any problems beforehand.

There is ongoing work to possibly fix this in the kernel, but it will
take a while until there is a working patch and consensus.

So in order to bring our default kernel back to 4.19 and of course make
it possible to run newer kernels in VM tests, I'm merging a small QEMU
patch as an interim solution, which we can drop once we have a working
fix in the next round of stable kernels.

Now we already had Linux 4.19 set as the default kernel, but that was
subsequently reverted in 048c36c
because the patch we have used was the revert of the commit I bisected a
while ago.

This patch broke overlayfs in other ways, so I'm also merging in a VM
test by @bachp, which only tests whether overlayfs is working, just to
be on the safe side that something like this won't happen in the future.

Even though this change could be considered a moderate mass-rebuild at
least for GNU/Linux, I'm merging this to master, mainly to give us some
time to get it into the current 19.03 release branch (and subsequent
testing window) once we got no new breaking builds from Hydra.

Cc: @samueldr, @lheckemann

Fixes: #54509
Fixes: #48828
Merges: #57641
Merges: #54508
(cherry picked from commit 12efcc2)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
6.topic: kernel 8.has: package (new) 8.has: package (update) 9.needs: changelog 9.needs: community feedback
Projects
None yet
Milestone
19.03
Development

No branches or pull requests
9 participants
@domenkozar @periklis @aszlig @gebner @NeQuissimus @dtzWill @ElvishJerricco @vcunat @c0bw3b