Please don't remove cc's - I added them for a reason. On 13 July 2018 at 15:54, youling 257 <youling257@xxxxxxxxx> wrote: > I tried Revert "mm/page_poison.c: make early_page_poison_param() > __init"Revert "mm/kmemleak.c: make kmemleak_boot_config() > __init" Revert "mm/page_owner.c: make early_page_owner_param() > __init" Revert "random: fix crng_ready() test" Revert "x86/efi: Use > efi_switch_mm() rather than manually > twiddling with %cr3" in three days > > not solved my problem ! i only can guess which patch cause my problem，i > still not solved my problem. > OK so if reverting that last patch did not fix your issue, why did you bring it up in the first place? Please, try to use git bisect methodically to narrow down the issue. If you do that, we will be able to help. If you don't, I am afraid there is nothing we can do. > 2018-07-13 21:50 GMT+08:00 Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>: >> >> (+ Sai) >> >> On 13 July 2018 at 13:56, youling 257 <youling257@xxxxxxxxx> wrote: >> > >> > https://github.com/torvalds/linux/commit/03781e40890c18bdea40092355b61431d0073c1d >> > x86_64 kernel and"efi=old_map" disabled because, x86_32 and efi=old_map >> > do >> > not use >> > efi_pgd, rather they use swapper_pg_dir. >> > >> > so what x86_64 kernel and efi=old_map ? >> > >> > https://forums.kali.org/archive/index.php/t-29927.html >> > Seems like the kali's 4.4 kernel doesnt support some (old)hardware >> > maybe? I >> > have an old 32bit toshiba satelite that always hang on reboot when using >> > that kernel version. >> > It goes to bios screen and hangs for like 1-2 min and then a blank >> > screen >> > with a _ blinking. I could then shutoff my computer using the power >> > button. >> > Shutting down is fine though. >> > >> > >> > Been having the same issue where I kept rebooting itself during loading >> > of >> > the kernel and would be a never ending loop of reboots. >> > >> > But I have managed to fix it by editing the grub conf file at >> > /etc/default/grub. Using your fave word editor and on the line >> > >> > GRUB_CMDLINE_LINUX_DEFAULT="quiet " add efi=old_map >> > >> > so the line should look like this roughly >> > >> > GRUB_CMDLINE_LINUX_DEFAULT="quiet efi=old_map" >> > >> >> OK, to let me see if I can summarize this correctly, because I have >> difficulty understanding what you are describing here. >> >> You have a Bay trail system that boots in mixed mode. >> You don't have a toshiba satellite, that is just an example you took >> from the internet. >> >> Your Bay Trail system sometimes fails to boot v4.17 but older kernels are >> fine. >> >> So does reverting the patch 03781e40890c18bdea40092355b61431d0073c1d >> you mention fix the issue? >> >> >> > 2018-07-13 18:12 GMT+08:00 youling 257 <youling257@xxxxxxxxx>: >> >> >> >> I begin to used from 4.17 rc3，the problem make a headache for me two >> >> months. >> >> i can't bisect to find the reason ，problem begin with 4.17，the 4.16 >> >> work >> >> well，4.16.18 also work well. >> >> >> >> 2018-07-13 13:38 GMT+08:00 Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>: >> >>> >> >>> On 13 July 2018 at 03:18, youling 257 <youling257@xxxxxxxxx> wrote: >> >>> > Not thorough fix Bay trail 64 bit kernel on 32 bit uefi. >> >>> > sometimes，can't >> >>> > boot . >> >>> > >> >>> > I tested efi/x86: remove pointless call to PciIo->Attributes() >> >>> > efi/x86: prevent reentrant firmware calls in mixed modeefi/x86: >> >>> > merge >> >>> > setup_efi_pci32 and setup_efi_pci64 routines >> >>> > efi/x86: align efi_uga_draw_protocol typedef names to convention >> >>> > efi/x86: merge 32-bit and 64-bit UGA draw protocol setup routines >> >>> > efi/x86: add missing NULL initialization in UGA draw protocol >> >>> > discovery >> >>> > efi/x86: replace references to efi_early->is64 with efi_is_64bit() >> >>> > >> >>> > please you test me this problem reason，which one 4.17 rc patch cause >> >>> > it， >> >>> > from 4.17 rc3 to 4.18 rc4，sometimes can boot kernel，sometimes can't >> >>> > boot， >> >>> >> >>> So v4.17-rc2 works but v4.17-rc3 doesn't? Can you bisect this window? >> >> >> >> >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
