kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
The Ubuntu-power-systems project |
Fix Released
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
High
|
Joseph Salisbury | ||
Zesty |
Fix Released
|
High
|
Joseph Salisbury | ||
linux-hwe-edge (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Randomly, khugepaged process will take 100% CPU, and I can only restart the computer to recover it.
Relevant dmesg attached (dmesg_crash.txt).
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: linux-image-
ProcVersionSign
Uname: Linux 4.10.0-14-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC1D0p: mathieu 2221 F...m pulseaudio
/dev/snd/
CurrentDesktop: Unity:Unity7
Date: Tue Mar 21 23:03:23 2017
HibernationDevice: RESUME=
InstallationDate: Installed on 2016-01-31 (415 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160131)
MachineType: LENOVO 20344
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.164
SourcePackage: linux
UpgradeStatus: Upgraded to zesty on 2017-03-02 (19 days ago)
dmi.bios.date: 10/16/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: 96CN29WW(V1.15)
dmi.board.
dmi.board.name: INVALID
dmi.board.vendor: LENOVO
dmi.board.version: 31900058WIN
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 20344
dmi.product.
dmi.sys.vendor: LENOVO
Mathieu Marquer (slasher-fun) wrote : | #1 |
- dmesg_crash.txt Edit (47.6 KiB, text/plain)
- AlsaInfo.txt Edit (38.4 KiB, text/plain; charset="utf-8")
- CRDA.txt Edit (426 bytes, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (52.5 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
- IwConfig.txt Edit (505 bytes, text/plain; charset="utf-8")
- JournalErrors.txt Edit (15.1 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (7.1 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (567 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (3.9 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (331 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (2.7 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (8.6 KiB, text/plain; charset="utf-8")
- PulseList.txt Edit (25.7 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (248 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (176.6 KiB, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (104.7 KiB, text/plain; charset="utf-8")
description: | updated |
tags: | added: kernel-bug |
tags: | added: regression-release |
Brad Figg (brad-figg) wrote : Status changed to Confirmed | #2 |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Joseph Salisbury (jsalisbury) wrote : | #3 |
Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer to https:/
If this bug is fixed in the mainline kernel, please add the following tag 'kernel-
If the mainline kernel does not fix this bug, please add the tag: 'kernel-
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
Thanks in advance.
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | Confirmed → Incomplete |
Mathieu Marquer (slasher-fun) wrote : | #4 |
Hi,
I don't remember encountering this bug with Linux 4.8, happens about every 1-3 hours with Linux 4.10 (although I couldn't figure out a way to reproduce it).
I'll try with Linux 4.11 RC3 and tell you how it goes.
Mathieu Marquer (slasher-fun) wrote : | #5 |
So I *thnk* it's fixed in 4.11 RC3, although I'm not fully sure because I was encountering bug https:/
tags: | added: kernel-fixed-upstream |
Changed in linux (Ubuntu): | |
status: | Incomplete → Confirmed |
JockeTF (jocketf) wrote : | #6 |
This started happening for me after upgrading to Zesty.
Mathieu Marquer (slasher-fun) wrote : | #7 |
Update from me, the patch for my display crash has been included in 4.11 RC5, and I'm not encountering the kernel bug anymore there, so it's 99% definitely fixed in 4.11 branch.
tags: | added: kernel-da-key needs-reverse-bisect |
kiney (jannik-winkel) wrote : | #8 |
This problem made my system mostly unuseable since upgreading to zesty (4.10.0-19). One crash every 1-4 Hours.
Some workloads tend to trigger it faster (firefox + youtube) but the crash is unavoidable.
Desktop usage becomes completely impossible.
Normally i can sill ssh in, but only certain things work:
- top works fine, I always see one kernel thread hogging cpu. Sometimes additionally a userspace process (mostly firefox). htop hangs on exit.
- kill -9 on cpu hogging userspace process does not work - this seems weird
- trying to reboot gracefully hangs. SysRq works.
I just switched to 4.11-rc7 mainline, but its too soon to make any conclusions. I will report tomorrow.
Looking through the clones of this bug this seems to happen with quite different hardware.
My affected system is AMD x370 chipset with RyZen 7 1700X cpu.
The system was perfectly stable with yakkety (kernel 4.8.0-??)
Bryan Quigley (bryanquigley) wrote : | #9 |
I thought it was related to my system being a brand new Ryzen with ZRam and 32GB of memory (no real swap) but apparently not.
A BIOS update bricked that motherboard so I'm back on my older Phenom(tm) II X4 945 with 12 GB of RAM (now no ZRAM). Just got the issue again. Now, I have *no* swap enabled at all and still got it.
kiney (jannik-winkel) wrote : | #10 |
I also have no swap.
JockeTF (jocketf) wrote : | #11 |
I'm on a laptop with Intel Ivy Bridge.
I had no swap enabled. I haven't experienced this issue since I created a small 1GB swap file. It may be too soon to tell for sure if it's related though.
Christian Sarrasin (sxc731) wrote : | #12 |
My laptop (Kaby Lake) has 16 GB swap configured and I have encountered the issue 5 times so far; see https:/
Brannon C Bowden (bbowden) wrote : Re: [Bug 1674838] Re: kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129 | #13 |
Was on multiple i7 2600 with 2 gig swap. Took longer to occur, but still
occurred.
On Apr 18, 2017 7:31 AM, "JockeTF" <email address hidden> wrote:
> I'm on a laptop with Intel Ivy Bridge.
>
> I had no swap enabled. I haven't experienced this issue since I created
> a small 1GB swap file. It may be too soon to tell for sure if it's
> related though.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1677611).
> https:/
>
> Title:
> kernel BUG at /build/linux-
> 7LGLH_/
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> Randomly, khugepaged process will take 100% CPU, and I can only
> restart the computer to recover it.
>
> Relevant dmesg attached (dmesg_crash.txt).
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.04
> Package: linux-image-
> ProcVersionSign
> Uname: Linux 4.10.0-14-generic x86_64
> ApportVersion: 2.20.4-0ubuntu2
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: mathieu 2221 F.... pulseaudio
> /dev/snd/pcmC1D0p: mathieu 2221 F...m pulseaudio
> /dev/snd/controlC1: mathieu 2221 F.... pulseaudio
> CurrentDesktop: Unity:Unity7
> Date: Tue Mar 21 23:03:23 2017
> HibernationDevice: RESUME=
> InstallationDate: Installed on 2016-01-31 (415 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64
> (20160131)
> MachineType: LENOVO 20344
> ProcFB: 0 inteldrmfb
> ProcKernelCmdLine: BOOT_IMAGE=
> root=UUID=
> vt.handoff=7
> RelatedPackageV
> linux-restricte
> linux-backports
> linux-firmware 1.164
> SourcePackage: linux
> UpgradeStatus: Upgraded to zesty on 2017-03-02 (19 days ago)
> dmi.bios.date: 10/16/2014
> dmi.bios.vendor: LENOVO
> dmi.bios.version: 96CN29WW(V1.15)
> dmi.board.
> dmi.board.name: INVALID
> dmi.board.vendor: LENOVO
> dmi.board.version: 31900058WIN
> dmi.chassis.
> dmi.chassis.type: 10
> dmi.chassis.vendor: LENOVO
> dmi.chassis.
> dmi.modalias: dmi:bvnLENOVO:
> pn20344:
> rvr31900058WIN:
> dmi.product.name: 20344
> dmi.product.
> dmi.sys.vendor: LENOVO
>
> To manage notifications about this bug go to:
> https:/
> 1674838/
>
Andrea Bernabei (faenil) wrote : | #14 |
same bug here, after upgrading to latest Zesty packages as of yesterday. (kernel 4.10.0-19-generic)
I use firefox-trunk, the nightly build.
At one point firefox-trunk goes 100% cpu and it can't even be killed.
After a couple of minutes, the whole system freezes.
Drascus (enchantedvisionsband) wrote : | #15 |
I am also having this issue. Ever time it occurs my whole system locks up and I have to hard reset to get things working again.
kiney (jannik-winkel) wrote : | #16 |
ok. With 4.11-rc7 mainline _this_ problem seems to be fixed.
But I had another (probably) unrelated crash/reboot with no useful traces in the logs.
Oliver Egginger (lau6chpad) wrote : | #17 |
- Shows the initial kernel bug in dmesg and some dmesg log after. Edit (139.8 KiB, text/html)
Hi,
come from:
https:/
cause Launchpad told me that 1682427 is a duplicate of 1674838.
I've see the same behavior with Thunderbird. See Bug Description of 1682427. But I think that is coincidence. The problem seems to be more general. I have no I idea at the moment but can give you the dmesg output of my system. See the attached file.
I have been using Ubuntu for a year on this system. First with 16.4, then 16.10 and since some days 17.4.
Before 17.4. I never have seen such a problem. The system was stable. It's a skylake system with a 6700K CPU. I had updated my board to BIOS version 2003 half a year ago. But as I said, I could not observe the error before Zesty.
I'm curious now what's going on here.
Regards
Oliver
Dennis Sheil (dennis-sheil) wrote : | #18 |
I upgraded from 16.10 to 17.04 three days ago. I have been hit with this three times in three days. I am using my desktop, and then everything freezes.
This last time I had a little more freedom. I was using firefox when it became unresponsive. I opened up a terminal and ran "ps axu" and it hung halfway through. I did a dmesg and saw "kernel: [52312.170678] kernel BUG at /build/
Then I tried to close Firefox by hitting the close button. It popped up a force quit button which I hit. This froze my desktop GUI, even the cursor.
Joseph Salisbury (jsalisbury) wrote : | #19 |
Can you see if this bug also exists in the latest upstream stable 4.10 kernel? It can be downloaded from:
kiney (jannik-winkel) wrote : | #20 |
That was already tested here:
https:/
-> seems to be fixed/not present in upstream 4.10
Jeffery Painter (jeff-painter) wrote : | #21 |
I can report that mainline seems fine. I have not tried 4.10.11 but stopped at 4.10.8 as it is working well for me the past couple days.
painter@merlin:~$ uname -a
Linux merlin 4.10.8-
painter@merlin:~$ uptime
17:41:20 up 11:09, 1 user, load average: 0.20, 0.06, 0.02
No more crashes!
Chris Hermansen (c-hermansen) wrote : | #22 |
Joseph, kiney;
I was having the problem yesterday with 4.10.0-19-generic whose vmlinuz is dated 8 April.
I installed 4.11.0-rc7 and ran it for awhile today with no problems, but I don't have a good feeling for how long is necessary to say "I think the problem is solved".
I have now installed 4.10.11 and am running it. We'll see...
Oliver Egginger (lau6chpad) wrote : | #23 |
I also have the problem with 4.10.0-19-generic.
This is the actual kernel in Zesty.
Joseph Salisbury (jsalisbury) wrote : | #24 |
Hmm, it sounds like this bug is only happening in Ubuntu kernels and not any of the upstream kernels. That indicates this is due to a SAUCE patch. We next need to identify the last Ubuntu kernel version that did not have the bug and the first that did.
Can those affected test the following early Zesty kernel:
https:/
Note with this test kernel, you need to install both the linux-image and linux-image-extra .deb packages.
Changed in linux (Ubuntu): | |
importance: | Medium → High |
assignee: | nobody → Joseph Salisbury (jsalisbury) |
Changed in linux (Ubuntu Zesty): | |
status: | Confirmed → In Progress |
tags: |
added: performing-bisect removed: needs-reverse-bisect |
Mitchell Tasman (tasman) wrote : | #25 |
I am also experiencing the problem with 4.10.0-19-generic.
Chris Hermansen (c-hermansen) wrote : | #26 |
Joseph, for us rookies out here, can you confirm that these are the only files we need to install with the 4.10.0-8 kernel you would like tested?
linux-headers-
linux-headers-
linux-image-
linux-image-
Thanks in advance!
Joseph Salisbury (jsalisbury) wrote : | #27 |
@Chris Hermansen, you only need to install the following two:
linux-image-
linux-image-
Jeffery Painter (jeff-painter) wrote : | #28 |
Trying to test as recommended and installed linux-image-
Note to others, if you are using any proprietary drivers, you should also download and install both:
linux-headers-
linux-headers-
Required to continue using VirtualBox but will need to run /sbin/vboxconfig after installing.
I will try this one out for today and post back my results this afternoon.
Chris Hermansen (c-hermansen) wrote : | #29 |
Joseph, I'm running 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 x86_64 x86_64 x86_64 now. I'll keep you posted.
BTW no problems yesterday with 4.10.11. My wife has been using the computer for a photo project on a web-based photo book service and that is what brought about this problem in the first place.
Christian Sarrasin (sxc731) wrote : | #30 |
Hi Joseph,
As previously reported:
4.10.0-15: affected
4.10.0-14: issue not experienced in over a week
Obviously "not experienced" doesn't mean the bug isn't present. All I can say is that it was first experienced with 4.10.0-15.
Chris Hermansen (c-hermansen) wrote : | #31 |
@Joseph Salisbury my computer, running 4.10.0-8, hung just now (display frozen etc). I was running "stress". This is similar to what happened previously with respect to this bug, but there seems to be nothing but a bunch of nulls in syslog this time. Not sure how to determine whether the same bug was actividated or not... any thoughts?
Thanks in advance.
Joseph Salisbury (jsalisbury) wrote : | #32 |
Thanks for testing, Chris. Lets see if other folks hit this bug running 4.10.0-8. It might be that there are multiple bugs being hit here.
Chris Hermansen (c-hermansen) wrote : | #33 |
@Joseph Salisbury,
Running the same test on 4.10.11-
This was the test:
for t in 1 2 3 4 5 6 7 8 9 10; do echo iter $t; stress -c 2 -m 2 -t 60; dmesg; done
So I'm leaving this running for awhile and will report back.
Jeffery Painter (jeff-painter) wrote : | #34 |
I've been working pretty heavily throughout the day (Eclipse, Chrome, Thunderbird, MySQL, etc) with the 4.10.0-8 and haven't hit the bug. I will run a couple more days on this version and see if it pops up.
painter@merlin:~$ uname -a
Linux merlin 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
painter@merlin:~$ uptime
16:48:33 up 6:59, 1 user, load average: 0.36, 0.52, 0.64
Chris Hermansen (c-hermansen) wrote : | #35 |
Still no problems with 4.10.11-041011.
Joseph Salisbury (jsalisbury) wrote : | #36 |
Thanks for testing Chris. So this bug really only seems to be happening with Ubuntu kernels and not Upstream ones. We should test some earlier Zesty kernels, so we can get a last good version and first bad version. That will allow us to bisect. Can you next test the following last 4.9 based Zesty kernel:
https:/
Chris Hermansen (c-hermansen) wrote : | #37 |
@Joseph Salisbury, installed the 4.9.0-16 recommended and running now (continuing to use stress). More later...
Colin Ian King (colin-king) wrote : | #38 |
I hit this same issue today and it seems like a hugepage scanning lockup to me.
Thomas M Steenholdt (tmus) wrote : | #39 |
There must be a better way to do this...
All of these issues seem to arise from a BUG event in swapops.h:129. That particular spot is a section that's only active, when the kernel was built with CONFIG_MIGRATION=y. So first step is probably to verify that CONFIG_MIGRATION is even enabled for the mainline kernel (the configs are not the same, I'm told). So for all we know, the bug could still be upstream.
If somebody running the mainline kernel could post the output of the following command, that would be useful:
cat /boot/config-
If CONFIG_MIGRATION is enabled on mainline (CONFIG_MIGRATION=y in the output above), next step should be to check if some of the Ubuntu modifications touch in the source in any relevant places. The BUG event in swapops.h:129 seems to be hit if migration_
Perhaps this will bring us closer to the problem a bit faster?
Jeffery Painter (jeff-painter) wrote : | #40 |
I have been running this kernel a 3-4 days now without any problems.
root@merlin:~# uname -a
Linux merlin 4.10.8-
root@merlin:~# cat /boot/config-
CONFIG_MIGRATION=y
Thanks!
Chris Hermansen (c-hermansen) wrote : | #41 |
@Joseph Salisbury,
No system hangs yet with kernel 4.9.0-16. I am seeing this:
[ 8034.959275] nouveau 0000:01:00.0: gr: TRAP ch 2 [003fa69000 Xorg[1191]]
[ 8034.959288] nouveau 0000:01:00.0: gr: GPC0/TPC2/TEX: 80000009
which I am trying to ignore...
zubozrout (zubozrout) wrote : | #42 |
- top output once khugepaged takes over all resources Edit (198.5 KiB, image/gif)
Hello,
I suspect there is nothing new here but I was able to watch my system for a few minutes before it completely died and here is a gif containing output from top - with khugepaged process staying on the top of the list taking 100% of CPU resources most of the time.
Ken Haase (kh) wrote : | #43 |
- This is the syslog for the time my system was hung, recovered after reboot. It also had a bunch of NULs in the syslog before the next boot started. Edit (8.7 KiB, text/plain)
I'm able to reliably reproduce it, but I haven't been able to generate a small test case (I have to reboot every time I reproduce it). FWIW, the job which reproduces it (after a few minutes) does a lot of SMP and a fair amount of MMAPing. I'm attaching a section of the syslog that could be relevant.
I'm happy to try to run one of the intermediate 4.10.0 kernels if it would help, but I don't see them in the standard repos. Do I need to add a repository to get them? (I haven't messed with the kernel for 15 years or so.)
For actually getting work done, I'll try backing out to 4.8, but I can readily try other kernels if it would help to get this resolved.
Chris Hermansen (c-hermansen) wrote : | #44 |
@Ken Haase, here is what I do:
1. make sure you aren't running any proprietary drivers and if you are and you can back them out (use the Software > Alternative Drivers tool for this)
2. look back at the kernels @Joseph Salisbury has requested we test
https:/
files I used
linux-headers-
linux-headers-
linux-image-
linux-image-
https:/
files I used
linux-headers-
linux-headers-
linux-image-
linux-image-
http://
files I used
linux-headers-
linux-headers-
linux-image-
3. Basically what I do is:
a. download the relevant group of kernel files (above)
b. into a subdirectory that contains nothing else
c. install as sudo dpkg -i *.deb
d. reboot with my finger on the left shift key to bring up the grub menu
e. select the advanced options to get the kernel I want to test
f. when booted check with uname -a
g. run my tests
JockeTF (jocketf) wrote : | #45 |
Just had another encounter with this bug on 4.10.0-19-generic.
Swap was enabled this time through a 1 GB swap file.
Thomas M Steenholdt (tmus) wrote : | #46 |
Okay, so MIGRATION is indeed enabled on the mainline kernel too and that possibility has been ruled out - So we're not chasing ghosts. :)
Ken Haase (kh) wrote : | #47 |
Thanks @Chris Hermansen. As @Joseph Salisbury suggested, I tried 4.9.0-16, 4.10.0-8, 4.10.0-11, and 4.10.0-19 and the problem doesn't crop up until 4.10.0-19 and then does so reliably (so to speak).
Chris Hermansen (c-hermansen) wrote : | #48 |
@Ken Haase congratulations, you are a kernel-testing machine and I gladly stand in your shadow!
Your experience jibes with mine but I feel less certain since I have a hard time provoking evidence in syslog.
Harald Hannelius (harald-arcada) wrote : | #49 |
I'm having the same error. I upgraded from 16.04 -> 16.10 -> 17.04 on the same day and now my computer freezes during night. There's no reply from the dhcpd running on the computer anymore, and the screen shows the background but no login window appears. I can't ping the computer, though AltSysRq s-u-b works.
This computer has been perfectly stable up to the upgrade day, running months a a time without hickups.
Apr 23 02:54:15 morran kernel: [62573.594338] kernel BUG at /build/
Apr 23 02:54:15 morran kernel: [62573.594355] invalid opcode: 0000 [#1] SMP
Apr 23 02:54:15 morran kernel: [62573.594364] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_
Apr 23 02:54:15 morran kernel: [62573.594504] snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_seq_midi snd_seq_midi_event snd_hda_intel snd_rawmidi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq ie31200_edac lpc_ich mei_me edac_core mei nuvoton_cir rc_core snd_seq_device shpchp snd_timer snd_soc_sst_acpi snd acpi_pad elan_i2c soundcore dw_dmac dw_dmac_core snd_soc_sst_match mac_hid 8250_dw i2c_designware_
Apr 23 02:54:15 morran kernel: [62573.594644] igb e1000e drm ahci dca libahci ptp i2c_algo_bit pps_core sdhci_acpi sdhci video i2c_hid hid fjes
Apr 23 02:54:15 morran kernel: [62573.594667] CPU: 1 PID: 12615 Comm: JS Helper Not tainted 4.10.0-19-generic #21-Ubuntu
Apr 23 02:54:15 morran kernel: [62573.594682] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./C226M WS, BIOS P2.00 05/22/2015
Apr 23 02:54:15 morran kernel: [62573.594701] task: ffff9ec485271680 task.stack: ffffb43505ca0000
Apr 23 02:54:15 morran kernel: [62573.594716] RIP: 0010:__
Apr 23 02:54:15 morran kernel: [62573.594726] RSP: 0000:ffffb43505
Apr 23 02:54:15 morran kernel: [62573.594737] RAX: 0017ffffc0048078 RBX: ffffe067e0204070 RCX: ffffe067e0204070
Apr 23 02:54:15 morran kernel: [62573.594751] RDX: 0000000000000001 RSI: ffff9ec48...
Sven (s-v-e-n) wrote : | #50 |
+1, experiencing this since I've upgraded from 16.10 to 17.04, every few hours the system freezes. Really annoying ...
kernel: [ 4075.895491] kernel BUG at /build/
kernel: [ 4075.895523] invalid opcode: 0000 [#2] SMP
Olivier Febwin (febcrash) wrote : | #51 |
same issue here!
Thunderbird freeze and after few seconds, system freeze
Fabian Grünbichler (f-gruenbichler) wrote : | #52 |
the only big mm changes pulled in from 4.11.x that I could find with a quick look through the history are related to KSM, but those are missing a later fixup (from 4.11.x as well):
d75450ff40df019
ace71a19cec5 was first contained in Ubuntu-
there are also a few other commits by the same upstream author, which do not explicitly contain any followup/fixes tags but touch similar code, some of which were picked.
since I cannot reproduce the problem at hand, I cannot tell whether including that fixup helps, but it might be worth a shot.
Andrey Arapov (andrey-arapov) wrote : | #53 |
- dmesg-firefox-kernel-swap-bug.txt Edit (33.3 KiB, text/plain)
Hi there.
I have encountered the same issue as Dennis Sheil in https:/
The same way, was using firefox which in turn became unresponsive.
The difference is that I am running firefox v53.0 in docker (v17.04.0-ce) using ``--kernel-
Please find attached dmesg logs in dmesg-firefox-
Linux kernel ver. 4.10.0-19-generic
And below are some outputs while I've hit that problem, hopefully some useful info in there:
```
$ df (hanged)
root@sony:~# ps auxww |grep Z
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
arno 8866 5.0 0.0 0 0 ? Zl 00:18 70:14 [firefox] <defunct>
arno 8908 10.2 0.0 0 0 ? Z 00:18 142:19 [Web Content] <defunct>
arno@sony:~$ mount |grep -i docker
rpool/docker on /var/lib/docker type zfs (rw,nodev,
rpool/docker on /var/lib/docker/zfs type zfs (rw,nodev,
rpool/docker/
shm on /var/lib/
nsfs on /run/docker/
```
Very strange part is that my SWAP file got reduced itself down to 16MiB:
```
root@sony:~# swapoff -a
hanged ...
though reduced swap usage down to 16M (and Swap Total !!)
arno@sony:~$ free -mh
total used free shared buff/cache available
Mem: 7.7G 1.9G 3.5G 710M 2.3G 3.6G
Swap: 16M 16M 0B
arno@sony:~$ free -b
total used free shared buff/cache available
Mem: 8270503936 2048671744 3625005056 745644032 2596827136 3855400960
Swap: 17055744 17055744 0
```
Whilst, I should normally have 8GiB swap:
```
root@sony:~# free -mh
total used free shared buff/cache available
Mem: 7.7G 2.0G 4.1G 473M 1.6G 4.4G
Swap: 8.0G 0B 8.0G
root@sony:~# free -b
total used free shared buff/cache available
Mem: 8270512128 2095005696 4448485376 496779264 1727021056 4701388800
Swap: 8589930496 0 8589930496
root@sony:~#
```
Mathieu Marquer (slasher-fun) wrote : | #54 |
Also affects linux-hwe-edge per #1685833
Changed in linux-hwe-edge (Ubuntu): | |
status: | New → In Progress |
Changed in linux-hwe-edge (Ubuntu Zesty): | |
status: | New → In Progress |
Joseph Salisbury (jsalisbury) wrote : | #55 |
I built a Yakkety test kernel with a pick of commit d75450ff40df019
http://
Can those affected by this bug test this kernel?
Thanks in advance!
Seth Forshee (sforshee) wrote : | #56 |
Fabian: I've had my eye on ace71a19cec5 too, though I haven't seen the stack trace from that commit in any of the reports. However I'm very suspicious that "mm: introduce page_vma_
I really just wish we had a very reliable means to reproduce the bug. I've been trying to find a more reliable way to reproduce, no luck so far.
pauljohn32 (pauljohn) wrote : | #57 |
- kernel log bridging time before and after freeze Edit (538.6 KiB, text/html)
I have this as well. For me, this is always correlated with having Thunderbird or Firefox open.
Sometimes, I also see messages like this
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s!
Can you say if these are superficial or not?
In my kernel log, the freeze happened Apr 22 13:41:51 and I re-started on Apr 23 14:22:38.
pauljohn32 (pauljohn) wrote : | #58 |
To @jsalisbury.
Ubuntu updates just uploaded 4.10.0.20.22. Can you guess if that has fixes similar to ones you offer in http://
Chris Hermansen (c-hermansen) wrote : | #59 |
@Joseph Salisbury;
Just getting ready to try out your kernel test. During the dpkg -i there were some messages I did not care for, for instance:
dpkg: warning: downgrading linux-headers-
and
Not updating initrd symbolic links since we are being updated/reinstalled
(4.10.0-20.22 was configured last, according to dpkg)
Among others. In any case, I'm proceeding with the testing now...
Dennis Sheil (dennis-sheil) wrote : | #60 |
I was hitting the bug with "4.10.0-19-generic #21-Ubuntu". With a standard apt-get update and upgrade (no special kernel install) I am now on "4.10.0-20-generic #22-Ubuntu".
Got hit with the same bug on this new kernel. So the most recent general kernel update did not fix anything for me. Incidentally, like many people here, firefox usage probably helped trigger the bug.
[21100.999019] ------------[ cut here ]------------
[21100.999090] kernel BUG at /build/
[21100.999193] invalid opcode: 0000 [#1] SMP
[...]
[21101.000376] CPU: 0 PID: 9914 Comm: firefox Not tainted 4.10.0-20-generic #22-Ubuntu
Nazar Mokrynskyi (nazar-pc) wrote : | #61 |
As an additional information: this issue is primarily triggered by Firefox when running GPU-related workloads, in my case either video playback or live SVG charts on stock exchange. When those are not used issue either doesn't happen at all or very rarely, not even every day. Video playback and SVG charts together seem to greatly improve probability of triggering this issue.
Henning Kulander (hennikul) wrote : | #62 |
To @pauljohn.
I've been running the 4.10.0-20-generic #22~lp1674838 kernel you linked to in post #58 for 6 hours at work today. No crash so far.
Chris Hermansen (c-hermansen) wrote : | #63 |
@Joseph Salisbury,
I've had the 4.10.0-
Colin Ian King (colin-king) wrote : | #64 |
So, I think the issue occurs because of the pte_lockptr lock being used on a PMD and is incontention with the lock on the same PMD. There are several possible points where this can happen, for example, pages being migrated on NUMA systems (unlikely in most of these bug reports) or even mremap() being used remap a mapped region to a new location. It may be because a page fault occurs on a page that is being migrated or being remapped while it is being accessed and it's swapped out; the latter case may introduce a lot of latency if there are lots of pending I/Os during the swap.
Christian Nassau (nassau) wrote : | #65 |
Fighter19 (littlefighter1996) wrote : | #66 |
- deskcrash.log Edit (85.5 KiB, text/html)
I've also just now experience this error when starting a video in Firefox
(right after the ad started to display, the whole desktop froze, only the mouse could be moved. No ALT+F1 combo etc).
However, I could log in via ssh.
The hard drive LED stood on for a good while after the freeze occurred.
The error is very inconsistent.
Strntydog (strntydog) wrote : | #67 |
@Joseph Salisbury;
I have been testing your kernel all night and not a single problem has occurred. Before this, I couldn't run for two hours without a lock up. So far my uptime on this kernel is 15 hours 30 minutes. With a problem like this its difficult to say categorically "its fixed" but it certainly feels that way.
I notice Kernel 4.10.0.20.22 is available for installation from the repos now, I assume this fix isn't in that version?
cmeerw (cmeerw) wrote : | #68 |
4.10.0-20-generic #22~lp1674838 seems to work fine for me as well so far.
pauljohn32 (pauljohn) wrote : | #69 |
To @jsalisbury
So far so good! 28 hours with http://
Joseph Salisbury (jsalisbury) wrote : | #70 |
Commit d75450ff40df019
It sounds like this commit fixes the issue. If possible please test with that kernel a little longer to confirm it resolves the bug. If it does, I'll submit an SRU request to include that commit in all affected releases.
Daniel (enoch85) wrote : | #71 |
daniel@XPS-13:~$ uname -r
4.10.0-20-generic
My computer just froze with this kernel. This issue is _not_ fixed in this kernel.
As you can see I run a Dell XPS-13 with the Intel network card if that information helps..? Like others say it freezes randomly or on heavy load for a longer period of time. I don't use Firefox , but I have always my mail open which is Thunderbird.
Daniel (enoch85) wrote : | #72 |
Joseph Salisbury (jsalisbury) wrote : | #73 |
@Daniel, can you try testing the kernel posted in comment #55? The uname output should have the bug number in it:
4.10.0-20-generic #22~lp1674838
Mitchell Tasman (tasman) wrote : | #74 |
- dmesg output showing BUG with Joseph's test kernel Edit (5.3 KiB, text/plain)
Joseph,
Hi. I have been running with your test kernel:
$ uname -a
Linux titanic 4.10.0-20-generic #22~lp1674838 SMP Mon Apr 24 18:50:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Unfortunately, it appears that this kernel is still subject to the BUG. Please see the attached dmesg snippet.
Mitchell Tasman (tasman) wrote : | #75 |
@Joseph,
Hi again. FYI, the bug never triggered when I tried your suggestion from #24 to test the following early Zesty kernel:
https:/
But as noted in my previous comment, the BUG did alas trigger in my environment while running 4.10.0-20-generic #22~lp1674838.
pauljohn32 (pauljohn) wrote : | #76 |
Bad news. Just had the kernel crash while using #22~lp1674838
I am attaching a kern.log file that shows this morning I woke from suspend, suspended again, work up again, and then had a freeze. Very surprising to me is that while the machine was locked to outside (cursor moved, but no key board response, no response from ssh to log in), it appears log was still accumulating feedback.
The hard reset happened around 12PM
Joseph Salisbury (jsalisbury) wrote : | #77 |
I will attempt to reproduce the bug. If I can, I'll bisect down to the commit that introduced this regression.
Christian Sarrasin (sxc731) wrote : | #78 |
BTW for those who encounter this issue (as I've just had the pleasure today), it might be useful to reboot your box using the "magic SysRq" sequence since it's supposed to be more gentle than the power key: https:/
In order to enable this feature, I have this in my /etc/rc.local:
echo 1 > /proc/sys/
Oxedions (oxedions) wrote : | #79 |
Hello,
I encounter the bug also. It appends nearly once a day.
Full trace is at: https:/
I tested a configuration without and with a swap, it occurs in both cases.
Also, I nearly always had the bug when using Firefox (but also append when launching some other memory intensive task). I often reach full memory with VMs, but it just kill a VM, never crash.
If I can help you in any way please ask, this bug force me to use screens everywhere and I want my scrolling back.
Ox
kiney (jannik-winkel) wrote : | #80 |
>If I can help you in any way please ask, this bug force me to use screens everywhere and I want my scrolling back.
as a workaround you can just run the mainline kernel.
I'm running 4.11.0rc7 mainline and my uptime is 9 days now. With the ubuntu kernel i had crashes every few hours.
Oxedions (oxedions) wrote : | #81 |
@kiney
Thanks for the tip. I installed 4.11.0rc8, will try this one.
I will keep you informed if I encounter the crash again.
Ox
Strntydog (strntydog) wrote : | #82 |
@Joseph Salisbury;
Touchwood, using your test kernel, I have been running for 2 days, 20 hours without a problem. (havent shutdown once in that time) Been using firefox and thunderbird the whole time. The stock kernels wouldn't run for me for more than an hour or two. I see other people still get the fault, but it would appear that your kernel partially fixes it, at least. Perhaps there are multiple paths that trigger it.
Oxedions (oxedions) wrote : | #83 |
I confirm you it works with this kernel. I went into terrible situations for system, but it survived. However, what I find strange is that I don't have swap on the disk, and still when I reach maximum memory, system write A LOT on the disk while lagging.
Edwin (edwin-v) wrote : | #84 |
Same here. Interesting is that I can run games for hours at high cpu/gpu/memory load without problems, yet I can sometimes lock firefox in a couple of minutes.
I had a quick look at the commit and it fixed a problem in a file that was not introduced until 4.11rc1. Looks like the kernel team has been a little too eager to pull in new patches.
I'll test the updated kernel and see if it helps.
Dennis Sheil (dennis-sheil) wrote : | #85 |
So, I have been getting hit with this every day or so on my rather old HP Pavilion desktop. I thought I might be getting hit with this problem because the desktop was a few years old.
But now I just got hit with it on a new Dell Inspiron laptop which I bought this year. Same error in my kern.log - "kernel BUG at /build/
Both machines currently running the most up to date kernel, 4.10.0-20-generic #22-Ubuntu.
Christian Nassau (nassau) wrote : | #86 |
- syslog.bug2 Edit (52.3 KiB, text/html)
I also had a crash with the #22~lp1674838 kernel. This happend after 2-3 days, over night when the machine was supposedly mainly idle.
Joseph Salisbury (jsalisbury) wrote : | #87 |
It seems I can reproduce this bug now. I'm in the process of "Reverse" bisecting now, which will identify the commit(s) in mainline that fix this and are needed in Zesty.
Joseph Salisbury (jsalisbury) wrote : | #88 |
Can folks affected by this bug test the 4.10.0-21 kernel? It can be downloaded from:
Chris Hermansen (c-hermansen) wrote : | #89 |
@Joseph Salisbury, I'm running the 4.10.0-21 kernel now. Let's see what happens.
hackel (hackel) wrote : | #90 |
FYI, I switched to the mainline build of 4.10.11 and did *not* experience this issue. Today I tried to switch back to linux-image-
Running the mainline kernel is borking up my LXCs and snaps. :(
David Bierce (cppe-david) wrote : | #91 |
Joseph Salisbury (jsalisbury) wrote : | #92 |
@David Bierce, can you give the 4.10.13 kernel a test? It is available from:
David Bierce (cppe-david) wrote : | #93 |
Looks like those builds are failing.
Chris Hermansen (c-hermansen) wrote : | #94 |
@Joseph Salisbury, the 4.10.0-21 kernel crapped out on me but with a different error:
May 1 18:42:25 vancouver kernel: [28120.190864] BUG: unable to handle kernel NULL pointer dereference at 0000000000000021
May 1 18:42:25 vancouver kernel: [28120.190895] IP: dma_fence_
May 1 18:42:25 vancouver kernel: [28120.190901] PGD 0
May 1 18:42:25 vancouver kernel: [28120.190902]
May 1 18:42:25 vancouver kernel: [28120.190909] Oops: 0000 [#1] SMP
etc.
Did you want the rest of the bug info from my syslog?
Joseph Salisbury (jsalisbury) wrote : | #95 |
@David, maybe test 4.10.12 while I review that build failure:
http://
Others have reported this bug is fixed in mainline, so I was just curious if the fix was also cc'd to upstream stable.
David Bierce (cppe-david) wrote : | #96 |
Will try the mainline kernel 4.10.12 With the load failure usually <45 minutes. Will let you know. Thanks!
Mitchell Tasman (tasman) wrote : | #97 |
@Joseph Salisbury,
Hi.
It looks as if the Ubuntu kernel source has diverged from stable in a significant way. In particular,
as has already been noted, on 3/10/2017, Canonical cherry-picked several patches from 4.11-pre, apparently relating to:
http://
Somewhere in there, I suspect, is the underlying cause of the present BUG.
You already tried overlaying an essential fix-up, d75450ff40df019
Looking at mainline, I see a rather large number of memory memory management-related patches from Kirill A. Shutemov and others that follow ace71a19cec5eb4
The reason for this note is to observe that the absence of the present BUG in 4.10.x stable may well be due to the absence of the Canonical backported patches, rather than due to some additive fix.
Reverting the http://
Joseph Salisbury (jsalisbury) wrote : | #98 |
@Mitchell Tasman, Thanks for the feedback. I think we now know for sure that this bug does not happen with the upstream 4.10 or 4.11 kernels. Any commits that are in upstream 4.10 are also in the Ubuntu Zesty kernel. The Ubuntu 4.10.0-21 kernel I requested in comment #88 had all the upstream 4.10 commits in it, up to 4.10.11. The Ubuntu 4.10.0-21 kernel was confirmed to have this bug. However, folks have tested several of the upstream 4.10 kernels and never hit the bug. This is leading me to believe the bug is due to an Ubuntu specific SAUCE patch or patches, so I think your correct.
It would be very helpful if we could identify the last good Ubuntu kernel. However, there has been varying test results.
Comment #30 had the following results:
4.10.0-15: affected
4.10.0-14: issue not experienced in over a week
However, comment #47 disagreed with this.
I think it would be good to have 4.10.0-14 tested again by as many as possible, to see if that is in fact a version that does not have the bug. If it is good, it will give us a good starting point for a bisect. It can be downloaded from:
https:/
Loïc Gomez (opensource-loic) wrote : | #99 |
Hi, I'm having the same randome freezes using kernel 4.10.0-20.22 (trace follows).
I'm running Linux without swap space, if that's relevant information.
It mostly happens when I'm listening to music / YT using chromium or amarok while doing something else. The computer starts heating, venting, and being slow but still windows can be changed for a very short time. Then it's gone and I have to either power down or use AltGr SysRq commands.
If I can help in any way please ask.
Loïc
[182948.603342] kernel BUG at /build/
[182948.603366] invalid opcode: 0000 [#1] SMP
[182948.603380] Modules linked in: rfcomm veth ccm xt_nat xfrm_user aufs ipt_MASQUERADE nf_nat_
[182948.603570] vboxdrv(OE) deflate twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_
[182948.603761] coretemp kvm_intel snd_soc_rl6231 snd_soc_core snd_compress ac97_bus kvm iwlmvm snd_pcm_dmaengine irqbypass mac80211 intel_cstate snd_seq_midi snd_seq_midi_event intel_rapl_perf snd_hda_codec_hdmi snd_hda_
[182948.603964] parport_pc ppdev lp parport ip_tables x_tables autofs4 algif_skcipher af_alg dm_crypt hid_generic usb...
Patrik Lundquist (patrik-lundquist) wrote : | #100 |
I've had 4.10.0-14 crash before.
[1217206.617030] ------------[ cut here ]------------
[1217206.617055] kernel BUG at /build/
[1217206.617077] invalid opcode: 0000 [#1] SMP
[1217206.617089] Modules linked in: macvtap macvlan ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs cpuid xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_
[1217206.617273] tpm_infineon mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 algif_skcipher af_alg dm_crypt raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log btrfs xor raid6_pq hid_generic usbhid hid uas usb_storage i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc video i2c_algo_bit drm_kms_helper aesni_intel syscopyarea aes_x86_64 sysfillrect crypto_simd sysimgblt glue_helper fb_sys_fops cryptd e1000e drm ahci libahci ptp pps_core wmi fjes
[1217206.617408] CPU: 4 PID: 19974 Comm: chrome Not tainted 4.10.0-14-generic #16-Ubuntu
[1217206.617428] Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.83 10/21/2016
[1217206.617453] task: ffff8a41f99b4380 task.stack: ffffb76a0b444000
[1217206.617473] RIP: 0010:__
[1217206.617489] RSP: 0000:ffffb76a0b
[1217206.617504] RAX: 0017ffffc0048078 RBX: fffff73853184d70 RCX: fffff73853184d70
[1217206.617523] RDX: 0000000000000001 RSI: ffff8a4046135480 RDI: fffff73846582400
[1217206.617541] RBP: ffffb76a0b447d80 R08: ffff8a426e9ba6c0 R09: ffff8a426e9ba6c0
[1217206.617561] R10: 0000000000000000 R11: 000000007fffffe0 R12: fffff73846582400
[1217206.617581] R13: 3e00000000196090 R14: ffffb76a0b447e30 R15: ffff8a3edf9774b0
[1217206.617601] FS: 00007f750d77748
[1217206.617623] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1217206.617638] CR2: 000032988cc906c0 CR3: 000000069d1f8000 CR4: 00000000001406e0
[1217206.617657] Call Trace:
[1217206.617669] migration_
[1217206.617684] do_swap_
[1217206.617697] handle_
[1217206.617712] __do_page_
[1217206.617726] do_page_
[1217206.617740] page_fault+
[1217206.617751] RIP: 0033:0x55dc93afa9df
[1217206.617763] RSP: 002b:00007ffddb
[1217206.617779] RAX: ffffcd65dddb65a0 RBX: 00000002aee49d7f RCX: 000000032988cc90
[1217206.617798] RDX: 0000000000000c90 RSI: 000032988cc906c0...
Joseph Salisbury (jsalisbury) wrote : | #101 |
Thanks, Patrik. We should test older kernels then. -8 was requested in the past, but it would be good to confirm those results:
https:/
Mitchell Tasman (tasman) wrote : | #102 |
@Patrick Salisbury,
Hi. I have yet to experience the BUG with 4.10.0-8:
$ uname -a
Linux titanic 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ uptime
17:54:47 up 6 days, 2:57, 1 user, load average: 0.24, 0.45, 0.61
I had run this kernel for some days earlier as well, but rebooted to try one of your test kernels.
Regards,
Mitch
Joseph Salisbury (jsalisbury) wrote : | #103 |
Thanks for the update. It might be best to next start testing 4.10.0-12 then:
https:/
Mitchell Tasman (tasman) wrote : | #104 |
@Patrick Salisbury,
As a P.S., If you are able to confirm that Ubuntu 4.10.0-14 is the first version affected, that would be consistent with a hypothesis that the patch series associated with: http://
* POWER9: Additional power9 patches (LP: #1671613)
- mm/autonuma: don't use set_pte_at when updating protnone ptes
- mm/autonuma: let architecture override how the write bit should be stashed in a protnone pte.
- powerpc/
- mm/gup: check for protnone only if it is a PTE entry
- mm/thp/autonuma: use TNF flag instead of vm fault
- SAUCE: powerpc/mm: handle protnone ptes on fork
- SAUCE: power/mm: update pte_write and pte_wrprotect to handle savedwrite
- mm/ksm: improve deduplication of zero pages with colouring
- mm: introduce page_vma_
- mm, ksm: convert write_protect_
- mm/ksm: handle protnone saved writes when making page write protect
Joseph Salisbury (jsalisbury) wrote : | #105 |
For the sake of time, if 4.4.0-12 is good, here are the -13 and -14 links which are the suspected last good and first bad kernels:
4.4.0-13:
https:/
and
4.4.0-14:
https:/
If we can confirm these are the last good and first bad kernels, I'll start a bisect to narrow down the exact commit.
Lorrin Nelson (lhn-5) wrote : | #106 |
I can also confirm the Ubuntu build of 4.10.0-8 does not have the bug.
$ uname -a
Linux gooseberry 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ uptime
21:14:04 up 6 days, 2 min, 1 user, load average: 0.79, 0.62, 0.43
I was crashing daily on the Ubuntu builds of 4.10.0-19 and 4.10.0-20
I will try 4.4.0-13.
pauljohn32 (pauljohn) wrote : | #107 |
OK, I will install 4.10.0-13. Are these the correct ones:
linux-headers-
linux-headers-
linux-image-
linux-image-
linux-tools-
For what it is worth, I've not seen this happen in 2 days using
Linux delllap-16 4.10.0-20-generic #22-Ubuntu SMP Thu Apr 20 09:22:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
It is not nearly so frequent as it was.
Seth Forshee (sforshee) wrote : | #108 |
I'm now able to produce this pretty reliably with 4.10.0-20.22. My testing shows that the "POWER9: Additional power9 patches" patches are responsible, two of them in particular:
- mm: introduce page_vma_
- mm, ksm: convert write_protect_
These patches don't appear to be included for any functionality they provide, but rather to make "mm/ksm: handle protnone saved writes when making page write protect" a clean cherry pick instead of a backport. But the backport isn't that difficult, so as far as I can tell we can do away with the other two patches.
I've built 4.10.0-20.22 with just those changes - reverting all three of the above patches then backporting the one which is actually needed - and I'm no longer able to reproduce this bug. Everyone, please give it a try and let me know whether or not you still see problems.
Colin Ian King (colin-king) wrote : | #109 |
Thanks Seth, this successfully fixes a reproducer that was able to trigger this bug for me.
kiney (jannik-winkel) wrote : | #110 |
I'm testing 4.10.0-20-generic #22+lp1674838v2
Jordao (carlosjordao) wrote : | #111 |
I've been experiencing same kind of freeze / lookup with kernel 4.10.0, from packages
linux-image-
linux-image-
linux-image-
I use Ubuntu at home and at my work and I experienced in both after upgrading to 17.04.
I kept only 4.8 version installed until I feel confident there are any stable versions.
Some times it freezes very quickly, other times it becomes very unstable and starts to freeze one application after another. In the later moment I could perceive something related to firefox / flash becoming zombie unable to kill, one cpu core get locked and with 100% use, then freezes. SysRq works for reboot.
If there is any way to collect data for debugging and diagnosis, please tell me.
David Bierce (cppe-david) wrote : | #112 |
Sorry, was out for a few days.
Just catching up, I'm running the kernel from http://
The box I'm testing will has been hitting the panic in less than hour from its high workload since updating to 17.04 will update yes or no.
David Bierce (cppe-david) wrote : | #113 |
After running under the usual high load for 4 hours the previously caused a hang after 1 hour, the issue hasn't popped up yet using 4.10.0-20-generic #22+lp1674838v2
kiney (jannik-winkel) wrote : | #114 |
No crash after more than 23 hours uptime with 4.10.0-20-generic #22+lp1674838v2
With the normal ubuntu 4.10 the system crashes every few hours. So I can confirm the bug is probably fixed in the kernel from ~sforshee
David Bierce (cppe-david) wrote : | #115 |
4.10.0-20-generic #22+lp1674838v2
fry:~$ uptime
11:27:04 up 16:20, 2 users, load average: 13.48, 14.59, 16.62
No crash, previous crashes would appear within an hour with lighter load and memory pressure. Seth's thesis on the back port seems to be correct.
Mathieu Pellerin (nirvn-asia) wrote : | #116 |
I've also been suffering from this issue. The kernel here (http://
pauljohn32 (pauljohn) wrote : | #117 |
Good news. I have no crashes in 2 days with http://
Lorrin Nelson (lhn-5) wrote : | #118 |
Sounds like this have been narrowed down to changes more recent than this, but I have tried 4.10.0-13. So far it is stable.
$ uname -a
Linux gooseberry 4.10.0-13-generic #15-Ubuntu SMP Thu Mar 9 20:28:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ uptime
22:59:30 up 3 days, 1:30, 1 user, load average: 0.80, 0.77, 0.64
Tim Ritberg (xpert-reactos) wrote : | #119 |
In opposit to Kernel 4.8x this 4.10 is very unstable.
I have this problem too. I am using 4.10.0-20-generic.
litjens (jhcl) wrote : | #120 |
no more problems since i installed version 4.10.0-20-generic (sforshee@gloin) #22+lp1674838v2
throwaway45224 (throwaway45224) wrote : | #121 |
Related bugs:
https:/
https:/
https:/
https:/
https:/
I will mark them as duplicates.
Kelvin Ma (taylorswift) wrote : | #122 |
This happened to me just now; computer randomly froze and I had to do a hard reboot. Later found out what happened by digging through syslog.
throwaway45224 (throwaway45224) wrote : | #123 |
Many people experience `NMI watchdog: BUG: soft lockup - CPU#$XXX stuck for $YYYs!`:
https:/
https:/
https:/
https:/
https:/
Are those duplicates of this bug?
Allan Mertner (amertner) wrote : | #124 |
Yes, I think the conclusion is that those are secondary effects of the bug. Fingers crossed that the actual fix has been found and will appear in an official release soon...
Andrey Arapov (andrey-arapov) wrote : | #125 |
- linux-4.10.0-20-swapops-slabtop-logs.txt Edit (56.6 KiB, text/plain)
Occurred again to me with Linux 4.10.0-20-generic #22-Ubuntu.
I attached some logs.
Edwin (edwin-v) wrote : | #126 |
I have been running "4.10.0-20-generic #22~lp1674838" since 28 April and today it finally gave me the swapops error again. This illustrates the need for using the reproducible test cases.
Emilio (emilio-moretti) wrote : | #127 |
@Joseph Salisbury Your changes fixed the problem:
http://
I was not able to use the computer for more than 10 minutes before that, and it's been working OK for a few hours now. I can't wait for the official release.
Thank you
throwaway45224 (throwaway45224) wrote : | #128 |
Emilio, Edwin mentioned above that lp1674838 is still susceptible to this bug.
Emilio (emilio-moretti) wrote : | #129 |
Oh, it's sad to hear that. At least I'm not getting them so often. Thanks for letting me know.
Jan Claeys (janc) wrote : | #130 |
edwin-v was testing an older test kernel from jsalisbury, not the newer one from sforshee
Mitchell Tasman (tasman) wrote : | #131 |
I'm seeing stable behavior with @Seth Forshee's kernel:
$ uname -a
Linux titanic 4.10.0-20-generic #22+lp1674838v2
$ uptime
14:41:08 up 4 days, 2 min, 1 user, load average: 0.12, 0.25, 0.13
What is the next step in getting Seth's patch series into the official Ubuntu kernels?
Fabian Grünbichler (f-gruenbichler) wrote : | #132 |
@tasman: it's already slated for inclusion into one of the next kernel packages: https:/
Vidar Braut Haarr (vhaarr+launchpad) wrote : | #133 |
Will it be included in the next artful kernel, or only zesty? I ask because the email subject says "[PATCH 0/4][Zesty SRU]".
And when will it be, roughly? 2 weeks? 3 months? Tomorrow?
Seth Forshee (sforshee) wrote : | #134 |
On Wed, May 10, 2017 at 02:19:26PM -0000, Vidar Braut Haarr wrote:
> Will it be included in the next artful kernel, or only zesty? I ask
> because the email subject says "[PATCH 0/4][Zesty SRU]".
>
> And when will it be, roughly? 2 weeks? 3 months? Tomorrow?
Currently artful is using the same kernel as zesty. As per previous
testing on this bug, kernels after 4.10 should not be affected.
Given the current SRU schedule (and barring any unforeseen
circumstances), the kernel with this fix should release on June 5.
Mathieu Pellerin (nirvn-asia) wrote : | #135 |
Hmm, a June 5 release date for this fix seems to be wait too late for the severity of this system freeze bug. A large number of people who run Ubuntu now (either long-time users or newcomers testing the desktop platform) has his/her computer crash every hour or so. On that basis, shouldn't Canonical speed up the fix delivery?
Nazar Mokrynskyi (nazar-pc) wrote : | #136 |
I agree that this should be released much faster. For instance, one bug I found in btrfs-progs that was fixed in less that a week after 2 weeks from reporting was fixed in Ubuntu, while bug only affected small subset of btrfs users with additional features and didn't actually corrupt or hang anything. Waiting almost 3 weeks to release something that causes many systems to hang randomly is way too long. Consider releasing this sooner, please.
flux242 (flux242) wrote : | #137 |
ah, c'mon, how severe could this bug be? You, loosing hours of work because your system freezes? Who cares? They have more important things to care about - preparing for ipo and stuff. And don't forget to buy canonical stocks as they out
canonical you really should mark 17.04 as testing and not recommended for install
Christian Sarrasin (sxc731) wrote : | #138 |
Not a comment on the slow patching schedule but while we're waiting for a proper release, those who prefer to use a released kernel might want to switch to 4.10.0-13-generic. Several people here (myself included) haven't had a crash for days using it and there is strong suspicion (see #104) that 4.10.0-14 is the one that introduced the bug.
apt install linux-image-
apt install linux-headers-
apt install linux-image-
To change your default grub boot option, see https:/
Not sure what regressions using 4.10.0-13 would entailed compared to later kernels?
Seth Forshee (sforshee) wrote : | #139 |
> Hmm, a June 5 release date for this fix seems to be wait too late
> for the severity of this system freeze bug.
This is our normal SRU cycle. Out-of-cycle updates are for the most part
reserved for critical security issues.
> Not sure what regressions using 4.10.0-13 would entailed compared to
> later kernels?
Probably better to use the kernel I posted, as this is more up-to-date
and thus has more fixes (including security fixes). A kernel will also
be available in -proposed much sooner than that (sometime next week in
all likelihood), and this bug will be updated when that is available, so
I'd suggest updating to that when it is available.
Kwang Moo Yi (kwang-m-yi) wrote : | #140 |
Hope this fix lands soon, since without it, the 4.10 kernel is basically unusable. Even for 16.04, this bug makes the hwe-edge series pretty much unusable.
Sean Tobin (seantobin) wrote : | #141 |
If it helps at all in the calculus of determining when to release this update, we've got a production RethinkDB cluster that was affected by this bug under Zesty server. Installing the http://
Mitchell Tasman (tasman) wrote : | #142 |
@Seth Forshee,
Thanks again for your patch series and test kernel, which has resulted in my system running stably for over a week now.
Although your patch series was ACK'd on the Ubuntu kernel mailing list, I thought it worth mentioning that it doesn't yet appear to have been applied to master-next of http://
MURAT ATES (digasi) wrote : | #143 |
murat@Murat-
4.10.0-20-generic
murat@Murat-
Linux Murat-Laptop 4.10.0-20-generic #22+lp1674838v2
I just booted into the kernel 4.10.0-20 by Seth Forshee and encountered this bug within a few hours.
This happened at one point I clicked on "Share This Page" icon on firefox while viewing some page on nike.com and I clicked on more options to load page at https:/
Are we back to the drawing board?
throwaway45224 (throwaway45224) wrote : | #144 |
Murat, are you sure it's the same bug? I experienced a random freeze on
4.8.0-51-generic, but there was nothing in syslog and symptoms were
quite different. What's in your syslog?
MURAT ATES (digasi) wrote : | #145 |
You are right. This is NOT the same bug but stunningly happens with this kernel while the "share + more actions" on firefox worked fine with the ubuntu kernel.
Here is the relevant entry in the syslog:
May 11 16:40:30 Murat-Laptop dbus-daemon[1834]: Activating service name='org.
May 11 16:40:30 Murat-Laptop dbus-daemon[1834]: Successfully activated service 'org.gnome.GConf'
May 11 16:40:32 Murat-Laptop unity-panel-
May 11 16:40:32 Murat-Laptop unity-panel-
May 11 16:40:33 Murat-Laptop compiz[2359]: 1494535233840#
04,"errno"
May 11 16:40:34 Murat-Laptop systemd[1]: Starting Stop ureadahead data collection...
May 11 16:40:34 Murat-Laptop systemd[1]: Started Stop ureadahead data collection.
May 11 16:40:56 Murat-Laptop compiz[2359]: Vector smash protection is enabled.
May 11 16:48:54 Murat-Laptop unity-panel-
There is 8 minutes of silence after the crash between 16:40 and 16:48, where I instinctively pressed alt+sysrqE to failure of reboot!
I CAN reproduce this particular error, which clearly is NOT the bug we are dealing with on this thread, following the same steps. Actually you can try this by clicking on "Share this page" icon on firefox and then the + icon to install more social actions.
You CAN kill the stalled Firefox processs from a terminal.
throwaway45224 (throwaway45224) wrote : | #146 |
> I CAN reproduce this particular error, which clearly is NOT the bug we
> are dealing with on this thread, following the same steps. Actually you
> can try this by clicking on "Share this page" icon on firefox and then
> the + icon to install more social actions.
If you can reproduce the error, file a separate bug report please.
David Ordenes D. (radioboy-2) wrote : | #147 |
This happens to me with 4.10.0-20 in Zesty KDE. It happens to me with a fresh install and only when using a fresh firefox profile, with and without flash enabled (and having a lot of tabs open); it leaves a zombie process after manually killing it, but then the system locks in about a minute.
If I ask too much of chrome it just crashes on its own and the system keeps working fine.
I set up an 8 GB partition to be mounted as /swap when installing, so I'm not sure how it works now that swap is supposed to be a file.
Jan Claeys (janc) wrote : | #148 |
One issue with Seth Forshee's kernel is that it doesn't work with secure boot, so people might have to disable that temporarily) to be able to boot...
Seth Forshee (sforshee) wrote : | #149 |
> One issue with Seth Forshee's kernel is that it doesn't work with secure
> boot, so people might have to disable that temporarily) to be able to
> boot...
Yes, however the kernel which should be available in -proposed sometime
next week will have a signed counterpart.
Also while I'm commenting I might as well let you know that the patches
are now commited, for zesty. Not sure why the status hasn't been updated
but I'll do so now.
Changed in linux (Ubuntu Zesty): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in linux-hwe-edge (Ubuntu Zesty): | |
status: | In Progress → Fix Committed |
Adrian (adrian-b) wrote : | #150 |
Just to add another confirmation regarding Seth Forshee's kernel, I've be up for 11 days now with it and was crashing every 1 or 2 days (since upgrading to Zesty).
Uptime
16:39:28 up 11 days, 6:54, 2 users, load average: 0.99, 0.91, 0.99
uname -r
4.10.0-20-generic
uname -a
Linux adrian-AMD 4.10.0-20-generic #22+lp1674838v2
Alex Garel (alex-garel) wrote : | #151 |
Same as Adrian, here, I've been testing Seth Forshee's kernel for 4+ days experimenting no more crash (versus 2/3 crash a day).
$ uname -a
Linux tignasse 4.10.0-20-generic #22+lp1674838v2
Jonas Slivka (jonas-slivka) wrote : | #152 |
- kern.log (Linux 4.10.0-20 (Forshee's kernel)) Edit (6.6 KiB, text/plain)
I'm still experiencing freezes with Seth Forshee's kernel (5-6 times a day on relatively heavy load)...
➜ ~ uname -a
Linux dell 4.10.0-20-generic #22+lp1674838v2
Attaching kern.log with stack trace.
3axis (3axis) wrote : | #154 |
just hung again, only reisub worked.
On Wed, 17 May 2017, 13:41 Jonas Slivka, <email address hidden> wrote:
> I'm still experiencing freezes with Seth Forshee's kernel (5-6 times a
> day on relatively heavy load)...
>
> ➜ ~ uname -a
> Linux dell 4.10.0-20-generic #22+lp1674838v2
> 13:41:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> Attaching kern.log with stack trace.
>
> ** Attachment added: "kern.log (Linux 4.10.0-20 (Forshee's kernel))"
>
> https:/
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1683889).
> https:/
>
> Title:
> kernel BUG at /build/linux-
> 7LGLH_/
>
> Status in linux package in Ubuntu:
> Fix Committed
> Status in linux-hwe-edge package in Ubuntu:
> In Progress
> Status in linux source package in Zesty:
> Fix Committed
> Status in linux-hwe-edge source package in Zesty:
> Fix Committed
>
> Bug description:
> Randomly, khugepaged process will take 100% CPU, and I can only
> restart the computer to recover it.
>
> Relevant dmesg attached (dmesg_crash.txt).
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.04
> Package: linux-image-
> ProcVersionSign
> Uname: Linux 4.10.0-14-generic x86_64
> ApportVersion: 2.20.4-0ubuntu2
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: mathieu 2221 F.... pulseaudio
> /dev/snd/pcmC1D0p: mathieu 2221 F...m pulseaudio
> /dev/snd/controlC1: mathieu 2221 F.... pulseaudio
> CurrentDesktop: Unity:Unity7
> Date: Tue Mar 21 23:03:23 2017
> HibernationDevice: RESUME=
> InstallationDate: Installed on 2016-01-31 (415 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64
> (20160131)
> MachineType: LENOVO 20344
> ProcFB: 0 inteldrmfb
> ProcKernelCmdLine: BOOT_IMAGE=
> root=UUID=
> vt.handoff=7
> RelatedPackageV
> linux-restricte
> linux-backports
> linux-firmware 1.164
> SourcePackage: linux
> UpgradeStatus: Upgraded to zesty on 2017-03-02 (19 days ago)
> dmi.bios.date: 10/16/2014
> dmi.bios.vendor: LENOVO
> dmi.bios.version: 96CN29WW(V1.15)
> dmi.board.
> dmi.board.name: INVALID
> dmi.board.vendor: LENOVO
> dmi.board.version: 31900058WIN
> dmi.chassis.
> dmi.chassis.type: 10
> dmi.chassis.vendor: LENOVO
> dmi.chassis.
> dmi.modalias:
> dmi:bvnLENOVO:
> dmi.product.name: 20344
> dmi.product.
> dmi.sys.vendor: LENOVO
>
> ...
Emilio (emilio-moretti) wrote : | #153 |
@jonas-slivka that's not related to this ticket.
You have a different bug:
https:/
tkb608 (tkb608) wrote : | #155 |
Ran into this bug during high load on 4.10.0-21
Followed @sxc731 Advice from...
https:/
Things seem good now.
Thanks for the good work here. Look forward to the fix dropping.
Ehsan Akhgari (ehsan) wrote : | #156 |
- kern.log.bz2 Edit (4.5 MiB, application/octet-stream)
I am also experiencing the hang still with the lp1674838 kernel:
$ cat /proc/version
Linux version 4.10.0-21-generic (root@gomeisa) (gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2) ) #23~lp1674838 SMP Mon May 1 16:13:17 UTC 2017
Please see the attached kern.log, for example around May 17 14:25:47.
Hans van den Bogert (hbogert) wrote : | #157 |
@ehsan, what do you mean? I can't see any error in the kern.log, which corresponds to the ones we would expect in this thread. Not every kernel panic is caused by the issue in this ticket.
Mitchell Tasman (tasman) wrote : | #158 |
@Ehsan,
Hi. You are running the original test kernel for this BUG, which turned out not to resolve the problem.
Please switch to @Seth Forshee's kernel as linked to #108:
http://
That kernel identifies itself as: 4.10.0-20-generic #22+lp1674838v2
Ehsan Akhgari (ehsan) wrote : | #159 |
My apologies, I think I was confused before. I saw another hang with similar symptoms and I think confirmation bias made me assume I'm seeing this bug again without double checking everything carefully. Sorry about that!
Now I verified I'm running the right kernel, I'll report if I see the original hang I first reported in Bug #1687267:
$ cat /proc/version
Linux version 4.10.0-20-generic (sforshee@gloin) (gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2) ) #22+lp1674838v2
Peter Selinger (selinger) wrote : | #160 |
I believe that a kernel that crashes every 1-4 hours is a critical security bug, so an update should be released immediately, rather than some time in June.
I was unable to install linux-image-
I am still experiencing this bug with vmlinuz-
May 18 08:42:05 puffin kernel: [171667.771712] ------------[ cut here ]------------
May 18 08:42:05 puffin kernel: [171667.771735] kernel BUG at /build/
May 18 08:42:05 puffin kernel: [171667.771756] invalid opcode: 0000 [#1] SMP
throwaway45224 (throwaway45224) wrote : | #161 |
> critical [...] bug
Totally agree.
> security bug
It's a critical bug, but not a security issue.
tkb608 (tkb608) wrote : | #162 |
@selinger Yeah, hard to kind old kernels.
https:/
Tim Passingham (tim-8aw3u04umo) wrote : | #163 |
A tale of ordinary folk - just users.
We have 4 systems running 17.04 - 3 xubuntu and 1 ubuntu. 3 are fine. Now one regularly locks up and has to be manually rebooted. The other 3 are fine. I initially reported against #1687267, (now marked as a duplicate of this) including a crash log.
The desktop that crashes is a 5 year old Dell used by my non-IT partner. This situation is quite impossible for her to tolerate. We have never, ever, had a problem like this before. SHe is now suggesting reverting to Windows, having never had such failures with that (nor have I in the last 10 or more years).
Fortunately there was a 16.10 kernel left after upgrading - 4.8.0-51 and by using Grub-customizer I managed to make this the default kernel. Whether it is truly OK with 17.04 I don't know, but so far so good.
Having always told my partner to do updates, I now have to tell her not to, because 4.10.0-21 just landed and changed the boot order.
If ubuntu (etc) is ever to be a normal desktop of choice for normal users, regular crashes of this nature have to be fixed ASAP. This one is now almost 2 months old. I've tripped over similar crash reports not (yet) marked as a duplicate (eg #1686727) and this problem may be even more widespread than people realise.
throwaway45224 (throwaway45224) wrote : | #164 |
Tim Passingham, thanks for telling us your story. Ordinary folk are not
very well represented here, in the bug tracker.
Does anybody know any news websites that might be interested in covering
this issue? I emailed the guy who writes for OMG! Ubuntu!, but he didn't
respond so far. It might be a good idea if other people contacted him
too: http://
better than I did and it may draw the editor's attention. Besides,
creating buzz about the issue increases the chance that it gets noticed.
tkb608 (tkb608) wrote : | #165 |
I'm supportive of the idea that this is a show song bug. But you know, free software, and not a LTS version. So maybe take it down a notch.
pauljohn32 (pauljohn) wrote : | #166 |
One more happy week of success with http://
I understand Tim Passingham's frustration, but can I turn the question a different way? I want to know "why didn't this problem affect all Ubuntu users? Why just us?" A particular motherboard is to blame?
Also, is there any word if this fix will go into Ubuntu updates? I ask because, after the Ubuntu firmware update within the last few days, I'm no longer able to get HDMI devices to work--just black screen of death on the HDMI in Intel video. I fear I'm in for another hard-to-diagnose problem I am sure everybody will say that using the lp1674838 kernel is complicating that. If I use a stock kernel, they might be more able to figure it out.
Tim Passingham (tim-8aw3u04umo) wrote : | #167 |
Thanks for the responses to my comments. I appreciate that this is not the LTS version, and I didn't have to pay to get it.
I have two approaches to updating. Either stay fully up to date on the most recent versions and risk having issues with ever changing versions, or never update at all. I take the view that being really up to date is best, so I keep us moving forward on non-LTS versions and take the risk. If I was asked to pay, say £50 or so, I would.
Other have suggested booting the appropriate version each time I boot. That's a nuisance, and not something my non-IT partner could handle at all (just switch it on and log in - why do I have to do anything else?). I suspect some who spend a lot of time in IT have little idea how people who have not grown up with it regard it (I started in 1970, so still have some feel for it, but am by no means expert in any area).
I assume that the recent release of 4.10.0-21 would override the patched 4.10.0.20. Is that correct? If so it would still cause ordinary folk some problems.
When I go away for a while I'm still going to be forced to tell my partner not to take any updates at all.
I'll see I can contact OMG ubuntu.
Patrik Lundquist (patrik-lundquist) wrote : | #168 |
@Tim
Add/set in /etc/default/grub:
GRUB_DEFAULT=saved
GRUB_SAVEDEFAUL
and run "sudo update-grub" to have GRUB remember the kernel you booted last time.
Thomas M Steenholdt (tmus) wrote : | #169 |
@Tim - What Patrick said... Or prevent the kernel package from being updated until the fix is included:
https:/
Kwang Moo Yi (kwang-m-yi) wrote : | #170 |
Just to add, even 16.04 LTS is affected by this bug, as if you install linux-hwe-edge, you install the same bugged kernel. For me, the next time I wipe my machine, it won't be ubuntu, simply because this type of bug is unacceptable for a daily driver.
Loïc Gomez (opensource-loic) wrote : | #171 |
I'm also grateful for the free service provided by Ubuntu here, although I must object ! The release being LTS or not is irrelevant to this problem as we are obviously in the support lifecycle of the zesty release. The release being non-LTS is not an indicator of instability, or at least it should not.
I understand this is not a security issue, but it's highly affecting user experience for at least 144 people here in this thread. And of course, it's only the tip of the iceberg, most users - and particularly non-tech users who are afaik one of Ubuntu's main targets - don't want the hassle of reporting bugs. They'll eventually change the piece of software causing them trouble.
Also, the culprit of these freezes seem to be a patch Ubuntu team decided to backport. I would assume they'd be swift to fix the issues they've been introducing in a widely used kernel.
If you know how to do so, please hasten the process, for our sakes and Ubuntu's !
Tim Passingham (tim-8aw3u04umo) wrote : | #172 |
Thanks to all for the advice. I'll trying saving the last used kernel using grub.
Is there like to be any problem running a 4.8 version kernel with 17.04? It seems OK so far.
tkb608 (tkb608) wrote : | #173 |
@kwang-m-yi Good point, I had forgotten that new installs of 16.04.2 would automatically get HWE and therefore this bug.
flux242 (flux242) wrote : | #174 |
hm, my computer hanged up even with the kernel 21
Linux chrome 4.10.0-21-generic #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
The symptoms were very similar - firefox in the foreground and computer locked up but there where no usual swapon oops record in the syslog this time.
Vincas Dargis (talkless) wrote : | #175 |
- syslog-cut.txt Edit (20.5 KiB, text/plain)
I have experienced freeze with Linux vinco 4.10.0-21-generic #23~16.04.1-Ubuntu SMP Tue May 2 12:57:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux while browsing with Firefox.
In addition to "invalid opcode: 0000 [#1] SMP", there are:
"NMI watchdog: BUG: soft lockup - CPU#6 stuck for 23s! [Timer:8949]"
At first, Firefox froze. Could not kill it, and when tried to log out for KDE session, everything froze, and I had to reisub.
Attaching syslog-cut.txt.
Strntydog (strntydog) wrote : | #176 |
So, how will we know when this patch drops into a distribution kernel?
Sven Hartrumpf (hartrumpf) wrote : | #177 |
Hi.
The relevant line in the kern.log of the affected server (4.10.0-21-generic) was:
kernel BUG at /build/
I switched to the 4.11 mainline kernel:
Linux 4.11.2-
I hope this is a valid work-around ...
Sven
q8374gf (q8374gf) wrote : | #178 |
Mint Cinnamon 18.1 user here. Just mentioning that so as to make it easier for other people doing a Google search to find this thread, since it was pretty hard for me to find. Same problem as everyone else, swapops.h:129!. For me particularly, khugepaged goes to Uninterruptible Sleep (D) state when writing a bunch of files to usb drive, then a lot of stuff quits working, like Firefox, then a complete lockup soon after. Have to reset computer via power button. Switching kernel away from any 4.10.x available in Mint to 4.8.0-52 seems to fix it.
pauljohn32 (pauljohn) wrote : | #179 |
This should be marked "SOLVED!".
It appears that newcomers are arriving at this ticket to report same old problem, without realizing it has been fixed in a replacement kernel offered by Seth Forshee. The problem is now understood and there is no need to guess about installing alternative kernels from whatever repository. Seth's kernel fixed it. Look up to comment 108:
https:/
I've been running this alternative for weeks and the problem has not reappeared.
Nazar Mokrynskyi (nazar-pc) wrote : | #180 |
This issue is not solved until fixed kernel appears in stable repositories. This is exactly why new people are arriving and will do so for a few more weeks.
Tim Passingham (tim-8aw3u04umo) wrote : | #181 |
And even if the patched kernel is installed by those few users that manage to find this bug report, or one of its many duplicates, it gets replaced by 4.10.0.21 which reinstates the bug. Only installing 4.11 keeps the problem away.
Rocko (rockorequin) wrote : | #182 |
I find it absolutely astonishing that a bug that is easy to trigger, can cause data loss, and requires a hard reboot is treated with a lower priority than security bugs.
Surely Ubuntu 17.04 should be flagged "not suitable for production machines" until this issue is fixed?
Steve (greatape) wrote : | #183 |
Another vote for this needs releasing now!
Before I tracked down the cause and found this bug report I'd spent hours trying to diagnose the reason for my machines instability. I'd re-installed Ubuntu over the previous version, when that didn't work got a new hard disk and did a totally new clean install and was shocked to find the machine still freezing regularly. At this point was almost sure it was a hardware problem, even though numerous memory scans had shown up nothing.
If I hadn't managed to setup Netconsole to catch the incriminating logs and then google this report I'd have bought a whole new machine by now, and been very annoyed when I'd have found the identical problem occurred on that as well.
The whole handling of this problem says to me Ubuntu simply can't be looked upon as anything other than a toy for technical experts who are prepared to get their hands dirty tracking the cause of problems like this, and prepared to put their machine on ice for a few weeks while they wait for a fix to be released.
You have to understand that while the problem is annoying enough in itself for those of us who know what the problem is. For those who don't know why their machines are freezing multiple times per days it's going to be causing huge amounts of grief, wasted time and expense trying to fix and diagnose the problem.
Hans van den Bogert (hbogert) wrote : | #184 |
> tkb608 (tkb608) wrote on 2017-05-19:
> @kwang-m-yi Good point, I had forgotten that new installs of 16.04.2 would automatically get HWE and therefore this bug.
Although that's true, @kwang-m-yi talked about hwe-edge; and the "edge" variant is not installed by default on 16.04.2.
As example, I hit this bug in precisely that scenario; though I fully realized that installing the hwe-edge *manually* might have unforeseen consequences.
Vincas Dargis (talkless) wrote : | #185 |
2017.05.21 22:53, JOSHUA CRUNK rašė:
> Have to reset computer via power button.
You can use REISUB sequence to reboot more safely.
Tim Passingham (tim-8aw3u04umo) wrote : | #186 |
I don't understand that article. It says press Alt+SysReq and another key, and that SysReq is the PrintScreen key.
If I press Alt + PrintScreen it asks to print the screen - I have no chance to enter another key. Can someone clarify this? I'm sure it's obvious.....
Tim Passingham (tim-8aw3u04umo) wrote : | #187 |
Sorry - I now understand that I have to press all 3 keys at the same time.
munbi (gabriele) wrote : | #188 |
@Tim, this is what works for me on a Dell Latitude E6540:
1. Left hand: Press and hold “Fn” key (between Ctrl and the Windows key)
2. Right hand: Press and hold “Alt” + “SysRq” keys (Stamp)
3. Left hand: Release “Fn” key
4. Left hand: Press and release “r” key. (Screenshot dialogs may start popping up. Ignore them)
5. Left hand: Press and release “e” key. (Your GUI should collapse to a tty, most processes terminated)
6. Left hand: Press and release “i” key. (Progress of key shown in the tty, most proceses killed)
7. Left hand: Press and release “s” key. (Progress of key shown in the tty, syncs filesystems)
8. Left hand: Press and release “u” key. (Progress of key shown in the tty, unmounts filesystems)
9. Left hand: Press and release “b” key. (Progress of key shown in the tty, starts reboot)
10. Right hand: Release all keys
David Jung (djung) wrote : | #189 |
For those of us that just want to use Ubuntu without having to care what a "kernel" is, could someone kindly explain how to install the fix from comment #108? Just download all the .deb files from that web-page and install them with the software updater or software center?
Thank you.
David Jung (djung) wrote : | #190 |
For anyone else wondering, here's what seemed to work (don't really know if it is the correct approach):
1. Download select .deb files from the page mentioned in comment #180: http://
Specifically:
linux-cloud-
linux-cloud-
linux-doc_
linux-headers-
linux-image-
linux-image-
linux-libc-
linux-tools-
linux-tools-
(was guessing that the not 'generic' and 'lowlatency' files were variations)
(don't know if the cloudtools one is needed, it seemed to indicate some kind of error on installation regarding dependencies)
2. Install them with: sudo dpkg -i *.deb
3. Reboot and select "Advanced Options for Ubuntu" from the boot menu, then select the 4.10.0-20 entry (unfortunately, there doesn't seem to be a way to see which is actually the lp1674838 kernel just installed)
4. Once booted, you can do "uname -a" to check it is the bugfix kernel you're running (has the lp1674848 in the name).
Cheers.
Tim Passingham (tim-8aw3u04umo) wrote : | #191 |
@munbi - thanks. That doesn't seem to work for me on a different system, but pressing and holding Alt, PrintScreen and r, releasing all, then all of Alt, PrintScreen and e, the the same for b, etc, seemed to work. I didn't see the GUI collapse, but it did reboot. I guess the rest happened although I saw no visual evidence.
geez (geez) wrote : | #192 |
This bug affects my laptop running 17.04, which is an upgrade from an earlier installation. I appear to have no other kernels available in the repository that do not have this bug, and there's no way I'm installing an untrusted kernel.
Considering how long this bug has been open, this is getting ridiculous.
stupid user (mc6312) wrote : | #193 |
Very strange bug - occurred several times with the 4.10.0-20 and 4.10.0-21 kernels on the Intel Core i5-2400, but did not appear with the same kernels on the Intel Core 2 Duo E6700.
Dan Streetman (ddstreet) wrote : | #194 |
Just as an FYI to everyone still commenting in this bug, this is fixed in kernel 4.10.0-22.24:
https:/
which is in the -proposed repository:
https:/
and as Seth said in comments above, is scheduled for general release to the -updates repository on June 5:
https:/
Tim Passingham (tim-8aw3u04umo) wrote : | #195 |
Thanks. Installed and being used on a system that didn't display the fault, to check before inflicting on my other half.
Kwang Moo Yi (kwang-m-yi) wrote : | #196 |
@ddstreet: It seems it's not yet in the xenial-proposed repo yet, but probably will be there soon-ish I guess?
tkb608 (tkb608) wrote : | #197 |
I followed the instructions at https:/
This went smoothly for me. Thanks @ddstreet for the link.
@kwang-m-yi I can't speak for xenial yet, this was for zesty.
Dan Streetman (ddstreet) wrote : | #198 |
> It seems it's not yet in the xenial-proposed repo yet, but probably will be there
> soon-ish I guess?
Yes, there was a technical issue with the build, but it seems minor and so looks like it should be ready soon-ish. It will be listed here when it's in the -proposed repository:
https:/
tkb608 (tkb608) wrote : | #199 |
Not that I can recommend it to anyone else, but I did update to 4.10.0-22.24 on xenial 16.04.2 by pointing the to the zesty 17.04 proposed repo. Hasn't crashed in the 5 minutes I've been running it. Caveat emptor.
Brendan Murray (brendanpmurray) wrote : | #200 |
Just had something similar to Patrick's in #100 above, but this time on 9 different GPFs on kernel 4.10.0-21. The locations are all quite different, but I wonder if there is something common there:
May 23 14:34:02 thornback kernel: [ 1371.525043] general protection fault: 0000 [#1] SMP
May 23 14:34:02 thornback kernel: [ 1371.525053] Modules linked in: rfcomm bnep nls_utf8 hfsplus intel_rapl x86_pkg_
May 23 14:34:02 thornback kernel: [ 1371.525101] usbhid hid nouveau ahci libahci mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse drm alx mdio fjes video
May 23 14:34:02 thornback kernel: [ 1371.525115] CPU: 3 PID: 2208 Comm: compiz Not tainted 4.10.0-21-generic #23-Ubuntu
May 23 14:34:02 thornback kernel: [ 1371.525120] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77-DS3H, BIOS F11a 11/13/2013
May 23 14:34:02 thornback kernel: [ 1371.525125] task: ffff96b8cb718000 task.stack: ffffb2b043c74000
May 23 14:34:02 thornback kernel: [ 1371.525132] RIP: 0010:kmem_
May 23 14:34:02 thornback kernel: [ 1371.525135] RSP: 0018:ffffb2b043
May 23 14:34:02 thornback kernel: [ 1371.525139] RAX: 0000000000000000 RBX: 00000000014080c0 RCX: 00000000000161e2
May 23 14:34:02 thornback kernel: [ 1371.525143] RDX: 00000000000161e1 RSI: 00000000014080c0 RDI: 000000000001c6e0
May 23 14:34:02 thornback kernel: [ 1371.525147] RBP: ffffb2b043c77bd8 R08: ffff96b8ded9c6e0 R09: 0000000000000000
May 23 14:34:02 thornback kernel: [ 1371.525151] R10: 96b8306b23c00000 R11: 0000000000000000 R12: 00000000014080c0
May 23 14:34:02 thornback kernel: [ 1371.525155] R13: ffff96b8ce003540 R14: ffffffffc0434a62 R15: ffff96b8ce003540
May 23 14:34:02 thornback kernel: [ 1371.525168] FS: 00007f677a6b578
May 23 14:34:02 thornback kernel: [ 1371.525172] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 23 14:34:02 thornback kernel: [ 1371.525175] CR2: 00007f677a582510 CR3: 00000004062c0000 CR4: 00000000001406e0
May 23 14:34:02 thornback kernel: [ 1371.525179] Call Trace:
May 23 14:34:02 thornback kernel: [ 1371.525214] nouveau_
May 23 14:34:02 thornback kernel: [ 1371.525240] nouveau_
May 23 14:34:02 thornback kernel: [ 1371.525254] drm_ioctl+
May 23 14:34:02 thornback kernel: [ 1371.525258] ? ___sys_recv...
geez (geez) wrote : | #201 |
@ddstreet: Installed from zesty-proposed, testing it how. Question: Given that this is quite a critical bug, is there any reason this hasn't been put into the main archives sooner? It is quite a bad user experience, especially for novice users that won't find this bug nor know how to do a selective upgrade.
Dan Streetman (ddstreet) wrote : | #202 |
> Question: Given that this is quite a critical bug, is there any reason this
> hasn't been put into the main archives sooner?
I'm not the right person to ask that, but you can see Seth's comment 139 above.
"This is our normal SRU cycle. Out-of-cycle updates are for the most part
reserved for critical security issues."
Nazar Mokrynskyi (nazar-pc) wrote : | #203 |
I'm wondering how did it reach zesty-proposed earlier that artful-proposed. On Artful I still do not see an update.
Seth Forshee (sforshee) wrote : | #204 |
> I'm wondering how did it reach zesty-proposed earlier that artful-
> proposed. On Artful I still do not see an update.
In artful the kernels are just copied forward from zesty once they reach
-updates. Soon artful will switch to 4.11, at which point its kernels
will start going into proposed. You can manually download the deb
package files from zesty-proposed and install them in artful.
Tim Passingham (tim-8aw3u04umo) wrote : | #205 |
This may not be a security issue, but it certainly is critical to normal users who don't have access to information here, let alone temporary patches or proposed changes.
Maybe ubuntu only want techies using their systems, and would prefer normal users went elsewhere? I'll certainly have to start looking for an alternative, more stable system, for my partner's desktop.
Patrick McManus (mcmanus-ducksong) wrote : | #206 |
I now have 23 hours of uptime thanks to 4.10.0-22 #24 from zesty proposed. That's a zesty record for me :)
thanks.
geez (geez) wrote : | #207 |
@ddstreet, sforshee: Thanks for the replies. Given that this also affects LTS installations that use the HWE stack, shouldn't this have as high a priority as critical security issues? I'd consider this a critical usability issue; there are tons of people running LTS, particularly on servers, for exactly the reason that it is "always" stable. Needless to say this is a bit of an outlier considering Ubuntu's overall good track record.
I understand that testing 4.10.0-22 takes time; one could conceivably apply a hotfix to 4.10.0-21?
As far as my own testing is concerned, I've been using my personal laptop for work today (instead of my 16.04 work laptop) with the kernel from zesty-proposed, and no issues so far.
Daniel Holbert (dholbert) wrote : | #208 |
- kern.log snippet for lockup on 4.10.0-22-generic #24-Ubuntu Edit (6.5 KiB, text/plain)
I installed the kernel with the fix from zesty-proposed (4.10.0-22-generic #24-Ubuntu), but after ~4 hours of uptime on that kernel, I hit what felt like the same system lockup again. (Or perhaps a new version of this lockup that the patch introduces / leaves unfixed?)
Here's the kern.log from that lockup. Hope this is helpful; otherwise, sorry for adding noise.
Seth Forshee (sforshee) wrote : | #209 |
I apprciate that this bug has a significant impact for many. However we
have a QA process to test kernels before they get pushed out to
everyone, and it is always risky to skip this testing which is why we
rarely do it. In the case of the fix for this bug the changes required
are fairly substantial and should go through testing.
The kernel in zesty-proposed is exactly the same kernel that will be
released to -updates in a couple of weeks (assuming it passes QA, etc.)
so please do not hesitate to run this kernel. There is also a signed
kernel available in -proposed.
Seth Forshee (sforshee) wrote : | #210 |
> I installed the kernel with the fix from zesty-proposed
> (4.10.0-22-generic #24-Ubuntu), but after ~4 hours of uptime on that
> kernel, I hit what felt like the same system lockup again. (Or perhaps
> a new version of this lockup that the patch introduces / leaves
> unfixed?)
>
> Here's the kern.log from that lockup. Hope this is helpful; otherwise,
> sorry for adding noise.
>
> ** Attachment added: "kern.log snippet for lockup on 4.10.0-22-generic #24-Ubuntu"
> https:/
That is a differnt issue, please file a new bug. Thanks!
Rocko (rockorequin) wrote : | #211 |
@dholbert: your lockup looks like https:/
Daniel Holbert (dholbert) wrote : | #212 |
(Thanks @Rocko - I'd filed https:/
Thadeu Lima de Souza Cascardo (cascardo) wrote : | #213 |
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/
tags: | added: verification-needed-zesty |
flux242 (flux242) wrote : | #214 |
> If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
never go full retard, dude
Christian Nassau (nassau) wrote : | #215 |
I've been running "-proposed" for quite a while now without the kernel oops, hence changed the tag to "verification-
tags: |
added: verification-done-zesty removed: verification-needed-zesty |
flux242 (flux242) wrote : | #216 |
for those of you like me who were reluctant to add testing into the sources list (because of course it could break something else) and couldn't find the deb packages because they didn't provide any direct link, here is a little script I had to write that downloads and installs the kernel 4.10.0-22.24. Adjust the architecture and the download directory
Kwang Moo Yi (kwang-m-yi) wrote : | #217 |
@Tim - To be fair, Ubuntu LTS without the hwe-edge is perfectly stable. However, it is true that all this process was a bit disappointing, and I ended up moving to debian sid, which seems to be a quite stable experience so far.
Frode Nordahl (fnordahl) wrote : | #218 |
As much as I want the -22 to fix all problems, it does not.
However, my crashes does currently not leave a trace in the logs. Sticking to -13 keeps my workhorse running riddled of any crash or freeze problems.
The simplest way to describe what is going on is that all I/O gets stuck and that my displays get a interesting change/distortion to the background image. (I can provide screen-shots upon request)
Any advice on how to best collect useful data from crashed/frozen machine is welcome.
The issue is highly reproducible on my system under heavy load.
Example: Deploy some big software with your favorite deployment tool on LXD containers and libvirt virtual machines through MAAS, at the same time do some backups with duplicity and playback of (YouTube) video in your favorite browser (Firefox/Chrome).
Tim Passingham (tim-8aw3u04umo) wrote : | #219 |
I tried to install 4.10.0-22 on the one system we have that was regularly crashing, but it gets installation errors (being unable to access files in /usr/src/
Given that this system is stable on 4.8, I'll have to wait for the normal release process rather than check the proposed version.
Axy (joshi-a) wrote : | #220 |
Been affecting me as well -- will try the alternate kernels.
Kernel that's crashing:
axyjo@frost:~$ uname -a
Linux frost 4.10.0-21-generic #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Walter Garcia-Fontes (walter-garcia) wrote : | #221 |
I'm getting a freeze with the same symptoms described in this bug report, but with this message
May 31 02:37:27 walter kernel: [410240.819651] NMI watchdog:
BUG: soft lockup - CPU#14 stuck for 22s! [JS Helper:23856]
I'm running 4.10.0-21-generic.
I will duplicate my bug report (bug #1677491) to this one, feel free to reverse if it is not the same bug.
Hans van den Bogert (hbogert) wrote : | #222 |
It's strange that I hit this at least once every two days, but server has been working for weeks now.
Is there already a description of what common scenarios are when this bug is hit, i.e., is it already reproducible?
Walter Garcia-Fontes (walter-garcia) wrote : | #223 |
I've seen this bug in the scenario described in comment #218. In my case, there was always a frozen Firefox around, but all the other processes running in the system where also reacting slowly or frozen.
Nikolaj Løbner Sheller (nikolaj-l) wrote : | #224 |
- Kernel Bug.txt Edit (4.8 KiB, text/plain)
I just experienced this bug on 4.10.0-21-generic #23-Ubuntu.
My Firefox stopped responding, and when trying to kill Firefox the Firefox process became un-killable used 25% CPU time and N/A memory.
CPU: 3 PID: 2558 Comm: firefox Tainted: G OE 4.10.0-21-generic #23-Ubuntu
This is the first time I have seen the issue. I have been running 17.04 for two or three weeks.
Michael Thayer (michael-thayer) wrote : | #225 |
I was also experiencing this issue with the official 4.10.0-21-generic kernel; I ran the ~lp1674838 kernel for several days, and have been running the -22-generic test kernel for a couple without problems.
vvhk (vvhk-deactivatedaccount-deactivatedaccount) wrote : | #226 |
Got bitten by this again today. Ubuntu 17.04, 4.10.0-21-generic #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux. Firefox again.
I think this is issue is critical enough to expedite the release of fixed kernel, posthaste.
Colan Schwartz (colan) wrote : | #227 |
Folks, just enable the Proposed channel for the next four days (until this is released into stable on the 5th). You can disable it again afterwards. This is what I've been doing, and haven't run into this issue again (or any other problems with Proposed).
Launchpad Janitor (janitor) wrote : | #228 |
This bug was fixed in the package linux - 4.10.0-22.24
---------------
linux (4.10.0-22.24) zesty; urgency=low
* linux: 4.10.0-22.24 -proposed tracker (LP: #1691146)
* Fix NVLINK2 TCE route (LP: #1690155)
- powerpc/powernv: Fix TCE kill on NVLink2
* CVE-2017-0605
- tracing: Use strlcpy() instead of strcpy() in __trace_
* perf: qcom: Add L3 cache PMU driver (LP: #1689856)
- [Config] CONFIG_
- perf: qcom: Add L3 cache PMU driver
* No PMU support for ACPI-based arm64 systems (LP: #1689661)
- drivers/perf: arm_pmu: rework per-cpu allocation
- drivers/perf: arm_pmu: manage interrupts per-cpu
- drivers/perf: arm_pmu: split irq request from enable
- drivers/perf: arm_pmu: remove pointless PMU disabling
- drivers/perf: arm_pmu: define armpmu_init_fn
- drivers/perf: arm_pmu: fold init into alloc
- drivers/perf: arm_pmu: factor out pmu registration
- drivers/perf: arm_pmu: simplify cpu_pmu_
- drivers/perf: arm_pmu: handle no platform_device
- drivers/perf: arm_pmu: rename irq request/free functions
- drivers/perf: arm_pmu: split cpu-local irq request/free
- drivers/perf: arm_pmu: move irq request/free into probe
- drivers/perf: arm_pmu: split out platform device probe logic
- arm64: add function to get a cpu's MADT GICC table
- [Config] CONFIG_
- drivers/perf: arm_pmu: add ACPI framework
- arm64: pmuv3: handle !PMUv3 when probing
- arm64: pmuv3: use arm_pmu ACPI framework
* [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin
(LP: #1689886)
- ipmi: Fix kernel panic at ipmi_ssif_thread()
* tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818)
- tty: pl011: fix earlycon work-around for QDF2400 erratum 44
- tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44
* kernel-wedge fails in artful due to leftover squashfs-modules d-i files
(LP: #1688259)
- Remove squashfs-modules files from d-i
- [Config] as squashfs-modules is builtin kernel-image must Provides: it
* arm64/ACPI support for SBSA watchdog (LP: #1688114)
- clocksource: arm_arch_timer: clean up printk usage
- clocksource: arm_arch_timer: rename type macros
- clocksource: arm_arch_timer: rename the PPI enum
- clocksource: arm_arch_timer: move enums and defines to header file
- clocksource: arm_arch_timer: add a new enum for spi type
- clocksource: arm_arch_timer: rework PPI selection
- clocksource: arm_arch_timer: split dt-only rate handling
- clocksource: arm_arch_timer: refactor arch_timer_
- clocksource: arm_arch_timer: move arch_timer_
call
- clocksource: arm_arch_timer: add structs to describe MMIO timer
- clocksource: arm_arch_timer: split MMIO timer probing.
- [Config] CONFIG_ACPI_GTDT=y
- acpi/arm64: Add GTDT table parse driver
- clocksource: arm_arch_timer: simplify ACPI support code.
- acpi/arm64: Add memory-mapped timer support in GTDT driver
- clocksource: arm_arch_timer: add GTDT support for memory-mapped timer
- acpi/arm64: Add SBS...
Changed in linux (Ubuntu): | |
status: | Fix Committed → Fix Released |
Vincas Dargis (talkless) wrote : | #229 |
When it should be available for 16.04?
Tim Passingham (tim-8aw3u04umo) wrote : | #230 |
Is there a delay in getting 4.10.0-22 to stable release? I had previously understood it was expected yesterday (June 5th).
information type: | Public → Private |
information type: | Private → Public |
Launchpad Janitor (janitor) wrote : | #231 |
This bug was fixed in the package linux - 4.10.0-22.24
---------------
linux (4.10.0-22.24) zesty; urgency=low
* linux: 4.10.0-22.24 -proposed tracker (LP: #1691146)
* Fix NVLINK2 TCE route (LP: #1690155)
- powerpc/powernv: Fix TCE kill on NVLink2
* CVE-2017-0605
- tracing: Use strlcpy() instead of strcpy() in __trace_
* perf: qcom: Add L3 cache PMU driver (LP: #1689856)
- [Config] CONFIG_
- perf: qcom: Add L3 cache PMU driver
* No PMU support for ACPI-based arm64 systems (LP: #1689661)
- drivers/perf: arm_pmu: rework per-cpu allocation
- drivers/perf: arm_pmu: manage interrupts per-cpu
- drivers/perf: arm_pmu: split irq request from enable
- drivers/perf: arm_pmu: remove pointless PMU disabling
- drivers/perf: arm_pmu: define armpmu_init_fn
- drivers/perf: arm_pmu: fold init into alloc
- drivers/perf: arm_pmu: factor out pmu registration
- drivers/perf: arm_pmu: simplify cpu_pmu_
- drivers/perf: arm_pmu: handle no platform_device
- drivers/perf: arm_pmu: rename irq request/free functions
- drivers/perf: arm_pmu: split cpu-local irq request/free
- drivers/perf: arm_pmu: move irq request/free into probe
- drivers/perf: arm_pmu: split out platform device probe logic
- arm64: add function to get a cpu's MADT GICC table
- [Config] CONFIG_
- drivers/perf: arm_pmu: add ACPI framework
- arm64: pmuv3: handle !PMUv3 when probing
- arm64: pmuv3: use arm_pmu ACPI framework
* [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin
(LP: #1689886)
- ipmi: Fix kernel panic at ipmi_ssif_thread()
* tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818)
- tty: pl011: fix earlycon work-around for QDF2400 erratum 44
- tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44
* kernel-wedge fails in artful due to leftover squashfs-modules d-i files
(LP: #1688259)
- Remove squashfs-modules files from d-i
- [Config] as squashfs-modules is builtin kernel-image must Provides: it
* arm64/ACPI support for SBSA watchdog (LP: #1688114)
- clocksource: arm_arch_timer: clean up printk usage
- clocksource: arm_arch_timer: rename type macros
- clocksource: arm_arch_timer: rename the PPI enum
- clocksource: arm_arch_timer: move enums and defines to header file
- clocksource: arm_arch_timer: add a new enum for spi type
- clocksource: arm_arch_timer: rework PPI selection
- clocksource: arm_arch_timer: split dt-only rate handling
- clocksource: arm_arch_timer: refactor arch_timer_
- clocksource: arm_arch_timer: move arch_timer_
call
- clocksource: arm_arch_timer: add structs to describe MMIO timer
- clocksource: arm_arch_timer: split MMIO timer probing.
- [Config] CONFIG_ACPI_GTDT=y
- acpi/arm64: Add GTDT table parse driver
- clocksource: arm_arch_timer: simplify ACPI support code.
- acpi/arm64: Add memory-mapped timer support in GTDT driver
- clocksource: arm_arch_timer: add GTDT support for memory-mapped timer
- acpi/arm64: Add SBS...
Changed in linux (Ubuntu Zesty): | |
status: | Fix Committed → Fix Released |
Tim Passingham (tim-8aw3u04umo) wrote : | #232 |
There's a problem with this new version - it won't install on the one system I have that is affected by the bug. The installation error is:
dpkg: error processing archive /var/cache/
unable to open '/usr/src/
The directory contains:
.../usr/
total 20
drwxr-xr-x 5 root root 4096 Jun 6 15:01 .
drwxr-xr-x 13 root root 4096 Jun 6 15:01 ..
drwxr-xr-x 3 root root 4096 Jun 6 15:01 include
drwxr-xr-x 3 root root 4096 Jun 6 15:01 kernel
drwxr-xr-x 3 root root 4096 Jun 6 15:01 pci
..../usr/
I've done a clean, update and install -f, but the headers still failed to install, giving a similar but different error code.
Tim Passingham (tim-8aw3u04umo) wrote : | #233 |
I have now reported the installation error using the automated report system - #1696132
Launchpad Janitor (janitor) wrote : | #234 |
This bug was fixed in the package linux-hwe-edge - 4.10.0-
---------------
linux-hwe-edge (4.10.0-
* linux-hwe-edge: 4.10.0-
* linux: 4.10.0-22.24 -proposed tracker (LP: #1691146)
* Fix NVLINK2 TCE route (LP: #1690155)
- powerpc/powernv: Fix TCE kill on NVLink2
* CVE-2017-0605
- tracing: Use strlcpy() instead of strcpy() in __trace_
* perf: qcom: Add L3 cache PMU driver (LP: #1689856)
- [Config] CONFIG_
- perf: qcom: Add L3 cache PMU driver
* No PMU support for ACPI-based arm64 systems (LP: #1689661)
- drivers/perf: arm_pmu: rework per-cpu allocation
- drivers/perf: arm_pmu: manage interrupts per-cpu
- drivers/perf: arm_pmu: split irq request from enable
- drivers/perf: arm_pmu: remove pointless PMU disabling
- drivers/perf: arm_pmu: define armpmu_init_fn
- drivers/perf: arm_pmu: fold init into alloc
- drivers/perf: arm_pmu: factor out pmu registration
- drivers/perf: arm_pmu: simplify cpu_pmu_
- drivers/perf: arm_pmu: handle no platform_device
- drivers/perf: arm_pmu: rename irq request/free functions
- drivers/perf: arm_pmu: split cpu-local irq request/free
- drivers/perf: arm_pmu: move irq request/free into probe
- drivers/perf: arm_pmu: split out platform device probe logic
- arm64: add function to get a cpu's MADT GICC table
- [Config] CONFIG_
- drivers/perf: arm_pmu: add ACPI framework
- arm64: pmuv3: handle !PMUv3 when probing
- arm64: pmuv3: use arm_pmu ACPI framework
* [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin
(LP: #1689886)
- ipmi: Fix kernel panic at ipmi_ssif_thread()
* tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818)
- tty: pl011: fix earlycon work-around for QDF2400 erratum 44
- tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44
* kernel-wedge fails in artful due to leftover squashfs-modules d-i files
(LP: #1688259)
- Remove squashfs-modules files from d-i
- [Config] as squashfs-modules is builtin kernel-image must Provides: it
* arm64/ACPI support for SBSA watchdog (LP: #1688114)
- clocksource: arm_arch_timer: clean up printk usage
- clocksource: arm_arch_timer: rename type macros
- clocksource: arm_arch_timer: rename the PPI enum
- clocksource: arm_arch_timer: move enums and defines to header file
- clocksource: arm_arch_timer: add a new enum for spi type
- clocksource: arm_arch_timer: rework PPI selection
- clocksource: arm_arch_timer: split dt-only rate handling
- clocksource: arm_arch_timer: refactor arch_timer_
- clocksource: arm_arch_timer: move arch_timer_
call
- clocksource: arm_arch_timer: add structs to describe MMIO timer
- clocksource: arm_arch_timer: split MMIO timer probing.
- [Config] CONFIG_ACPI_GTDT=y
- acpi/arm64: Add GTDT table parse driver
- clocksource: arm_arch_timer: simplify ACPI support code.
- acpi/arm64: Add memory-mapped timer support in GTD...
Changed in linux-hwe-edge (Ubuntu): | |
status: | In Progress → Fix Released |
status: | In Progress → Fix Released |
Changed in ubuntu-power-systems: | |
status: | New → Fix Released |
Christian Sarrasin (sxc731) wrote : | #236 |
@tim-8aw3u04umo no installation issue here. I used: 'sudo apt update && sudo apt upgrade'.
uname -r reports "4.10.0-22-generic"
Tim Passingham (tim-8aw3u04umo) wrote : | #237 |
I have 4 17.04 systems. The one that had this bug is the only one which has an installation problem with 4.10.0-22. Maybe a coincidence, maybe not?
Tim Passingham (tim-8aw3u04umo) wrote : | #238 |
Seth has fixed my installation problem, so all my 4 17.04 4.10.0.22 systems are now being used. I'll report if I get any further crashes (but I don't expect any).
See #1696132 if you are interested in what the problem was.
Changed in linux-hwe-edge (Ubuntu Zesty): | |
status: | Fix Committed → Fix Released |
Robbie Crash (sardonic-smiles) wrote : | #239 |
- kern.log snippet Edit (33.7 MiB, application/octet-stream)
I believe I may still be encountering this bug, this seems to happen any time the system is under significant load. Attached is my kern.log from right after the NMI watchdog soft lockups start. Please let me know if I should submit additional logs from the next time this happens, or submit a new bug.
Kai-Heng Feng (kaihengfeng) wrote : | #240 |
@Robbie
It's not the same, please file a new bug.
Richard Hainsworth (rnhainsworth) wrote : | #241 |
uname -a
Linux merlin 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Same symptoms as reported about. Firefox freezes and causes the system to freeze.
Cannot get Firefox to work. I have had to install Chrome in order to access web.
Have sent automated crash reports to Mozilla and Ubuntu.
If it is not the same problem as reported here, it looks the same from all comments her.
This change was made by a bot.