4.8.0 kernels do not complete boot process on VM

Bug #1627198 reported by Barry Warsaw
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Undecided
linux (Ubuntu)
Fix Released
Critical
Canonical Kernel Team
Yakkety
Fix Released
Critical
Canonical Kernel Team
linux-raspi2 (Ubuntu)
Fix Released
Undecided
Tim Gardner
Yakkety
Fix Released
Undecided
Tim Gardner

Bug Description

On my native amd64 box, 4.8.0-15 works just fine, but on my VMWare Fusion 8.5 system, none of the 4.8.0 kernels complete the boot process. I tried 4.8.0-15 from yakkety and 4.8.0-16 from yakkety-proposed.

Currently I am seeing the last message in my console at boot up as:

[ OK ] Started Bluetooth service

and then... it just sits there.

Through the use of snapshots, restores, and package bisects, I've definitively narrowed it to linux-generic linux-image-generic and linux-headers-generic.

Revision history for this message
In , Vinson (vinson-redhat-bugs) wrote :
Download full text (3.6 KiB)

Description of problem:
kernel BUG at mm/usercopy.c:75!

Version-Release number of selected component (if applicable):
kernel-4.8.0-0.rc4.git4.1.fc26.x86_64

How reproducible:

Steps to Reproduce:
1. boot
2.
3.

Actual results:

