Red Hat Bugzilla – Bug 1459912
BIOS CMOS settings spoiled, after restart kernel 4.11. with Intel 7260 bluetooth [8087:07dc] disabled.
Last modified: 2017-08-07 13:40:01 EDT
Created attachment 1286168 [details] Concatenaited dmesg output from kernels 4.10 and 4.11 Description of problem: After update to '4.11.3-200.fc25.x86_64' and loading fedora 25. Next time reboot will be with spoiled CMOS settings. Bios detect this, display 'configuration changed - restart the system' and returns default settings. Last normal kernel 4.10.17-200.fc25.x86_64 Version-Release number of selected component: 4.11.3-200.fc25.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) How reproducible: Steps to Reproduce: 1. Turn on notebook 2. Load fedora 25 with kernel 4.11 3. Restart. 4. Then an next boot time you see 'configuration changed - restart the system' Actual results: All CMOS settings returned to default. Additional info: Notebook - lenovo s540. Load mode - legacy MBR. No EFI. I try fedora vanilla 4.11.4 kernel with same result. Kernel 4.10 all right.
Created attachment 1288273 [details] The output difference 'dmesg' of the both kernels. dmesg -u output_4.10 output_4.11
Please. Does anybody know what a kernel changes can be reason of this behaviour?
I have been trying many kernel acpi parameters. ( acpi_force_32bit_fadt_addr acpi_enforce_resources=lax acpi=copy_dsdt acpi_apic_instance=2 acpi_osi=\"!Linux\" acpi_osi=\"Windows 2012\" pci=realloc=off,nocrs intel_iommu=off intremap=off" acpi=noirq acpica_no_return_repair acpi_no_auto_serialize acpi_enforce_resources=no acpi_no_static_ssdt acpi_force_table_verification" ) I have used the efi fedora26 beta. Fedora-Workstation-Live-x86_64-26_Beta-1.4.iso with kernel 4.11 too. But works without "CMOS reseting" only with acpi=off. :(
Created attachment 1304096 [details] diff-u_output_of_the kernel 4.11.4_good_boot 4.11.4_wrong_boot
My system has two disks. Perhaps after cloning the first disc on the second I forgot to wipe it completely. As a result, maybe, I had two disks with the same signature in the MBR. Now I have created a new MBR with new disk signature on one of the disks. Perhaps the changes in BIOS settings helped, I left the boot up only in normal(legacy) mode without the possibility of UEFI. After, the UEFI possibility was returned without troubles. Now everything works as it should. Sorry for any inconvenience.
Everything works as it should, but after I disable the bluetooth. BIOS can't see the adapter any more, and think that the hardware configuration changed -> Bios Reset CMOS Settings. It happens only with kernels 4.11 and above. Doesn't happen with 4.10. Windows 10 system log has: EVENT 34 BTHUSB The local adapter does not support an important Low Energy controller state to support peripheral mode. The minimum required supported state mask is 0x491f7fffff, got 0x1fffffff. Low Energy peripheral role functionality will not be available.
workaround: Keep the bluetooth always on.
*** This bug has been marked as a duplicate of bug 1479014 ***