From nobody Sun Oct 6 21:07:38 2024 X-Original-To: freebsd-stable@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 4XMFHD25fBz5YXtk for ; Sun, 06 Oct 2024 21:07:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XMFHD1YR5z4sWd for ; Sun, 6 Oct 2024 21:07:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2e082f2a427so2729773a91.3 for ; Sun, 06 Oct 2024 14:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728248871; x=1728853671; 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=76EPMLFg137hP+dEyrCAQY2R/lfrzXIhBmsJjSVXu44=; b=Fd1Gpaq5tEvXDvB40IBrpnC9gtHQHlzq0+1cGhB9/OCzHa9u99a7UHk59Q8L/obX6V 9EKkkQYxG6n3dJVv3M2b2msZHWu0Yy0m+4hQC6tOI1O0vr3GTNesxZM3H7TStDxvTfyr HFO1IzHPrmM4m4W2i133NjdHHJ5QgSr603mV65fSZV47gkatzJ7cJqBD0sVy4eAYXXpP cR5iBiBUPw6gA9njl2ugM/P/9D798EEMW6NpU2AHvOwzOy9lG9vmzwsqPDKuMxiFwsR/ GLPwSBxMl8OXQsIY4NQvJkrPes47QSQoeLx1vU+UjWIZvtnFmgCH8V6XqjanmfbaX+76 sAqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728248871; x=1728853671; 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=76EPMLFg137hP+dEyrCAQY2R/lfrzXIhBmsJjSVXu44=; b=umQaA9weZRmzmHH/jeulwrpe9LG1oCfPxmP50IArSE9YdeRg4JsQ1vByh4wZQAVh6J 6lVajTSqmhLQ7hV/4Qdd2Dy5nn5rTweboDkXPhHN3pgpw/fAcBwB35+7qkoxKLeK3mH6 a536+ckG/R2frJa38+ISIvTmv4UPobpImrZs7uQpZ3be+AePmA95WA+iQMFZ5SeghAY6 pWkX3CYB0+bXWPSwGWXgRYqDH4FqOa7Ph8eIrBTGWTQ2eE7XZDI0lX8nXI3xxyGb5evx MUY75uwyn3PKi+7V8aulNftOglejQA7JcGuyxTui8pxm2ScyZaWN+5ftpveFW+L5QBkO +xZg== X-Gm-Message-State: AOJu0YxH2sIUqw8vhKDKKpRmpDh3+zpJMoIGpVVuOOLx8YxeUwhgR5sg hccASpVDM3gzN6jQoq51J9XPsQqRQy/Lkae7HvTuBZ2eEJXbp+4K6QRY3lZMzW0JGZ5JVujacF+ Cm0VxUU50Vgg55gS7MtLsZx56eOGc/h5c8vQX/g== X-Google-Smtp-Source: AGHT+IExK4m8uQTHcjKBJTE58i/DI71IQe7/Jpm5N9PwKInKJrOqxEEuLUNVbL5vUtIvhiZNLjdSM4N3kj540UXm7YE= X-Received: by 2002:a17:90b:4ac4:b0:2d8:d58b:52c8 with SMTP id 98e67ed59e1d1-2e1e629ccffmr12967257a91.19.1728248870617; Sun, 06 Oct 2024 14:07:50 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Oct 2024 15:07:38 -0600 Message-ID: Subject: Re: APU1 bricked on stable/14 - solved To: Stefan Hegnauer Cc: FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="00000000000004750f0623d54c89" 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XMFHD1YR5z4sWd X-Spamd-Bar: ---- --00000000000004750f0623d54c89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 6, 2024, 1:14=E2=80=AFPM Stefan Hegnauer wrote: > On 06.10.2024 15:47, Warner Losh wrote: > > > > On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer > wrote: > >> I have a few pc-engines APU1 appliances running in headless mode under >> Nanobsd. Maintenance is by means of direct COM port connection. >> After a recent update a few weeks back I was not able to connect by COM >> port anymore - console output and input went away after booting and >> before single- or multi-user mode would start. Even re-flashing the >> SDcard with a fresh image did not help. >> >> After some longish trials and errors it turned out that both >> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to >> "acpi"' as well as >> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings >> on x86' >> broke things for me. Restoring hints and setting >> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restore= d >> working order. >> >> I agree that APU1 is EOL, however I would have expected an entry to >> UPDATING for such a POLA violation. >> > > Likely, but really really old gear like this is going to hit edge cases > that > developers haven't seen. The hint thing wasn't though to actually > negatively > affect any deployed hardware since it dealt with details that changed 15 = or > 20 years ago... > > Looks like the APU1 used coreboot which at the time was trailing adaptati= on > of ACPI, so it makes sense... I knew that Soekris boxes had issues, but > they > are another 5 or 10 years older than the APUs and mine sadly isn't > operational. > > So I can write a better UPDATING entry, can you share with me the dmesg > from both APU1 and APU2? > > Warner > > >> Note that pc-engines APU2 models are not affected as the BIOS ACPI >> tables contain correct UART descriptions. >> >> - Stefan >> >> Warner: thanks for the quick reply. Not so really, really old in my view > - the BIOS is from ~August 2022 (APU1). And yes, it uses coreboot: > PC Engines apu1 > coreboot build 20220822 > BIOS version v4.17.0.3 > SeaBIOS (version rel-1.16.0.1-0-g77603a32) > Yea. ACPI started being reliable in the early 2000s, +/-. Nearly everything sonce 2010 has provided it.... Here's clearly an exception that needs special care so we can make newer hw more reliable... My comments are more to explain the regression not to try to assign blame on the hardware.. >From verbose boot, dmesg -a: > - APU1, original/faulty from today: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.txt > - APU1, fixed in loader.conf.local: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.t= xt > - APU2 (has no problems): > https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt > Thanks. I think between the two I know what to write. Warner > Let me know if you need additional information. > > - Stefan > --00000000000004750f0623d54c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 6, 2024, 1:14=E2=80=AFPM Stefan Hegnauer &= lt;stefan.hegnauer@gmx.ch>= wrote:
=20 =20 =20
On 06.10.2024 15:47, Warner Losh wrote:
=20


On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <s= tefan.hegnauer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.
After some longish trials and errors it turned out that both
- commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.
I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hi= nt thing wasn't though to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.
- Stefan
Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot:
=C2=A0=C2=A0=C2=A0 PC Engines apu1
=C2=A0=C2=A0=C2=A0 coreboot build 20220822
=C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3
=C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32)

Yea. ACPI started being reliable in the early 2000s, +/-. Nearly every= thing sonce 2010 has provided it....=C2=A0 Here's clearly an exception = that needs special care so we can make newer hw more reliable... My comment= s are more to explain the regression not to try to assign blame on the hard= ware..

From verbose boot, dmesg -a:
- APU1, original/faulty from today:=C2=A0https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb= _v4_17_0_3_std.txt
- APU1, fixed in loader.conf.local:=C2=A0https://hegnauer.selfhost.eu/web/computing/apu1c4_3md= eb_v4_17_0_3_fixed.txt
- APU2 (has no problems): https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt<= /font>

Thanks. I think between the two I know what to write.

Warner=C2=A0


Let me know if you need additional information.

- Stefan
--00000000000004750f0623d54c89--