Sorry to jump-in, but could this be similar to a problem I have since 6.7 ?
https://marc.info/?l=openbsd-misc&m=159611309426907&w=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:
>> Da
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, mark.kette...@xs4
> 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:
> > > >
> > > > revision
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; lin
> 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 n
>
> 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 att
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 ha
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 byte
12 matches
Mail list logo
