Date: Sun, 6 Oct 2024 07:47:32 -0600 From: Warner Losh <imp@bsdimp.com> To: Stefan Hegnauer <stefan.hegnauer@gmx.ch> Cc: freebsd-stable@freebsd.org Subject: Re: APU1 bricked on stable/14 - solved Message-ID: <CANCZdfqZ_byx5aQsybVDriitWezTL43ix7Vajh-i1DKPRtg_7g@mail.gmail.com> In-Reply-To: <feaff803-ae93-4e9b-a8e6-1498d7b07b69@gmx.ch> References: <feaff803-ae93-4e9b-a8e6-1498d7b07b69@gmx.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <stefan.hegnauer@gmx= .ch> 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 6, 2024 at 6:35=E2=80=AFA= M Stefan Hegnauer <<a href=3D"mailto:stefan.hegnauer@gmx.ch">stefan.hegn= auer@gmx.ch</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">I have a few pc-engines APU1 appliances running in headless mode= under<br> Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.<br> After a recent update a few weeks back I was not able to connect by COM<br> port anymore - console output and input went away after booting and<br> before single- or multi-user mode would start. Even re-flashing the<br> SDcard with a fresh image did not help.<br> <br> After some longish trials and errors it turned out that both<br> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa"= ; to<br> "acpi"' as well as<br> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt setting= s<br> on x86'<br> broke things for me. Restoring hints and setting<br> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored<b= r> working order.<br> <br> I agree that APU1 is EOL, however I would have expected an entry to<br> UPDATING for such a POLA violation.<br></blockquote><div><br></div><div>Lik= ely, but really really old gear like this is going to hit edge cases that</= div><div>developers haven't seen. The hint thing wasn't though to a= ctually negatively</div><div>affect any deployed hardware since it dealt wi= th details that changed 15 or</div><div>20 years ago...</div><div><br></div= ><div>Looks like the APU1 used coreboot which at the time was trailing adap= tation</div><div>of ACPI, so it makes sense... I knew that Soekris boxes ha= d issues, but they</div><div>are another 5 or 10 years older than the APUs = and mine sadly isn't operational.</div><div><br></div><div>So I can wri= te a better UPDATING entry, can you share with me the dmesg</div><div>from = both APU1 and APU2?</div><div><br></div><div>Warner</div><div>=C2=A0</div><= 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<br> tables contain correct UART descriptions.<br> <br> - Stefan<br> <br> </blockquote></div></div> --000000000000332c130623cf26d8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqZ_byx5aQsybVDriitWezTL43ix7Vajh-i1DKPRtg_7g>