[HP Compaq 6715s] Updating kernel renders system unbootable

I did some testing using different kernels:

3.19.0-26, no boot.

- ACPI PCC error on screen, disappears after a few seconds
- Black screen, normal fan, no HDD activity
- Ctrl+alt+del doesn't work

3.19.0-42

- ACPI PCC error on screen, disappears after a longer time
- HDD works longer before stopping
- Black screen, normal fan
- Ctrl+alt+del doesn't work

4.2.0-22

- Blinking cursor
- Fan on full speed, no HDD activity
- Black screen
- Ctrl + alt + del doesn't work

What should I do to complete the bug report?

Carl Englund, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
apport-collect 1529381

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Carl Englund, at your earliest convenience, could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

Testing 4.4-rc6 had the difference in result that after the fan went on max speed (unlike when booting on 3.19.0-25) and hdd was working - after a while the blue XUbuntu screen with the spinning wheel came up. After that the screen went black again and hdd stopped.

4.3.3 was same result but without the blue XUbuntu screen.

Tested 3.19.0-23 just to make sure..and yes, it works. Everything I've tested after 3.19.0-25 doesn't.

Carl Englund, the next step is to fully commit bisect from kernel 3.19.0-25 to 3.19.0-42 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.

After the offending commit (not kernel version) has been identified, then please mark this report Status Confirmed.

Thank you for your understanding.

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

Hi! Bisecting stuff is new to me - I'm not sure I did it the right way, but..

..I tested precompiled kernel commits found via a link in the Kernel bisection guide. My results are:

3.19.0-26.27 doesn't boot
3.19.0-25.26 boots normally

Carl Englund, while you have made progress in kernel version bisecting, the commit bisect is missing. As outlined in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1529381/comments/22 finding adjacent kernel versions is not a commit bisect.

I got it! If I didn't mess it up but I don't think so.

Side question: do you have to do "fakeroot debian/rules clean" for every step when bisecting? The guide was a bit unclear on that. I was just thinking the compile process might be quicker if I didn't do clean in between..

19114b5458510b757cd2801e64094e4062e4067f is the first bad commit
commit 19114b5458510b757cd2801e64094e4062e4067f
Author: Lv Zheng <email address hidden>
Date: Wed Jul 1 14:43:34 2015 +0800

    ACPICA: Tables: Enable default 64-bit FADT addresses favor

    BugLink: http://bugs.launchpad.net/bugs/1479048

    commit 0ea61381788a37d864f9841b0fe97d40f7058f3b upstream.

    ACPICA commit 4da56eeae0749dfe8491285c1e1fad48f6efafd8

    The following commit temporarily disables correct 64-bit FADT addresses
    favor during the period the root cause of the bug is not fixed:
     Commit: 85dbd5801f62b66e2aa7826aaefcaebead44c8a6
     ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.

    With enough protections, this patch re-enables 64-bit FADT addresses by
    default. If regressions are reported against such change, this patch should
    be bisected and reverted.
    Note that 64-bit FACS favor and 64-bit firmware waking vector favor are
    excluded by this commit in order not to break OSPMs. Lv Zheng.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
    Link: https://github.com/acpica/acpica/commit/4da56eea
    Reported-and-tested-by: Oswald Buddenhagen <email address hidden>
    Signed-off-by: Lv Zheng <email address hidden>
    Signed-off-by: Bob Moore <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>
    Signed-off-by: Kamal Mostafa <email address hidden>
    Signed-off-by: Luis Henriques <email address hidden>

:040000 040000 0b002dc7d6e5abe0ded978926361d88efd5a0f88 27c36ea102b1622ded7beecbca477f62fa33922a M include

Carl Englund, you should assume everything is required unless precisely stated otherwise.

Despite this, as a final test, could you please test mainline 4.4-rc7 and advise to the results?

Done. 4.4.0-040400rc7 tested:

- Message about loading initrd image or somesuch.
- Screen goes black.
- Fan goes to full speed.
- HD light lit for about 15 seconds or so, then goes dark.

Carl Englund, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate mailing list (TO Lv Zheng, Bob Moore, and Rafael J. Wysocki, CC linux-acpi)?

Please provide a direct URL to your post to the mailing list when it becomes available so that it may be tracked.

Thank you for your understanding.

My post to the developers:

http://marc.info/?l=linux-acpi&m=145186512903943&w=2

Reply:

http://marc.info/?l=linux-acpi&m=145191133113281&w=2

Bug submitted to bugzilla.kernel.org as per developer instructions: https://bugzilla.kernel.org/show_bug.cgi?id=110451

