[Lenovo ThinkPad T400] kexec reboot fails

[MegaBrutal]

After release upgrade to Utopic, when I reboot with kexec (simply with "reboot" command), my computer cold reboots after "Starting new kernel" (i.e. I need to get through the POST and GRUB), instead of the new kernel being loaded. Previously I didn't experience problems with Trusty.

It matters which kernel I try to boot, while it doesn't matter what kernel I kexec from, and which version of kexec-tools I have.

I can't boot 3.16.0-25, nor 3.18.0-031800rc6 from any installed kernels, while I can boot 3.13.0-39 from any kernels without any problems.

I tried to downgrade kexec-tools from 1:2.0.7-1ubuntu2 (utopic) to 1:2.0.6-0ubuntu2.1 (trusty), but it made no difference.

I have a Lenovo Thinkpad T400. I didn't experience the same on my other machines, so I suspect some hardware-dependent issue.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-25-generic 3.16.0-25.33
ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
Uname: Linux 3.16.0-25-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: megabrutal 2497 F.... pulseaudio
 /dev/snd/seq: timidity 1420 F.... timidity
Date: Thu Nov 27 07:40:07 2014
HibernationDevice: RESUME=UUID=3d113c6f-7cf8-477f-81e1-857aa62102c2
InstallationDate: Installed on 2014-06-10 (169 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
MachineType: LENOVO 6474B84
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcEnviron:
 LANGUAGE=hu
 TERM=xterm
 PATH=(custom, no user)
 LANG=hu_HU.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic root=/dev/mapper/thinkvg-rootlv ro rootflags=subvol=@
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-25-generic N/A
 linux-backports-modules-3.16.0-25-generic N/A
 linux-firmware 1.138
SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-11-11 (15 days ago)
dmi.bios.date: 04/22/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 7UET66WW (2.16 )
dmi.board.name: 6474B84
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7UET66WW(2.16):bd04/22/2009:svnLENOVO:pn6474B84:pvrThinkPadT400:rvnLENOVO:rn6474B84:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 6474B84
dmi.product.version: ThinkPad T400
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[MegaBrutal (qbu6to)]

I did the BIOS upgrade and nothing has changed.

7UET94WW (3.24 )
10/17/2012

[Christopher M. Penalver (penalvch)]

MegaBrutal, the next step is to fully commit bisect from kernel 3.13 to 3.16 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ? Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[MegaBrutal (qbu6to)]

The first bad commit is
8ab3820fd5b2896d66da7bb2a906bc382e63e7bc x86, kaslr: Return location from decompress_kernel
which introduces KASLR.

The problem only presents itself when CONFIG_RANDOMIZE_BASE=y.

While this bug has been around in the kernel source for quite a time, it was dormant, as this option wasn't enabled in some previous Ubuntu kernel configurations. (This actually caused some headache during the bisection, as I needed to realize that I have to make sure this option is always enabled to get proper test results.)

[Christopher M. Penalver (penalvch)]

MegaBrutal, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

[MegaBrutal (qbu6to)]

I've posted the problem report.

Here are the URLs to track from several mail archives:
http://www.spinics.net/lists/kernel/msg1878907.html
http://marc.info/?l=linux-kernel&m=141741553905446&w=2
https://lkml.org/lkml/2014/12/1/15

[Thomas M Steenholdt (tmus)]

I'm on a virtual machine and experiencing the same thing. The problem seems to be covered pretty well in pages mentioned in #8.

My problem in more detail is trying to kexec the 3.16 kernel provided by linux-generic-lts-utopic in trusty (from original 3.13 kernel, to allow "normal" kernel updates on DigitalOcean).

[MegaBrutal (qbu6to)]

Please try the patch mentioned here:
https://lkml.org/lkml/2014/12/1/790

If it works, it would be nice to tell the authors to get it included in the mainline kernel. I've already told them, but one man is probably not enough.
(I'm not sure if it's included already, and currently I have no time to test.)

[MegaBrutal (qbu6to)]

I've tested the issue with mainline kernel v3.19-rc7-vivid, and it works now!
However, the actual Ubuntu kernel, 3.16.0-30-generic, still has the issue.

[Christopher M. Penalver (penalvch)]

MegaBrutal, the next step is to fully reverse commit bisect from kernel 3.18-rc7 to 3.19-rc7 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

[MegaBrutal (qbu6to)]

The following commit fixes the problem in mainline:

commit f285f4a21c3253887caceed493089ece17579d59
Author: Kees Cook <email address hidden>
Date: Thu Jan 15 16:51:46 2015 -0800

    x86, boot: Skip relocs when load address unchanged

    On 64-bit, relocation is not required unless the load address gets
    changed. Without this, relocations do unexpected things when the kernel
    is above 4G.

    Reported-by: Baoquan He <email address hidden>
    Signed-off-by: Kees Cook <email address hidden>
    Tested-by: Thomas D. <email address hidden>
    Cc: Vivek Goyal <email address hidden>
    Cc: Jan Beulich <email address hidden>
    Cc: Junjie Mao <email address hidden>
    Cc: Andi Kleen <email address hidden>
    Cc: <email address hidden>
    Link: http://<email address hidden>
    Signed-off-by: Thomas Gleixner <email address hidden>

[MegaBrutal (qbu6to)]

Is there anything I can do to get the patch actually backported? Can I somehow backport it myself or something?
Even with the latest Utopic kernel which was published few days ago, I still don't have a kexec-able kernel.
I can imagine the Vivid release will happen earlier than I'll get a patched kernel in Utopic.

[MegaBrutal (qbu6to)]

The issue was fixed with `linux-image-3.16.0-33-generic`, as it finally contains commit f285f4a21c3253887caceed493089ece17579d59.