From nobody Mon Aug 30 05:28:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8ED841799B16 for ; Mon, 30 Aug 2021 05:28:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gyf4232l8z3Dwh for ; Mon, 30 Aug 2021 05:28:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe32.google.com with SMTP id b5so9608656vsq.2 for ; Sun, 29 Aug 2021 22:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BJv8eTt0CNqG6BBdBB6Y0XFQOQDxjnqorRYZh8AQU6Y=; b=YKz8jeeM/hPePuBrvi5krjJGD/jSMf4Z0vuVVPnWUovMlpqpeT1g1ihqZGu7SPoWIo g5wCY0dmd5jc1sg7ulbAwoQ1ReZCPHlRyhymndxXiH2vITpltoBkkP9u9InKv2C20cRt jvb0IbPW67gtRLRbv4epGpaxGVmNdia2B03g1/vTBuC7MIntPI1dTqu0hVpCAAWVq2Xy +LEnWOo4yBaPu6GorCCHttOlnqyJCucO5Rcn7qoIm4q3+KXtY7oJ1BnzQDA/1Whf/cM4 PwyFqHUEpC8a+k2k7ELPljOF8F05Xck2NKKxbeeD4TIBOU35wx3cLTGAUvhQGc8v3H4z HNrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BJv8eTt0CNqG6BBdBB6Y0XFQOQDxjnqorRYZh8AQU6Y=; b=BXpqCNbpLleVzdTi5urchGkqNmt06OhhWq4qEyaT+5IRpvF0GMGZ75ziJFAaGsSX4U kVK3fKLSA830Ndkzzkqp58gQtVhHOGgrAOhdTj3o7fq3PpGVP+D2SmIfWylk6BALUsYT jtRq5SyIGy0P8y1SaP+9rAnIUgdZhqqmom7CUQTgmKylMPFGcaQHjHyTpi1UZM7tHP/j 37307/bhin+WFkOnKceLnU8NscYlOQP3GSv5gQuGIzzLZ5ggLlkoLxOW+x5rbQ58dmfH HCpXZreJBBam/BaFdwBJyU5rTshRzl3rk+Zm39Emo8H6VKFzg6FhOmhsIBIR5999juud zz3g== X-Gm-Message-State: AOAM533adegpusbZRTA2+jCr1/7mPHkZ+bK4v7lZA9Y8h0p9Q+49vi3e 9Ut4SIkiJs7yYxWKGGllKl2tDGUhQsqw1nbZxFNYYr4QL+2Bof4O X-Google-Smtp-Source: ABdhPJwhAtPB1BvhD9o9ZqbapTMgasemJx7VGfRTq6DrHUX67a6QNPhcBVuKaZw80Wggg15XhuIoGoFXu2+dUv8iQ5A= X-Received: by 2002:a05:6102:5a:: with SMTP id k26mr8165108vsp.26.1630301292478; Sun, 29 Aug 2021 22:28:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 29 Aug 2021 23:28:01 -0600 Message-ID: Subject: Re: New loader_lua.efi causes kernels to hang at boot To: Dustin Marquess Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000006a578705cac019fb" X-Rspamd-Queue-Id: 4Gyf4232l8z3Dwh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000006a578705cac019fb Content-Type: text/plain; charset="UTF-8" On Sun, Aug 29, 2021 at 7:28 PM Dustin Marquess wrote: > I am upgrading a -CURRENT box from a build that's exactly 2 weeks old to > one I built about 2 hours ago. After installkernel I updated the bootloader > the same way I normally do: > > # mount_msdosfs /dev/da8p1 /mnt > # cp /mnt/EFI/BOOT/BOOTX64.efi /mnt/EFI/BOOT/BOOTX64.bak > # cp loader_lua.efi /mnt/EFI/BOOT/BOOTX64.efi > # umount /mnt > > After rebooting, however, the kernel hangs right after: > > real memory = 137438953472 (131072 MB) > avail memory = 133651951616 (127460 MB) > ACPI APIC Table: > > It never makes it to this line: > > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > > So I rebooted a selected kernel.old at the boot menu and.. same thing. > That's strange! > > So I booted off a USB stick, mounted the EFI partition and copied > BOOTX64.bak back to BOOTX64.efi and now the machine booted normally. > > So for some reason the newer loader_lua.efi is causing both the new kernel > AND the old kernel to hang, but the older loader_lua.efi seems to work with > both no problem. > > Any ideas? > Can you bisect where this starts to happen? Have you set EFI_STAGING_SIZE in your src.conf or similar file? The following commits have been made to stand that likely affect this: commit b54eec8366605d9c2303277cf2ab4b605289910a Author: Konstantin Belousov CommitDate: Fri Aug 27 19:49:01 2021 +0300 efi loader: disallow user to configure staging area size less than default commit b850806921a735f3f307bc4b2634c7e9008f5a9c Author: Konstantin Belousov CommitDate: Fri Aug 27 19:48:53 2021 +0300 Restore the definition of EFI_STAGING_SIZE commit 6032b6ba9596927aba15a8004ade521a593a7d58 Author: Konstantin Belousov CommitDate: Wed Aug 25 22:26:52 2021 +0300 amd64 UEFI loader: enable automatic disable of staging area copying commit 0d13f5343fafbf3067ffc33a507ffca0375c4417 Author: Maxim Sobolev CommitDate: Fri Aug 20 14:08:01 2021 -0700 Only trigger read-ahead if two adjacent blocks have been requested. You can rebuild "stand" independently of the system, so it should be relatively straightforward to build a new loader_lua.efi that steps back across these (and the other ones that I'm pretty sure are super-low risk for this use case). You can also use efibootmgr to setup a temporary boot variable to ease testing, or just boot a known good one off a USB stick. Warner --0000000000006a578705cac019fb--