| Summary: | Updating to kernel 4.14.20+ causes early boot hang on ASUS x205ta (Intel Bay Trail platform) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Martin Whitaker <mageia> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | marja11, tmb |
| Version: | 6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel-4.14.20-1.mga6.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Martin Whitaker
2018-03-12 21:04:46 CET
Marja Van Waes
2018-03-13 18:24:17 CET
CC:
(none) =>
marja11 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 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 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. ok, so that pretty much confirms there are still issues with the 32bit PTI support I thought it showed that one of our additional patches was to blame. 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 (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 :-) 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. Still valid with kernel-desktop-4.14.70-2. kernel-linus-4.14.69-1 still works OK. 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. (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) (In reply to Thomas Backlund from comment #11) > Does kernel-desktop (not 586) work on that ? One ISO build later...yes, that one works. Fixed in kernel-desktop586-4.20.9-1.mga7. Resolution:
(none) =>
FIXED |