From nobody Tue Nov 21 03:33:29 2023 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 4SZ92b6Hxjz51fjW for ; Tue, 21 Nov 2023 03:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZ92b4S8Rz3R7X for ; Tue, 21 Nov 2023 03:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-5098e423ba2so7122094e87.2 for ; Mon, 20 Nov 2023 19:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700537620; x=1701142420; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BotDw3yRO3dcMRFaD3UZxnOVZecWLTOEColpPfvQcjA=; b=kq/DdG1vdKiRWehSqSdyWnaelDhxZIwRxRCH28BxtJcwghT3fGrGrz/EPpB9GHjL1b suCAweVtVPBLzfLzRGwIpCy9gH5JMSH02vC4Jf5YyYvJZu5Qu5TwgTvK4r16/q4EeFta 9km2718m6sk7CIbSfCIJpYOUu9i8/gXUHONyP5GQgZcxubDY0JJYpjENTIWY/86qmtJq x36dLKhWpiA6g4HOefmX0RgnLrGY3P3eYu45qwV65eg4FJdk58m/GHe335/YfReING/X Zq1e+6QPd/mJW9yMfWHTixLauAc/F7VxuTw5dhHkUEJIpx7dvBSMtUZJd2ObzgjACJjX 6w1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700537620; x=1701142420; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BotDw3yRO3dcMRFaD3UZxnOVZecWLTOEColpPfvQcjA=; b=SQGZeKnt7r52yEV8WWKXk9WpmOygYPVo7Dv/DdWmr0VZ9iYlu7rliCv12k3JYW/rmu /fAudm7C5mBYUxD7D5T2J03pgUqsmNpSwAR3nuL+qBcvzEgasjmpCNTOzhwR/VaFnYgo uz3ieMqRxVX3Kjk9cbhO873ITNTz16+A7ziPXSQ56GRwi8RCzmcnr0YNQChwYMxIJmkg JPt/ya6OAsDNyY4vafhh8Mzesfudk53ep7DIqJjVubITxVGCRPM4IFsfVO5ivfxq8eqm 3Z7CSeG5wx2nuZqYLg4o9HZ9baO/KTKcgfwl6JhfNv1HxENtO5phTlPNcLrnVA4tTnHf zYAw== X-Gm-Message-State: AOJu0YzyIrUpMwvbcfofXT4/DO5ypFF1QoW5S0aVhZRvV1OtrA4Xx01U LsBF6JBbsWktOo3UuyQq9hmd+KyXaWUT5fr2Ajj2ePTKIY7n+0GGWR4= X-Google-Smtp-Source: AGHT+IEhivOWUMm1qqRnowgdr5fanSzBOsjwPS9iEYWZ65QqTfXe8lt9NWlJI6SqTnUtJkErivpXwVBAtWM0gUrgJU0= X-Received: by 2002:ac2:434a:0:b0:509:39e3:5268 with SMTP id o10-20020ac2434a000000b0050939e35268mr5000282lfl.59.1700537620290; Mon, 20 Nov 2023 19:33:40 -0800 (PST) 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: Mon, 20 Nov 2023 20:33:29 -0700 Message-ID: Subject: Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3 To: d@delphij.net Cc: freebsd-current@freebsd.org, rcm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c8fccd060aa144fd" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SZ92b4S8Rz3R7X --000000000000c8fccd060aa144fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 6:21=E2=80=AFPM Xin Li wrote: > Hi, > > It seems that the recent improvements of ACPI detection (e0f3dc82727f > and 0b01d45783c3) would leave the system in an unbootable state if the > UEFI files are not being updated at the same time of "make > installworld". At early boot the kernel would panic with: > > panic: running without device atpic requires a local APIC on UEFI systems > > To recover a system in this state, at loader prompt, use: > > unset hint.acpi.0.disabled > boot > > (I think core.lua should be modified to be compatible with an older UEFI > payload, possibly issuing a warning that gets logged; and this should be > mentioned in UPDATING) > I just pushed https://cgit.freebsd.org/src/commit/?id=3Df213da893ca8c7c76e1656b36d3a10f93= f9a1760 which should fix the issue for x86, with an UPDATING entry for aarch64. This is at best a stop-gap kludge. The real solution would be for loader.efi to publish a list of interfaces it implements and then the lua code can cope with old/new better. Warner --000000000000c8fccd060aa144fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 20, 2023 at 6:21=E2=80=AF= PM Xin Li <delphij@delphij.net> wrote:
Hi,=

It seems that the recent improvements of ACPI detection (e0f3dc82727f
and 0b01d45783c3) would leave the system in an unbootable state if the
UEFI files are not being updated at the same time of "make
installworld".=C2=A0 At early boot the kernel would panic with:

panic: running without device atpic requires a local APIC on UEFI systems
To recover a system in this state, at loader prompt, use:

unset hint.acpi.0.disabled
boot

(I think core.lua should be modified to be compatible with an older UEFI payload, possibly issuing a warning that gets logged; and this should be mentioned in UPDATING)

I just pushed=C2= =A0https://cgit.freebsd.org/src/commit/?id=3Df213da893c= a8c7c76e1656b36d3a10f93f9a1760 which should fix the issue for x86, with= an UPDATING entry for aarch64.

This is at best a = stop-gap kludge. The real solution would be for loader.efi to publish a lis= t of interfaces it implements and then the lua code can cope with old/new b= etter.

Warner=C2=A0
--000000000000c8fccd060aa144fd--