Sorry to jump-in, but could this be similar to a problem I have since 6.7 ?
https://marc.info/?l=openbsd-misc=159611309426907=2
tldr;
Server does not finish boot until I connect to the server's java console on the
iRMC (console redirection).
G
On 31/01/2022 16:51, Mark Kettenis wrote:
>> Date:
On Jan 31 15:51:06, mark.kette...@xs4all.nl wrote:
> > Date: Mon, 31 Jan 2022 15:41:32 +0100
> > From: Jan Stary
> >
> > On Jan 31 14:47:41, mark.kette...@xs4all.nl wrote:
> > > > Date: Mon, 31 Jan 2022 14:03:29 +0100
> > > > From: Jan Stary
> > >
> > > > > On Jan 26 18:02:17,
> Date: Mon, 31 Jan 2022 15:41:32 +0100
> From: Jan Stary
>
> On Jan 31 14:47:41, mark.kette...@xs4all.nl wrote:
> > > Date: Mon, 31 Jan 2022 14:03:29 +0100
> > > From: Jan Stary
> >
> > > > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote:
> > > >
> > > >
On Jan 31 14:47:41, mark.kette...@xs4all.nl wrote:
> > Date: Mon, 31 Jan 2022 14:03:29 +0100
> > From: Jan Stary
>
> > > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote:
> > >
> > > revision 1.406
> > > date: 2022/01/26 14:39:07; author: kettenis; state: Exp;
> Date: Mon, 31 Jan 2022 14:03:29 +0100
> From: Jan Stary
> > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote:
> >
> > revision 1.406
> > date: 2022/01/26 14:39:07; author: kettenis; state: Exp; lines: +2 -2;
> > commitid: zL3Ot2UVnkpDz6go;
> > An ACPI device
>
> On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote:
>
> revision 1.406
> date: 2022/01/26 14:39:07; author: kettenis; state: Exp; lines: +2 -2;
> commitid: zL3Ot2UVnkpDz6go;
> An ACPI device needs to be both present and enabled for it to function.
> So only
Boots fine, dmesg below.
> Index: arch/hppa/dev/com_dino.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/dev/com_dino.c,v
> retrieving revision 1.4
> diff -u -r1.4 com_dino.c
> --- arch/hppa/dev/com_dino.c 15 Jul 2007 19:25:49 -
On Jan 15 11:03:10, dera...@openbsd.org wrote:
> I think the bug is that com_acpi_match() should call ic/com.c comprobe1(),
> which verifies that an actual chip exists, rather than simply trusting the
> ACPI tables. If attach succeeds, open and ioctl become callable, and at
> that point if real
On Jan 14 19:10:32, kolip...@exoticsilicon.com 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
I think the bug is that com_acpi_match() should call ic/com.c comprobe1(),
which verifies that an actual chip exists, rather than simply trusting the
ACPI tables. If attach succeeds, open and ioctl become callable, and at
that point if real hardware isn't present, the driver reacts very poorly.
On Jan 14 19:10:32, kolip...@exoticsilicon.com 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
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
This is current/amd64 on a Dell PowerEdgee R200 (dmesg below).
Right after install, the first boot hangs after checking the filesystems.
Looking at /etc/rc in single user mode (adding set -x), it's apparently
the ttyflags -a call; indeed, commenting that out makes it boot OK.
I am now aware of
13 matches
Mail list logo
