Bug 22756 - Updating to kernel 4.14.20+ causes early boot hang on ASUS x205ta (Intel Bay Trail platform)
Summary: Updating to kernel 4.14.20+ causes early boot hang on ASUS x205ta (Intel Bay ...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-12 21:04 CET by Martin Whitaker
Modified: 2019-02-16 14:03 CET (History)
2 users (show)

See Also:
Source RPM: kernel-4.14.20-1.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Martin Whitaker 2018-03-12 21:04:46 CET
The last message displayed before the hang is either

  Btrfs loaded, crc32c=crc32c-generic

or

  Write protecting the kernel read-only data: 3076k

so I suspect the problem occurs when starting dracut.

This machine has a 32-bit UEFI BIOS, which I realise isn't officially supported, but it works fine with kernel 4.14.10 through to 4.4.18. I'm using the 32-bit desktop586 kernel, but the 32-bit desktop kernel gives the same result. I've tested both 4.14.20 and 4.14.25.

lscpidrake gives:

lpc_ich         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Power Control Unit [BRIDGE_ISA] (rev: 0f)
xhci_pci        : Intel Corporation|Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI [SERIAL_USB] (rev: 0f)
Card:Intel 810 and later: Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Graphics & Display [DISPLAY_VGA] (rev: 0f)
mei_txe         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [CRYPT_OTHER] (rev: 0f)
unknown         : Intel Corporation|Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [BRIDGE_HOST] (rev: 0f)
hub             : Linux 4.14.18-desktop586-1.mga6 xhci-hcd|xHCI Host Controller [Hub|Unused|Full speed (or root) hub]
uvcvideo        : Chicony Electronics Co., Ltd|USB2.0 VGA UVC WebCam [Video|Video Control]
hub             : Genesys Logic, Inc.|USB2.0 Hub [Hub|Unused|TT per port]
usbhid          : Logitech|USB Receiver [Human Interface Device|Boot Interface Subclass|Keyboard]
hub             : Linux 4.14.18-desktop586-1.mga6 xhci-hcd|xHCI Host Controller [Hub|Unused|Full speed (or root) hub]
hid_asus        : PDEC3393:00 0B05:8585
hid_generic     : Logitech USB Receiver
hid_generic     : Logitech USB Receiver

The CPU is

vendor_id	: GenuineIntel
cpu family	: 6
model		: 55
model name	: Intel(R) Atom(TM) CPU  Z3735F @ 1.33GHz
stepping	: 8
microcode	: 0x829
Marja Van Waes 2018-03-13 18:24:17 CET

CC: (none) => marja11
Assignee: bugsquad => kernel

Comment 1 Thomas Backlund 2018-03-13 20:21:45 CET
The 32bit efi stuff should technically not matter...

but it might be a fallout of the 32bit PTI support for Meltdown protection.

does it help if you boot with "nopti" added on kernel command line ?

CC: (none) => tmb

Comment 2 Thomas Backlund 2018-03-13 20:29:34 CET
Also, please try with kernel-linus 4.14.25 that is in testing...

That should show if its one of our additional kernel patches causing it, or if its an upstream regression
Comment 3 Martin Whitaker 2018-03-13 20:46:28 CET
nopti enables both 4.14.20 and 4.14.25 desktop586 kernels to boot to a working desktop. kernel-linus 4.14.25 boots without that option.
Comment 4 Thomas Backlund 2018-03-13 20:49:17 CET
ok, so that pretty much confirms there are still issues with the 32bit PTI support
Comment 5 Martin Whitaker 2018-03-13 20:53:04 CET
I thought it showed that one of our additional patches was to blame.
Comment 6 Thomas Backlund 2018-03-13 21:01:32 CET
Yeah, it does :)

The 32bit PTI support is not merged upstream yet, but since revision 1, 2 and 3 all passed some heavy tests upstream I decided to add it to our kernels beginning with 4.14.20 ...

(4.14.20 has rev2, 4.14.25 have rev3)

And you are the first to report problem with the 32bit kernels...


If you like to play with the setup, you could with some customized install a 64bit system, but with 32bit efi bootloader

(or technically you could install a 64bit kernel on that 32bit install and that should hopefully work too as long as you dont need stuff like ipsec vpn
Comment 7 Martin Whitaker 2018-03-14 09:57:53 CET
(In reply to Thomas Backlund from comment #6)
> If you like to play with the setup, you could with some customized install a
> 64bit system, but with 32bit efi bootloader

We started with this when I was helping Lewis get it working on his friend's machine. It works fine, but needs manual intervention to install the bootloader. If we wanted to make this generally available, we'd need to add a 32-bit grub2-efi package to the 64-bit repo (and make drakboot aware of it). Could be done, but that adds more combinations to test...

nopti will do me for now :-)
Comment 8 Martin Whitaker 2018-03-14 22:33:20 CET
I had a play with the 64-bit options. rpm won't let me install the 64-bit kernel in a 32-bit system, telling me the RPM is for an incompatible architecture. So I did a full 64-bit install, added the necessary files from the 32-bit grub2-efi package, and updated to the 4.14.25 desktop kernel. No problems on reboot, without adding any extra boot options. So looks like the problem is specific to the 32-bit PTI fixes.
Comment 9 Martin Whitaker 2018-10-14 10:17:08 CEST
Still valid with kernel-desktop-4.14.70-2. kernel-linus-4.14.69-1 still works OK.
Comment 10 Martin Whitaker 2018-11-22 19:42:51 CET
Even worse with kernel-desktop586-4.19.3-1.mga7 - black screen and no life as soon as you select the entry in the GRUB2 menu.

Looks like the only way to support this class of hardware is to add 32-bit UEFI support to the 64-bit ISOs.
Comment 11 Thomas Backlund 2018-11-22 19:47:55 CET
(In reply to Martin Whitaker from comment #10)
> Even worse with kernel-desktop586-4.19.3-1.mga7 - black screen and no life
> as soon as you select the entry in the GRUB2 menu.
> 

Does kernel-desktop (not 586) work on that ?

> Looks like the only way to support this class of hardware is to add 32-bit
> UEFI support to the 64-bit ISOs.

Yeah, the baytrail hw should never have been released in the form it was :/
Way too much broken stuff (even on MS side where I have had to fight at $dayjob)
Comment 12 Martin Whitaker 2018-11-22 20:48:12 CET
(In reply to Thomas Backlund from comment #11)
> Does kernel-desktop (not 586) work on that ?

One ISO build later...yes, that one works.
Comment 13 Martin Whitaker 2019-02-16 14:03:56 CET
Fixed in kernel-desktop586-4.20.9-1.mga7.

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.