Hi, i have exact same problem on my hp compaq 6715s.

I have prepared a kernel based on Ubuntu-3.19.0-26.27 with just commit 19114b5458510b757cd2801e64094e4062e4067f (see comment #25) reverted. If someone could test that and confirm just the indicated commit reverted is enough to fix this:

    http://people.canonical.com/~apw/lp1529381-vivid/

Please report any testing back here.

Hi, i have exact same problem on my hp compaq 6715s.
Today, i got help from a developer nick-named "apw", who dwells in #ubuntu-kernel channel on Freenode network. He produced a kernel based on 3.19.0-26.27 with just the commit removed and it BOOTED SUCCESSFULLY!
Here's the link of the modified kernel: http://people.canonical.com/~apw/lp1529381-vivid/

So it's highly likely that the 64 bit addresses used for specific PM registers are wrong in the FADT, where as they are correct in the 32 bit addresses.

The FADT supports old 32 bit legacy addressing for PM registers and 64 bit addressing too. Unfortunately sometimes the firmware sets the 64 bit versions incorrectly and the kernel is now using these in preference to the 32 bit variant, hence the issue.

For reference: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 5.2.9 Fixed ACPI Description Table (FADT), see the 32 bit PM registers (PM1a_EVT_BLK etc) and their 64 bit counterparts (X_PM1a_EVT_BLK etc).

You can check if these are sane by running "sudo fwts acpidump - > dump.log"

and then checking if the 32 bit and 64 bit variants of the PM registers are different. The kernel will default to using the 64 bit variants with the faulty patch.

Developers on #ubuntu-kernel helped me a lot to identify the problem, so here's our conversation log:
http://irclogs.ubuntu.com/2016/01/21/%23ubuntu-kernel.html

You should scroll down to my nickname peaceful.

I'm currently working on an override kernel parameter, I hope to get a kernel for you to test later today

I've uploaded some 3.19 kernels (i386, 32 bit), (amd64, 64 bit) to:

http://kernel.ubuntu.com/~cking/lp-1529381/

First, edit /etc/default/grub and change the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

and add "acpi_force_32bit_fadt_addr", e.g.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_force_32bit_fadt_addr"

Then download install the appropriate ones for your machine from http://kernel.ubuntu.com/~cking/lp-1529381

I've tested this out on a virtual machine with a modified BIOS so I believe it should do the trick. Please let me know if it works around the issue. Thanks.

Thanks a lot Colin! My laptop now boots this kernel with "acpi_force_32bit_fadt_addr" override kernel parameter.

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-needed-vivid' to 'verification-done-vivid'.

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://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

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-needed-wily' to 'verification-done-wily'.

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://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Verified on Vivid.

Steps used:

1. Hacked seabios to extend FADT to include 64 bit X_* PM registers which pointed to garbage address
2. Boot vivid QEMU VM with old kernel and modified (broken) BIOS
3. Observe kernel failures
4. Install new kernel (3.19.0.49-generic) #55 (Jan 22)
5. Add acpi_force_32bit_fadt_addr to kernel boot line
6. Reboot
7. Observe no kernel failures.
8. Boot with new kernel and original "sane" seabios BIOS
9. Observe no kernel failures.

Looks good to me on Vivid.

Verified on Wily

Steps used:

1. Hacked seabios to extend FADT to include 64 bit X_* PM registers which pointed to garbage address
2. Boot vivid QEMU VM with old kernel and modified (broken) BIOS
3. Observe kernel failures
4. Install new kernel (4.2.0-27-generic) #32 (Jan 22)
5. Add acpi_force_32bit_fadt_addr to kernel boot line
6. Reboot
7. Observe no kernel failures.
8. Boot with new kernel and original "sane" seabios BIOS
9. Observe no kernel failures.

Looks good to me on Wily too.

I added the "proposed" source and from there installed kernel 3.19.0-46 (using Synaptic). Booted with acpi_force_32bit_fadt_addr and system froze.

I get the feeling this kernel wasn't the one I was supposed to be testing with. Could it be because I am on Trusty? Is the proposed kernel released to be available for me to test? I see the tags about vivid and wily but the problem occurs for Trusty users too.

Also wondering about something Mr. Zheng wrote on the bug on bugzilla.kernel.org:

"What we can offer here is to provide a quirk for your platform to revert the behavior back to favor 32-bit GAS values on this platform before your issue is root caused."

Wouldn't it be nicer to also detect this computer automatically and force 32-bit registers so the boot parameter wouldn't be needed? Many people won't want to bother with boot parameters - they'll just see how Ubuntu doesn't boot on their machines and be disappointed. Or should we wait until the quirk is added upstream?

This bug was fixed in the package linux - 4.4.0-2.16

---------------
linux (4.4.0-2.16) xenial; urgency=low

  [ Andy Whitcroft ]

  * Release Tracking Bug
    - LP: #1539090
  * SAUCE: hv: hv_set_ifconfig -- convert to python3
    - LP: #1506521
  * SAUCE: dm: introduce a target_ioctl op to allow target specific ioctls
    - LP: #1538618

  [ Colin Ian King ]

  * SAUCE: ACPI / tables: Add acpi_force_32bit_fadt_addr option to force 32
    bit FADT addresses (LP: #1529381)
    - LP: #1529381

  [ John Johansen ]

  * SAUCE: (no-up): apparmor: fix for failed mediation of socket that is
    being shutdown
    - LP: #1446906

  [ Mahesh Salgaonkar ]

  * SAUCE: Powernv: Remove the usage of PACAR1 from opal wrappers
    - LP: #1537881
  * SAUCE: powerpc/book3s: Fix TB corruption in guest exit path on HMI
    interrupt.
    - LP: #1537881
  * SAUCE: KVM: PPC: Book3S HV: Fix soft lockups in KVM on HMI for time
    base errors
    - LP: #1537881

  [ Paolo Pisati ]

  * SAUCE: arm64: errata: Add -mpc-relative-literal-loads to erratum
    #843419 build flags
    - LP: #1533009
  * [Config] MFD_TPS65217=y && REGULATOR_TPS65217=y
  * [Config] disable ARCH_ZX (ZTE ZX Soc)

  [ Tim Gardner ]

  * Revert "SAUCE: (noup) cxlflash: a couple off by one bugs"
  * SAUCE: (no-up) Update bnx2x firmware to 7.12.30.0
    - LP: #1536719
  * SAUCE: drop obsolete bnx2x firmware
  * SAUCE: i40e: Silence 'may be used uninitialized' warnings
    - LP: #1536474
  * [Config] CONFIG_ZONE_DMA=y for amd64 lowlatency
    - LP: #1534647
  * [Config] Add pvpanic to virtual flavour
    - LP: #1537923
  * [Config] CONFIG_INTEL_PUNIT_IPC=m, CONFIG_INTEL_TELEMETRY=m
    - LP: #1520457

  [ Upstream Kernel Changes ]

  * i40evf: fix compiler warning of unused variable
    - LP: #1536474
  * intel: i40e: fix confused code
    - LP: #1536474
  * i40e/i40evf: remove unused tunnel parameter
    - LP: #1536474
  * i40e: Change BUG_ON to WARN_ON in service event complete
    - LP: #1536474
  * i40e: remove BUG_ON from feature string building
    - LP: #1536474
  * i40e: remove BUG_ON from FCoE setup
    - LP: #1536474
  * i40e: Workaround fix for mss < 256 issue
    - LP: #1536474
  * i40e/i40evf: Add a stat to track how many times we have to do a force
    WB
    - LP: #1536474
  * i40e: Move the saving of old link info from handle_link_event to
    link_event
    - LP: #1536474
  * i40e/i40evf: Add comment to #endif
    - LP: #1536474
  * i40e/i40evf: clean up error messages
    - LP: #1536474
  * i40evf: handle many MAC filters correctly
    - LP: #1536474
  * i40e: return the number of enabled queues for ETHTOOL_GRXRINGS
    - LP: #1536474
  * i40e: rework the functions to configure RSS with similar parameters
    - LP: #1536474
  * i40e: create a generic configure rss function
    - LP: #1536474
  * i40e: Bump version to 1.4.2
    - LP: #1536474
  * i40e: add new fields to store user configuration
    - LP: #1536474
  * i40e: rename rss_size to alloc_rss_size in i40e_pf
    - LP: #1536474
  * i40e/i40evf: Fix RS bit update in Tx path and disable force WB
    workaround
    - LP: #1536474
  * i40e/i40evf: prefetch skb data on transmit
    - LP: #1536474
  * i40evf: rename VF adapter s...

This bug was fixed in the package linux - 3.19.0-49.55

---------------
linux (3.19.0-49.55) vivid; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1536775

  [ Colin Ian King ]

  * SAUCE: (no-up) ACPI / tables: Add acpi_force_32bit_fadt_addr option to
    force 32 bit FADT addresses
    - LP: #1529381

  [ Tim Gardner ]

  * [Config] Add DRM ast driver to udeb installer image
    - LP: #1514711
  * SAUCE: (no-up) Revert "[SCSI] libiscsi: Reduce locking contention in
    fast path"
    - LP: #1517142

  [ Upstream Kernel Changes ]

  * powerpc/eeh: Fix recursive fenced PHB on Broadcom shiner adapter
    - LP: #1532942
  * Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors
    - LP: #1440103
  * Drivers: hv: vmbus: teardown hv_vmbus_con workqueue and
    vmbus_connection pages on shutdown
    - LP: #1440103
  * drivers: hv: vmbus: Teardown synthetic interrupt controllers on module
    unload
    - LP: #1440103
  * clockevents: export clockevents_unbind_device instead of
    clockevents_unbind
    - LP: #1440103
  * Drivers: hv: vmbus: Teardown clockevent devices on module unload
    - LP: #1440103
  * Drivers: hv: vmbus: Add support for VMBus panic notifier handler
    - LP: #1440103
  * hv: run non-blocking message handlers in the dispatch tasklet
    - LP: #1440103
  * Drivers: hv: vmbus: unregister panic notifier on module unload
    - LP: #1440103
  * Drivers: hv: vmbus: Implement the protocol for tearing down vmbus state
    - LP: #1440103
  * kexec: define kexec_in_progress in !CONFIG_KEXEC case
    - LP: #1440103
  * Drivers: hv: vmbus: add special kexec handler
    - LP: #1440103
  * Drivers: hv: don't do hypercalls when hypercall_page is NULL
    - LP: #1440103
  * Drivers: hv: vmbus: add special crash handler
    - LP: #1440103
  * Drivers: hv: vmbus: prefer 'die' notification chain to 'panic'
    - LP: #1440103
  * hyperv: Implement netvsc_get_channels() ethool op
    - LP: #1494423
  * hv_netvsc: Properly size the vrss queues
    - LP: #1494423
  * hv_netvsc: Allocate the sendbuf in a NUMA aware way
    - LP: #1494423
  * hv_netvsc: Allocate the receive buffer from the correct NUMA node
    - LP: #1494423
  * Drivers: hv: vmbus: Implement NUMA aware CPU affinity for channels
    - LP: #1494423
  * Drivers: hv: vmbus: Allocate ring buffer memory in NUMA aware fashion
    - LP: #1494423
  * Drivers: hv: vmbus: Improve the CPU affiliation for channels
    - LP: #1494423
  * Drivers: hv: vmbus: Further improve CPU affiliation logic
    - LP: #1494423

linux (3.19.0-48.54) vivid; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1536124
  * Merged back Ubuntu-3.19.0-46.52

 -- Brad Figg <email address hidden> Thu, 21 Jan 2016 12:29:48 -0800

This bug was fixed in the package linux - 4.2.0-27.32

---------------
linux (4.2.0-27.32) wily; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1536867

  [ Andy Whitcroft ]

  * SAUCE: (no-up) add compat_uts_machine= kernel command line override
    - LP: #1520627

  [ Colin Ian King ]

  * SAUCE: (no-up) ACPI / tables: Add acpi_force_32bit_fadt_addr option to
    force 32 bit FADT addresses
    - LP: #1529381

  [ Eric Dumazet ]

  * SAUCE: (no-up) udp: properly support MSG_PEEK with truncated buffers
    - LP: #1527902

  [ Guilherme G. Piccoli ]

  * SAUCE: powerpc/eeh: Validate arch in eeh_add_device_early()
    - LP: #1486180

  [ Tim Gardner ]

  * SAUCE: (no-up) Revert "[SCSI] libiscsi: Reduce locking contention in
    fast path"
    - LP: #1517142
  * [Config] Add DRM ast driver to udeb installer image
    - LP: #1514711

  [ Upstream Kernel Changes ]

  * net/mlx5e: Re-eanble client vlan TX acceleration
    - LP: #1533249
  * net/mlx5e: Fix LSO vlan insertion
    - LP: #1533249
  * net/mlx5e: Fix inline header size calculation
    - LP: #1533249
  * net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card
    - LP: #1533118
  * net: usb: cdc_ncm: Adding Dell DW5813 LTE AT&T Mobile Broadband Card
    - LP: #1533118
  * powerpc/eeh: Fix recursive fenced PHB on Broadcom shiner adapter
    - LP: #1532942

linux (4.2.0-26.31) wily; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1535795
  * Merged back Ubuntu-4.2.0-25.30

 -- Brad Figg <email address hidden> Thu, 21 Jan 2016 18:44:37 -0800

This fix recently landed in linux-next, abef9ca9ff7dacb77603b2c0976e29423efded39 so should be supported in forth coming kernel releases (4.6+)