------------[ cut here ]------------
kernel BUG at mm/usercopy.c:75!
invalid opcode: 0000 [#1] SMP
Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security ebtable_filter ebtables ip6table_filter ip6_tables bnep vmw_vsock_vmci_transport vsock snd_seq_midi snd_seq_midi_event intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ppdev ghash_clmulni_intel btusb intel_rapl_perf uvcvideo btrtl btbcm btintel vmw_balloon snd_ens1371 gameport videobuf2_vmalloc snd_rawmidi videobuf2_memops bluetooth
 videobuf2_v4l2 snd_ac97_codec videobuf2_core ac97_bus videodev snd_seq snd_seq_device media snd_pcm rfkill joydev snd_timer snd soundcore vmw_vmci shpchp nfit i2c_piix4 parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw vmwgfx drm_kms_helper e1000 ttm mptspi scsi_transport_spi drm mptscsih ata_generic mptbase pata_acpi fjes
CPU: 0 PID: 1268 Comm: gnome-shell Not tainted 4.8.0-0.rc4.git4.1.fc26.x86_64 #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
task: ffff9394e8568000 task.stack: ffff9394cece8000
RIP: 0010:[<ffffffffa629eea1>] [<ffffffffa629eea1>] __check_object_size+0x111/0x47a
RSP: 0018:ffff9394cecebc10 EFLAGS: 00010282
RAX: 000000000000006c RBX: ffff9394e6800000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9394ed7ce2a8 RDI: ffff9394ed7ce2a8
RBP: ffff9394cecebc58 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000001128
R13: 0000000000000000 R14: ffff9394e6801128 R15: 000003fffff00000
FS: 00007f5a72ac4ac0(0000) GS:ffff9394ed600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000558bcb39db08 CR3: 000000004ee6b000 CR4: 00000000003406f0
Stack:
 ffff9394e8568000 0000558bcb3086e0 ffff9394e72c0000 ffff9394e6801127
 ffff9394e72c0000 0000558bcb3086e0 ffff9394e72c0000 ffff9394e6800000
 0000000000001128 ffff9394cecebd90 ffffffffc0369eec 0000000000000246
Call Trace:
 [<ffffffffc0369eec>] vmw_execbuf_process+0x97c/0x1370 [vmwgfx]
 [<ffffffffc02e9138>] ? __ttm_read_lock+0x48/0x90 [ttm]
 [<ffffffffc02e95a6>] ? ttm_read_lock.part.1+0x46/0xd0 [ttm]
 [<ffffffffa6237283>] ? __might_fault+0x43/0xa0
 [<ffffffffc02e965c>] ? ttm_read_lock+0x2c/0xd0 [ttm]
 [<ffffffffc036aa72>] vmw_execbuf_ioctl+0x142/0x1b0 [vmwgfx]
 [<ffffffffc036e971>] vmw_generic_ioctl+0x251/0x290 [vmwgfx]
 [<ffffffffc036e9e5>] vmw_unlocked_ioctl+0x15/0x20 [vmwgfx]
 [<ffffffffa62ba403>] do_vfs_ioctl+0xa3/0x720
 [<ffffffffa62c7c85>] ? __fget+0x5/0x200
...

Read more...

Revision history for this message
In , Laura (laura-redhat-bugs) wrote :

Hardened usercopy caught something, can you share the full kernel log

Revision history for this message
In , Vinson (vinson-redhat-bugs) wrote :

Created attachment 1198401
4.8.0-0.rc4.git4.1.fc26.x86_64 kernel log

Brad Figg (brad-figg)
tags: added: kernel-4.8
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1627198

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Barry Warsaw (barry)
summary: - 4.4.8 kernels do not complete boot process on VM
+ 4.8.0 kernels do not complete boot process on VM
Revision history for this message
Barry Warsaw (barry) wrote :

Unfortunately, I cannot run this command on the system in question since booting with the defective kernel never gives me a prompt or an ssh login.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
importance: Undecided → Critical
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Barry,

Could you re-test with the 4.8.0-17.19 kernel we have in ppa:canonical-kernel-team/unstable

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable

Thanks in advance.

Revision history for this message
Barry Warsaw (barry) wrote : Re: [Bug 1627198] Re: 4.8.0 kernels do not complete boot process on VM

On Sep 26, 2016, at 12:48 PM, Leann Ogasawara wrote:

>Could you re-test with the 4.8.0-17.19 kernel we have in ppa:canonical-
>kernel-team/unstable

Unfortunately this kernel also fails to completely boot. The last things I
see in the console are

[ OK ] Started Login Service.
[ 36.445144] cgroup: new mount options do not match the existing superbock, will be ignored

I'll also mention that I see what looks like a crash in __wake_up_common. I
see the Call Trace: but I can't scroll up on the console to get the details.

tags: added: kernel-key
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I'd like to perform a kernel bisect to identify the commit that introduced this regression. We need to first identify the last good kernel version and the first bad one. Do you know what kernel was the last one that did not exhibit this bug? If not, I can post some download links, so prior kernels can be tested.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :
Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 26, 2016, at 06:18 PM, Joseph Salisbury wrote:

>v4.5: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/
>v4.6: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/
>v4.7: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/

All of these kernels (amd64, generic) boot successfully.

tags: added: performing-bisect
Revision history for this message
Barry Warsaw (barry) wrote :

4.8 rc1 does not boot

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I started a kernel bisect between v4.7 final and v4.8-rc1. The kernel bisect will require testing of about 7-10 test kernels.

I built the first test kernel, up to the following commit:
1c88e19b0f6a8471ee50d5062721ba30b8fd4ba9

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
f7816ad0f878dacd5f0120476f9b836ccf8699ea

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Vinson Lee (vlee) wrote :
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Commit 8e1f74ea0, mentioned in comment #11, was not added to mainline until v4.8-rc6. However, Barry is seeing this bug as early as v4.8-rc1.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
55392c4c06204c8149dc333309cf474691f1cc3c

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
52770c37db2c0ee5585dae2de3d19c8453f1e8dc

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 26, 2016, at 10:52 PM, Joseph Salisbury wrote:

>I built the next test kernel, up to the following commit:
>52770c37db2c0ee5585dae2de3d19c8453f1e8dc

This one boots!

linux-image-4.7.0-040700-generic_4.7.0-040700.201609261819_amd64.deb

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
5048c2af078d5976895d521262a8802ea791f3b0

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 26, 2016, at 11:36 PM, Joseph Salisbury wrote:

>I built the next test kernel, up to the following commit:
>5048c2af078d5976895d521262a8802ea791f3b0

#201609261917 boots!

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
0f657262d5f99ad86b9a63fb5dcd29036c2ed916

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 27, 2016, at 03:32 PM, Joseph Salisbury wrote:

>I built the next test kernel, up to the following commit:
>0f657262d5f99ad86b9a63fb5dcd29036c2ed916

Thanks. 201609271113 does *not* boot.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
c86ad14d305d2429c3da19462440bac50c183def

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
3ebfd81f7fb3e81a754e37283b7f38c62244641a

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
be8a18e2e98e04a5def5887d913b267865562448

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
af2cf278ef4f9289f88504c3e03cb12f76027575

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
2deb4be28077638591fe5fc593b7f8aabc140f42

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
9a2e9da3e003112399f2863b7b6b911043c01895

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
46aea3873401836abb7f01200e7946e7d518b359

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

The bisect reported the following as the first bad commit:

commit 2deb4be28077638591fe5fc593b7f8aabc140f42
Author: Andy Lutomirski <email address hidden>
Date: Thu Jul 14 13:22:55 2016 -0700

    x86/dumpstack: When OOPSing, rewind the stack before do_exit()

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 27, 2016, at 08:28 PM, Joseph Salisbury wrote:

>The bisect reported the following as the first bad commit:
>
>commit 2deb4be28077638591fe5fc593b7f8aabc140f42
>Author: Andy Lutomirski <email address hidden>
>Date: Thu Jul 14 13:22:55 2016 -0700
>
> x86/dumpstack: When OOPSing, rewind the stack before do_exit()

I should note that while I can't seem to capture it, the console does show
some stack track on boot.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built a Yakkety test kernel with a revert of commit 2deb4be28077638591fe5fc593b7f8aabc140f42.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you see if this kernel resolves this bug?

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 27, 2016, at 09:15 PM, Joseph Salisbury wrote:

>Can you see if this kernel resolves this bug?

Almost! As mentioned in IRC, it boots but login doesn't give me a desktop.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built a mainline kenel with commit 2deb4be28077638591fe5fc593b7f8aabc140f42 reverted.

Can you test this kernel to see if it also has the new desktop issue?

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 27, 2016, at 11:12 PM, Joseph Salisbury wrote:

>I built a mainline kenel with commit
>2deb4be28077638591fe5fc593b7f8aabc140f42 reverted.
>
>Can you test this kernel to see if it also has the new desktop issue?

That one gets a little farther but ultimately doesn't give me a desktop
either.

The previous kernels, once I logged in all I was left with was the lightdm
wallpaper. With this kernel, the screen goes black, but that's it. No
response on the desktop to mouse or keyboard clicks, but ssh works and htop
doesn't show any abnormal stats.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

It looks like we'll have to perform a second bisect, but also reverting commit 2deb4be2 between each step.

Let's start by testing v4.8-rc1 with commit 2deb4be2 reverted. That kernel is now build and available in the usual location:

http://kernel.ubuntu.com/~jsalisbury/lp1627198

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 28, 2016, at 02:39 PM, Joseph Salisbury wrote:

>It looks like we'll have to perform a second bisect, but also reverting
>commit 2deb4be2 between each step.

Just to follow up, I was able to eventually gain a desktop with the rc1 kernel
and the bad commit reverted. My current plan is to dist-upgrade to latest
yakkety, sans kernel packages, and you're going to build the rc2 kernel with
the revert. Let's test that and see where we are.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Working on IRC, but posting here to keep track of all the commits for the second bisect.

I built the next test kernel, up to the following commit:
7de249964f5578e67b99699c5f0b405738d820a2

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
cb0d93aaf06d9b23dc2b21b59c6c4bf7da6f0da3

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
a3d1ddd932bc86f0f7027079754ab0aefd259109

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
97433ea4fda62349bfa42089455593cbcb57e06c

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 28, 2016, at 11:06 PM, Joseph Salisbury wrote:

>I built the next test kernel, up to the following commit:
>97433ea4fda62349bfa42089455593cbcb57e06c

201609281855 boots and gives me a desktop. No crash in usercopy.c found in
syslog.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
1eccfa090eaea22558570054bbdc147817e1df5e

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Barry Warsaw (barry) wrote :

On Sep 29, 2016, at 03:20 AM, Joseph Salisbury wrote:

>I built the next test kernel, up to the following commit:
>1eccfa090eaea22558570054bbdc147817e1df5e

201609282035 boots, does not give me a desktop, and I see the crash in the
syslog.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
1bd4403d86a1c06cb6cc9ac87664a0c9d3413d51

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
ed18adc1cdd00a5c55a20fbdaed4804660772281

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built a Yakkety test kernel with CONFIG_HARDENED_USERCOPY_PAGESPAN disabled.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1627198

Can you test that kernel and report back if it has the bug or not?

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

@Vinson Lee, it looks like you were correct about that option!

Changed in linux (Ubuntu Yakkety):
status: Confirmed → Fix Committed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

This config option is intended to be used only while trying to find anything that copies from userspace with cross page boundaries, and it looks like some vmware driver was doing exactly that.

Revision history for this message
Barry Warsaw (barry) wrote :

FWIW, I posted to the Fusion forums:

https://communities.vmware.com/message/2623359#2623359

Revision history for this message
Tim Gardner (timg-tpi) wrote :

UBUNTU: [Config] CONFIG_HARDENED_USERCOPY_PAGESPAN=n

Tim Gardner (timg-tpi)
Changed in linux-raspi2 (Ubuntu Yakkety):
assignee: nobody → Tim Gardner (timg-tpi)
status: New → Fix Committed
Revision history for this message
Seth Forshee (sforshee) wrote :

I just wanted to add a note here to clarify things a little bit, since from the comments here it's all a bit muddled. There are two loosely related things happening.

The first problem, which is fixed by setting CONFIG_HARDENED_USERCOPY_PAGESPAN=n, is that some security enhancements were added in kernel version 4.8 related to copying memory from userspace. One of these hardening features was to check for copies from userspace which cross a page boundary, and when this happens the kernel logs an error and terminates the running task immediately by causing it to oops. This turned out to be too aggressive for now, because the vmwgfx module is doing these sorts of memory copies from userspace. Therefore when CONFIG_HARDENED_USERCOPY_PAGESPAN was enabled and the kernel booted in VMWare Fusion, Barry was getting an oops.

This triggered the second problem. There's also a patch in 4.8 which aims to make oopsing behave more reliably by calling do_exit() with a clean stack, and this seems to be causing some sort of problems on VMWare Fusion when the kernel oopses. The exact nature of those problems isn't yet clear. Fixing the problem above side steps the problems caused by this patch as it prevents the oops from happening, however I suspect that the problem remains.

Revision history for this message
Barry Warsaw (barry) wrote :

Thanks for the extra details Seth.

Can you say whether it's the second problem that was breaking the desktop
coming up on login? IOW, I observed two problems. One was a freeze during
the boot process, and the other was a freeze during the login process
(although the latter wasn't a total freeze, as ssh still worked).

Revision history for this message
Seth Forshee (sforshee) wrote :

> Can you say whether it's the second problem that was breaking the desktop
> coming up on login? IOW, I observed two problems. One was a freeze during
> the boot process, and the other was a freeze during the login process
> (although the latter wasn't a total freeze, as ssh still worked).

As far as I can tell from the history here,
CONFIG_HARDENED_USERCOPY_PAGESPAN was responsible for the desktop not
coming up. Having the "rewind the stack before do_exit()" patch in
combination with that option prevented booting, becuase the usercopy
hardening created an oops that triggered the code paths affected by the
patch (but I'm still not sure what about that patch caused boot to
hang).

tags: added: kernel-da-key
removed: kernel-key
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 4.8.0-19.21

---------------
linux (4.8.0-19.21) yakkety; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1629057

  * 4.8.0 kernels do not complete boot process on VM (LP: #1627198)
    - [Config] CONFIG_HARDENED_USERCOPY_PAGESPAN=n

  * mount-image-callback cannot mount partitioned disk image (LP: #1628336)
    - SAUCE: nbd: Only delay uevent until connected

  * Support snaps inside of lxd containers (LP: #1611078)
    - apparmor: add interface to be able to grab loaded policy
    - securityfs: update interface to allow inode_ops, and setup from vfs fns
    - apparmor: refactor aa_prepare_ns into prepare_ns and create_ns routines
    - apparmor: add __aa_find_ns fn
    - apparmor: add mkdir/rmdir interface to manage policy namespaces
    - apparmor: fix oops in pivot_root mediation
    - apparmor: fix warning that fn build_pivotroot discards const
    - apparmor: add interface to advertise status of current task stacking
    - apparmor: update policy permissions to consider ns being viewed/managed
    - apparmor: add per ns policy management interface
    - apparmor: bump domain stacking version to 1.2

  * linux-image-extra-4.8.0-17-generic does not provide many sound card modules
    (LP: #1628523)
    - [Config] CONFIG_ZONE_DMA=y for generic

  * Yakkety - disable ARCH_ZX (LP: #1628503)
    - [Config] armhf: disable ARCH_ZX

  * Enable switchdev config parameter for Yakkety (LP: #1628241)
    - [Config] CONFIG_NET_SWITCHDEV=y for amd64/arm64

  * Ubuntu 16.10 kernel v4.8: Installation failing on Habanero with Shiner card
    (LP: #1628009)
    - firmware: Update bnx2x to 7.13.1.0

  * vNIC driver missing in 4.8 kernel package (LP: #1628187)
    - [Config] Enable CONFIG_IBMVNIC=m

  * Yakkety - armhf: MFD_TPS65217 and REGULATOR_TPS65217 are boot essential
    (LP: #1628112)
    - [Config] armhf: MFD_TPS65217=y && REGULATOR_TPS65217=y

  * Miscellaneous Ubuntu changes
    - Rebase to v4.8-rc8
    - [Config] skip Ubuntu-4.8.0-18.20
    - [Config] missing modules in armhf/s390x

  * Miscellaneous Ubuntu changes
    - rebase to v4.8-rc8

 -- Leann Ogasawara <email address hidden> Sun, 25 Sep 2016 12:13:35 -0700

Changed in linux (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Revision history for this message
Barry Warsaw (barry) wrote :

Confirmed that Yakkety main kernel boots and logs into the desktop.

% uname -a
Linux anarchist 4.8.0-040800rc1-generic #201609281024 SMP Wed Sep 28 14:26:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
% dpkg-query -W linux-image-generic
linux-image-generic 4.8.0.19.28

Thanks!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux-raspi2 - 4.8.0-1012.14

---------------
linux-raspi2 (4.8.0-1012.14) yakkety; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1630339

  * Rebase against Ubuntu-4.8.0-21.23

 -- Tim Gardner <email address hidden> Tue, 04 Oct 2016 11:57:45 -0600

Changed in linux-raspi2 (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Revision history for this message
Grief (iamgrief) wrote :

I have exactly the same issue with kernel 4.8.1 taken from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8.1/

Isn't this bug supposed to be fixed already?

Revision history for this message
Dylan Borg (borgdylan) wrote :

I am having similar issues booting on my i7 6900K CPU. This is an issue on real hardware, not a VM. The relevant bug is here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1633172 .

Revision history for this message
Grief (iamgrief) wrote :

Seems that kernels in http://kernel.ubuntu.com/~kernel-ppa/mainline/ are not fixed yet. I recompiled the kernel by myself with CONFIG_HARDENED_USERCOPY_PAGESPAN disabled and it works now. Some details are in this thread: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1633172

Revision history for this message
Tim Gardner (timg-tpi) wrote :

Grief - mainline only gets built when upstream Linux changes, hence the reason for this stale config which we've since changed in the distro kernel. I've requested a mainline rebuild which should complete presently.

Revision history for this message
Grief (iamgrief) wrote :

@timg-tpi: Got it! Thanks for the explanation. As I said, I've compiled the kernel on my own, so don't worry :) But looks like a lack of testing before the release

Revision history for this message
cfz (cfz) wrote :

seems disabling the thermald.service is a walk around
i'm using
4.8.0-22-generic #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
In , Neil (neil-redhat-bugs) wrote :

Looks like a failure on copy_from_user, specifically vmware tried to preform a copy_from_user of more thana page worth of data to a heap allocated space allocated via vmalloc.

Upstream, this shouldn't be a problem as vmalloc addresses shouldn't be tested page spanning, as per commit 8e1f74ea02cf4562404c48c6882214821552c13f. Thats not available to 4.8-rc6. I can backport it if you like, or we can just wait for the update. Let me know what you would like to do

Revision history for this message
In , Laura (laura-redhat-bugs) wrote :

This is available in the current rawhide release.

Revision history for this message
Barry Warsaw (barry) wrote :

This has returned for Zesty. LP: #1641976

Changed in linux:
importance: Unknown → Undecided
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.