From nobody Sun Oct 06 19:39:12 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 4XMCKM51ygz5YSg3 for ; Sun, 06 Oct 2024 19:39:35 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XMCKL2xNHz4bn8 for ; Sun, 6 Oct 2024 19:39:34 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.ch header.s=s31663417 header.b=mpf9Gl63; spf=pass (mx1.freebsd.org: domain of stefan.hegnauer@gmx.ch designates 212.227.15.19 as permitted sender) smtp.mailfrom=stefan.hegnauer@gmx.ch; dmarc=pass (policy=quarantine) header.from=gmx.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.ch; s=s31663417; t=1728243571; x=1728848371; i=stefan.hegnauer@gmx.ch; bh=+h0DecMvIHUdBA4vJGlHY+B3k3nSX+g+oi0cED+d6Lo=; h=X-UI-Sender-Class:Content-Type:Message-ID:Date:MIME-Version: Subject:From:To:Cc:References:In-Reply-To:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=mpf9Gl63r6D7rw6U3MoIlW9aWNcjQUPNNk+8e7gegUdop5Z6Kop64NKjZrHDcRfu LloL607ydawAtnaN6lR2F85vb9NrJvK92Bzf844nD302QbbdyWFgle7qHaYr54hJn O8qsGSkjC7PxeSJsJ/0mRGnv5x51gHDJTWgnQwlsAHVdbVAbOQsImd2jIg5Nm8L0+ cmwPWpcPIDk7u8pB2T1QOe/kaNnSVSE3PyVjFyk4AhCgdQYixLe1TVKZu57Uf6D7+ bBNLc6CPFzcm8/yHSlAUtVnJKxNUdm0RrYShzLDQ/vTdgAGy1uxyoIuZPqrjV+rg0 7OZiGf2/xmFmSCyqjA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.20.55] ([84.73.192.40]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MfpOd-1tdUcc1b0D-00cG2c; Sun, 06 Oct 2024 21:39:31 +0200 Content-Type: multipart/alternative; boundary="------------7T2SWUvVFJJ1WVFzx0ond7Se" Message-ID: Date: Sun, 6 Oct 2024 21:39:12 +0200 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 User-Agent: Betterbird (Windows) Subject: Re: APU1 bricked on stable/14 - solved From: Stefan Hegnauer To: Warner Losh Cc: freebsd-stable@freebsd.org References: Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:bo/xikJB/4eD1pvbQy7XzwNFzSzYqqc8jxFWKWvp+8tbVe4KU95 4HwYnnoMjWsymVQs7XUSVVenv9MspSQRF24pHqG/c0izOkPXCMlmqo9NhMRI95wdWWBztzT rpMzH1FB/G44TcdpsV2Nj+NF+UQA6SIjiaF5L6Fr8fOWM6KNqEYZAJw1KmqEjtzUlY0pGu3 B9RY1lufBMHVx5aAL0MAQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Wscr0rtyzj4=;beaQWT3p9mRxFQprEJU2v9Oz0L/ HKY1ZiJcy5wNt1c5Ghe27LV5AadkAruhx9W3cq51BHzFMJtBoyHkcT+4hS8yWVpPWBNRQh344 QRF2fR5iCzCPpQfljQhquyAEOU8bG2mgW2kDce7xVyUU5tCN179j+jXyAl1F87OU/OSzgQMxB IiOU0wwwX41zN5l5MIZh1unFqVpNdz0AyFBuvNNRu9+lfsKa5BHweWqz834iC8a2kzK5axvI0 KNDV3t5SxObM5m2q0MfABrrLPj0FABIAZGlwvP0T/sJ1B4EdTQIrgsE8CtrV2/ktvVCSFSiqd P6vZJU6GLMJE196h/oeujblLjfI96p7KiStdZoBm+USbvLrWAt+EeDD+QF/w7x0pq+rnOIIx/ /Y4i0RD2PNK4hGMQWeUJ/32cxQA0QttLgHHPe/POsx6fX9x5kvQzy4CypnEVsARC1NojoHqey m/Xq4Nhnx1MNSB9XY0DJdkE1x/12qAizUY5576u7xz7UUy4GMd8GchOBj2PPIfC/ZUm1bypOg 9YEGKN63KS2T/wIAcBLZCktCORiAdAWSq5CguSL5OrXxZIWGW5Y9UjC+n4gI7rZaDxbBHpB1f 3XBDupvEW/b9sR8zUu28HPdOiIqq0lIwrrXzmm2eEFtB1a7et3oRuSpDpNp3/tg80/fIxLlGF d0lIRdTX7YHc4qnw+VQwnAgNJxK7LWxIzt8dfdAGZmav8aJ/J1wuXwmTBpwBQrTr3QsuUtxcG 3o8dwkY7rshLWRbHzXrtsmkWpkRc0N7XX29/SyUaw1yHQbzYVl5lANftULmcTuvVTjj2CBHji g13SJO974XTl3uDlD3qP5FehlQnzzqYevhiE2VuMr2CdI= X-Spamd-Result: default: False [-3.87 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.879]; DMARC_POLICY_ALLOW(-0.50)[gmx.ch,quarantine]; R_SPF_ALLOW(-0.20)[+a:mout.gmx.net]; R_DKIM_ALLOW(-0.20)[gmx.ch:s=s31663417]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.ch:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmx.ch]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[gmx.ch] X-Rspamd-Queue-Id: 4XMCKL2xNHz4bn8 X-Spamd-Bar: --- This is a multi-part message in MIME format. --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 06.10.2024 21:14, 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=C2=A0 direct COM port connectio= n. >> 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 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 >> 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 >> >> 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 coreb= oot: > =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) > > From verbose boot, dmesg -a: > - APU1, original/faulty from today: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.tx= t > - APU1, fixed in loader.conf.local: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.= txt > - APU2 (has no problems): > https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt > > Let me know if you need additional information. > > - Stefan For the record, APU1 is =C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-STAB= LE stable/14-n269015-013d817b5393 STRATUM amd64 and APU2: =C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n269015-013d817b5393 APUPF amd64 --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06.10.2024 21:14, 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 <stefan.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 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 adaptation<= /div>
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?<= /div>

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)

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_3mdeb_v4_17_0_3_fixed.txt
- APU2 (has no problems): https://hegnauer.selfhost.eu/web= /computing/apu2d4_3mdeb_v4_19_0_1.txt

Let me know if you need additional information.

- Stefan

For the record, APU1 is
=C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a
=C2=A0=C2=A0=C2=A0 14.1-STABLE
=C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-S= TABLE stable/14-n269015-013d817b5393 STRATUM amd64

and APU2:
=C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a
=C2=A0=C2=A0=C2=A0 14.1-STABLE
=C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STA= BLE stable/14-n269015-013d817b5393 APUPF amd64



--------------7T2SWUvVFJJ1WVFzx0ond7Se--