The 4.10.8 stable update contains a number of important fixes across the tree
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2017-93dec9eba5
Please login to add feedback.
0 | 3 | Test Case kernel regression |
This update has been submitted for testing by jforbes.
wfm - desktop 16GB Intel i7-3770 CPU using the Mate Desktop
Works for me, x86_64 work station. Plasma DE, Nvidia card/nouveau
works for me - but what is going on at kernel.org - release often is fine BUT every second day?
This update has been pushed to testing.
Boots here on x86_64 (Atom server, T450s, VM).
@hreindl keeping ahead of CVE's is good !
boots fine on my 64bit pc
@funfunctor: i doubt that each and evey kernel update in the past was about CVE's and even if - if it goes in a direction that you have to reboot your servers 2 or 3 times a week it's unacceptable and developemnt upstream should realize that they are no longer able to keep reasoanable quality with the current developemtn speed of new kernel versions (and no i don't talk about that bugfix releases but about way too less time between release 4.9.0 and 4.10RC)
LGTM, pass default and performance test
works for me
No regressions noted on x86_64 Ivy Bridge and i686 Diamondville.
LGTM, Thinkpad X250
@hreindl this is probably the wrong forum for this discussion; however fedora tried to keep on top of CVE's - almost every single kernel releases addresses at least half a dozen CVE's. Regarding your reboot issue, you should consider looking into live patching, i.e., kpatch.
This update has been submitted for stable by jforbes.
This update has been pushed to stable.
Hello,
Same issue as anonymous posters on previous kernel page.
This issue happens with all 4.10.x kernels released so far.
I have a nvidia GK107 card using the nouveau driver. When kde screenlocker starts, the logs are filling up with the following entry (several hundreds per second) :
nouveau 0000:01:00.0: fifo: PBDMA0: 04000000 [ACQUIRE] ch 2 [007f9e3000 Xorg[1414]] subc 0 mthd 0000 data 00000000
My PC is then not responding anymore (caps lock light wont change). Power off using the PC power button is the only option.
I also noticed that when the freeze problem above is not happening, the screenlocker still does not behave properly, since I have to kill it from the console so that I can enter my password to unlock, otherwise the field is not selectable.
Regards
Sorry for the blank comment above; just figuring out how to add comment properly.
Exact same problem as anonymous above: Fedora 25 stock 4.10.8 kernel and all earlier 4.10.x kernels. Total display lockup on KDE plasma when screen saver kicks in; intermittent: happens about every 3 - 5 times, otherwise normal screensaver. Can ssh in, but normal shutdown stalls after "shutdown now" command; only forced power cycle recovers. Have not found nouveau errors in logs but I may not know where to look. Have checked /var/log/messages and dmesg. Happy to test patched kernels.
Thanks for your ongoing great work!
@ebarkan: use "journalctl -k -b 0" to see the current kernel log. Also, if you're dealing with suspend issues or what-not, a good starting reference is: Best practice to debug Linux suspend/hibernate issues.
@dhgutteridge: Thanks for the quick response. After running all night my system finally hung again. I ran "journalctl -k -b 0" via ssh as you suggested, but no new entries whatsoever appeared since yesterday evening. I have emailed a file dump from that command to you, in case there's any thing unusual in it. I have also attached a /var/log/Xorg.0 to the email to give you details of my Nvidia video hardware.
I am not using any suspend/hibernate functionality at all. This is a desktop computer and I am only using simple "Screen Energy Saving" under KDE system settings. I do not invoke "Suspend Session" at all (left unchecked).
@ebarkan: This is better addressed on the Fedora Forum at this point, as Bodhi isn't really a good medium for discussing issues after the package in question has been pushed to stable. (Especially since we're spamming the other commenters here.) Anyway, it's possible nothing was logged because by default most priority levels of messages only get synced to disk every five minutes (see SyncIntervalSec in journald.conf[5]).