Today's mails to misc@ are bouncing back with
[email protected]: Network error on destination MXs
Jan
On Jan 17 15:49:08, [email protected] wrote:
> Hi!
>
> This is the MAILER-DAEMON, please DO NOT REPLY to this email.
>
> A message is delayed for more than 4 hours for the following
> list of recipients:
>
> [email protected]: Network error on destination MXs
>
> Please note that this is only a temporary failure report.
> The message is kept in the queue for up to 7 days.
> You DO NOT NEED to re-send the message to these recipients.
>
> Below is a copy of the original message:
> Reporting-MTA: dns; stare.cz
>
> Final-Recipient: rfc822; [email protected]
> Action: delayed
> Status: 4.0.0
> Received: from localhost (stare.cz [local])
> by stare.cz (OpenSMTPD) with ESMTPA id 3d1ef9fe
> for <[email protected]>;
> Mon, 17 Jan 2022 13:02:16 +0100 (CET)
> Date: Mon, 17 Jan 2022 13:02:16 +0100
> From: Jan Stary <[email protected]>
> To: [email protected]
> Subject: Re: ttyflags hangs on Dell PowerEdge R200
> Message-ID: <[email protected]>
> References: <[email protected]>
> <[email protected]>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <[email protected]>
>
> On Jan 14 19:10:32, [email protected] wrote:
> > On Fri, Jan 14, 2022 at 10:41:52PM +0100, Jan Stary wrote:
> > > I suspect it's com1; I have yet to try commenting out just tty01.
> > > But commenting out both makes it boot OK.
> > >
> > > com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> > > com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo
> > >
> > > Are these known to misbehave under ttyflags?
> > >
> > > I realize a lot has changed since then, but it's a production machine,
> > > and while I would love nothing more than go through the releases one
> > > by one, this machine has to run now.
> >
> > Well there were recently changes to make com attach via acpi, and now
> > you have a com port that you didn't have before.
>
> This is to confirm that the "new" com1 @ acpi is the culprit:
> it is enough to comment out tty01 in /etc/ttys
> and the boot gets through ttyflags -a
>
> > My suspicion would be that the new com1 either does not really exist in
> > hardware, or that it's mis-configured.
>
> Please excuse my HW ignorance: does "ti16750" mean then
> that some ACPI table _says_ there it a (Texas Instruments?) com,
> even if there isn't really? At any rate, there is just one
> visible cereal on the PowerEdge's case.
>
> > Does the BIOS mention it? Can it be disabled there?
>
> The BIOS only mentions "Serial port 1 ... COM1",
> which I suppose is 1-based indexing, so that's com0 aka tty00.
> There is no other serial port in the BIOS to be disabled.
>
> (Got a diff in the meantime, recompiling now.)
>
> Jan
>
