From nobody Sun Oct 6 13:47:32 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 4XM3WS4zDgz5Y6Fq for ; Sun, 06 Oct 2024 13:47:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 4XM3WR6d0Hz3wcM for ; Sun, 6 Oct 2024 13:47:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-7ea0ff74b15so32132a12.3 for ; Sun, 06 Oct 2024 06:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728222466; x=1728827266; 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=V3sFjvSS90UJBO9XnaUdo+Iq354O/BDwZpXPg2109Ig=; b=HZKEnS72ue9MCnGceRDsNTzuObXvIgab3dVlvS0/vl9JJWz4RX/a4OWrBdGpF7mtpK ClQBGda0B7cE1Ym3pGHAEQhja9L7FH9s5o3N6O8P7nQoyKkQAPZAJMNW941Jbjg9e+cq 7Xzk/01zRlkcNzMsDQOcRuQFTfuCKQBltdSsupP+JTX+m2LlzUsGrAiP1sXpuI2X+JRq 3pOQchAcPLiHaWZHrNm0XrsHtZ/eYulwx4E3ENuznDUzqPEQI40aMmmSGD8p0JdGiR8F USK5AZwfnpCP1apg89jiPRQMIs2LagovstVK6CGMx4wlRHGl6vGWPiTpWC1n1+JNNHSd OOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728222466; x=1728827266; 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=V3sFjvSS90UJBO9XnaUdo+Iq354O/BDwZpXPg2109Ig=; b=nMkXrLJZ3nAZhEKXRZkgiA66KMpL6giugcG65pgeSpYOWIuuQM47PU5lorb8N3OqCH 6FOkk8bv2Yuwtyu3h+ff8a0Tb7jlnaVkY3cuCPymOnrHGDMC6V6taVaGLas2R0Qbd7rW R2NAHH9tUtSFFlyBnqdMSNCht+7hWCkEnwINeslFUt6j0Y/SgIfRsOJqIIXrm72XCU8s 5EPZvGtRRqkiA1p6cx8+JiQvLg44EUk33D9eE3MBp/5p+05b7hKqTh+hqCdjvV3GrPDo xtnxUPV7N7DwNeHAup3vEs5Flz1Wvs6O9OsAjuyYszUklpoYVajI3qLw1xWy7F8n9jRy 6+Ow== X-Gm-Message-State: AOJu0YyAGFTa2gHjJIsIfEMkjJ8s0ENUtmVhtFK8Eguc0AFu5gwxprlb 6BeYPv/t+YbKub9B40B4ozg/ExZ79VTBE8hZYvE+udedamF0hoQXBgpvBalVbKUGF3KWBTjFMBU 11+oH4I9kl8zBupI5U2Oghvce4BNQ+2F28g/j7A== X-Google-Smtp-Source: AGHT+IHZnkCfTAjZ6gszr9n1Iu7qcqRq3iLjClCQYsYWfmsRrlS4bvVfYaCy2sR3+1QXgwkk68tL9wv5ZsbujvCNybc= X-Received: by 2002:a17:90a:7186:b0:2e1:e19f:609b with SMTP id 98e67ed59e1d1-2e1e627f41fmr10251982a91.24.1728222466346; Sun, 06 Oct 2024 06:47:46 -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 07:47:32 -0600 Message-ID: Subject: Re: APU1 bricked on stable/14 - solved To: Stefan Hegnauer Cc: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000332c130623cf26d8" 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: 4XM3WR6d0Hz3wcM X-Spamd-Bar: ---- --000000000000332c130623cf26d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 tha= t developers haven't seen. The hint thing wasn't though to actually negativel= y 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 the= y 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 > > --000000000000332c130623cf26d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 6, 2024 at 6:35=E2=80=AFA= M Stefan Hegnauer <stefan.hegn= auer@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 setting= s
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.

Lik= ely, 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 a= ctually negatively
affect any deployed hardware since it dealt wi= th details that changed 15 or
20 years ago...

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

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

Warner
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.

- Stefan

--000000000000332c130623cf26d8--