NetBSD Problem Report #58261
From www@netbsd.org Wed May 15 16:43:06 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id DAAD31A9257
for <gnats-bugs@gnats.NetBSD.org>; Wed, 15 May 2024 16:43:06 +0000 (UTC)
Message-Id: <20240515164305.789A31A9258@mollari.NetBSD.org>
Date: Wed, 15 May 2024 16:43:05 +0000 (UTC)
From: ncommander@restless.systems
Reply-To: ncommander@restless.systems
To: gnats-bugs@NetBSD.org
Subject: lcg driver breaks MicroVAX 3100 M40 due to same board type
X-Send-Pr-Version: www-1.0
>Number: 58261
>Category: port-vax
>Synopsis: lcg driver breaks MicroVAX 3100 M40 due to same board type
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: port-vax-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed May 15 16:45:00 +0000 2024
>Last-Modified: Sun Jun 09 22:35:01 +0000 2024
>Originator: NCommander
>Release: 10
>Organization:
Restless Systems LLC
>Environment:
NetBSD soap 10.99.10 NetBSD 10.99.10 (GENERIC) #33: Fri May 3 09:44:54 UTC 2024 ncmdr@soapmaker.lan:/home/ncmdr/netbsd-src/sys/arch/vax/compile/obj/GENERIC vax
>Description:
NetBSD 8 GENERIC doesn't boot on this MicroVAX due to the lcg.c driver being enabled by default. This driver is meant to initialize the framebuffer on the VAXStation 4000 VLC. The MicroVAX 3100 M40 is essentially the same machine as the the VAXstation, so VAX_BTYP_48 is true, and the driver gets attached.
Internally, NetBSD treats this and the VAXstation 4000 VLC as the same machine, with determination in locore being a flag check on the SIE register. The lcg driver isn't included on the INSTALL kernel, so install.ram worked fine when I loaded it via MOP.
I sent a longer description to port-vax with dmesg and more information here: https://mail-index.netbsd.org/port-vax/2024/05/01/msg005016.html
>How-To-Repeat:
Install any recent version of NetBSD on a VAX board type 46 or 48 that lacks a framebuffer.
>Fix:
OpenBSD 5.8's lcg.c works, but it does quite a bit more checks on the system platform. This patch uses the same check on siedata as locore to determine microvax vs. vaxstation.
NetBSD 10 and current work if lcg is disabled in the config.
I came up with this patch allows the MicroVAX to boot up, although I don't have a VAXstation 4000 VLC to test on.
---
diff --git a/sys/arch/vax/vsa/lcg.c b/sys/arch/vax/vsa/lcg.c
index 0178c069cb08..0808b24f4faa 100644
--- a/sys/arch/vax/vsa/lcg.c
+++ b/sys/arch/vax/vsa/lcg.c
@@ -438,6 +438,9 @@ lcg_match(struct device *parent, struct cfdata *match, void *aux)
if ((vax_boardtype != VAX_BTYP_46) && (vax_boardtype != VAX_BTYP_48))
return 0;
+ if (vax_siedata & 0x1)
+ return 0; /* is microvax */
+
*ch = 1;
if ((*ch & 1) == 0)
return 0;
@@ -457,6 +460,9 @@ lcg_attach(struct device *parent, struct device *self, void *aux)
struct vsbus_attach_args *va = aux;
struct wsemuldisplaydev_attach_args aa;
+ if (vax_siedata & 0x1)
+ return; /* is microvax */
+
printf("\n");
aa.console = lcgaddr != NULL;
@@ -956,6 +962,9 @@ lcgcnprobe(struct consdev *cndev)
if (vax_confdata & 0x100)
return; /* Diagnostic console */
+ if (vax_siedata & 0x1)
+ return; /* is microvax */
+
lcg_init_common(NULL, NULL);
/* Set up default LUT */
>Audit-Trail:
From: =?UTF-8?Q?H=C3=A5kon_Innerdal?= <haakon@innerdal.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-vax/58261
Date: Thu, 6 Jun 2024 09:08:35 +0200
This is a multi-part message in MIME format.
--------------LSXGq1Og003OtdtG5MNmYmAh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
I have observed the same problem mentioned in post
https://mail-index.netbsd.org/port-vax/2024/05/01/msg005016.html
On my MicroVAX 3100 M80, using the stock GENERIC kernel (I have tried
NetBSD-10 and NetBSD-9.4), the serial console gives this output:
[ 1.0000000] NetBSD 9.4 (GENERIC) #0: Sat Apr 20 13:32:22 UTC 2024
[ 1.0000000]
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/vax/compile/GENERIC
[ 1.0000000] MicroVAX 3100/80
[ 1.0000000] total memory = 73448 KB
[ 1.0000000] avail memory = 66648 KB
[ 1.0000000] mainbus0 (root)
[ 1.0000000] cpu0 at mainbus0: KA47, Mariah, 2KB L1 cache, 256KB L2 cache
[ 1.0000000] vsbus0 at mainbus0
[ 1.0000000] vsbus0: 32K entry DMA SGMAP at PA 0x6a0000 (VA 0x806a0000)
[ 1.0000000] vsbus0: interrupt mask 0
[ 1.0000000] le0 at vsbus0 csr 0x200e0000 vec 770 ipl 17 maskbit 1 buf
0x0-0xffff
[ 1.0000000] le0: address 08:00:2b:2e:21:e3
[ 1.0000000] le0: 32 receive buffers, 8 transmit buffers
[ 1.0000000] dz0 at vsbus0 csr 0x200a0000 vec 124 ipl 17 maskbit 4
[ 1.0000000] dz0: 4 lines
[ 1.0000000] lkkbd0 at dz0
[ 1.0000000] lkkbd0: no keyboard
[ 1.0000000] wskbd0 at lkkbd0 mux 1
[ 1.0000000] lkms0 at dz0
[ 1.0000000] wsmouse0 at lkms0 mux 0
[ 1.0000000] tc0 at vsbus0 csr 0x36800000 didn't interrupt
[ 1.0000000] asc0 at vsbus0 csr 0x200c0080 vec 774 ipl 17 maskbit 0
[ 1.0000000] asc0: NCR53C94, 25MHz, SCSI ID 6
[ 1.0000000] scsibus0 at asc0: 8 targets, 8 luns per target
[ 1.0000000] lcg0 at vsbus0 csr 0x21801000 vec 440 ipl 15 maskbit 2
[ 1.0000000] panic: LCG model not supported
[ 1.0000000] cpu0: Begin traceback...
[ 1.0000000] panic: LCG model not supported
[ 1.0000000] Stack traceback :
[ 1.0000000] Process is executing in user space.
[ 1.0000000] cpu0: End traceback...
Stopped in pid 0.1 (system) at netbsd:vpanic+0x171: pushl $0
And I also can confirm that applying the patch from Mr. NCommander
mentioned here:
https://mail-index.netbsd.org/netbsd-bugs/2024/05/15/msg083093.html
on a NetBSD-9.4-GENERIC fixes the problem, lcg0 initialization is skipped.
Håkon
--------------LSXGq1Og003OtdtG5MNmYmAh
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I have observed the same problem mentioned in post </p>
<p><a class="moz-txt-link-freetext" href="https://mail-index.netbsd.org/port-vax/2024/05/01/msg005016.html">https://mail-index.netbsd.org/port-vax/2024/05/01/msg005016.html</a> </p>
<p>On my MicroVAX 3100 M80, using the stock GENERIC kernel (I have
tried NetBSD-10 and NetBSD-9.4), the serial console gives this
output:</p>
<p>[ 1.0000000] NetBSD 9.4 (GENERIC) #0: Sat Apr 20 13:32:22 UTC
2024<br>
[ 1.0000000]
<a class="moz-txt-link-abbreviated" href="mailto:mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/vax/compile/GENERIC">mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/vax/compile/GENERIC</a><br>
[ 1.0000000] MicroVAX 3100/80<br>
[ 1.0000000] total memory = 73448 KB<br>
[ 1.0000000] avail memory = 66648 KB<br>
[ 1.0000000] mainbus0 (root)<br>
[ 1.0000000] cpu0 at mainbus0: KA47, Mariah, 2KB L1 cache, 256KB
L2 cache<br>
[ 1.0000000] vsbus0 at mainbus0<br>
[ 1.0000000] vsbus0: 32K entry DMA SGMAP at PA 0x6a0000 (VA
0x806a0000)<br>
[ 1.0000000] vsbus0: interrupt mask 0<br>
[ 1.0000000] le0 at vsbus0 csr 0x200e0000 vec 770 ipl 17 maskbit
1 buf 0x0-0xffff<br>
[ 1.0000000] le0: address 08:00:2b:2e:21:e3<br>
[ 1.0000000] le0: 32 receive buffers, 8 transmit buffers<br>
[ 1.0000000] dz0 at vsbus0 csr 0x200a0000 vec 124 ipl 17 maskbit
4<br>
[ 1.0000000] dz0: 4 lines<br>
[ 1.0000000] lkkbd0 at dz0<br>
[ 1.0000000] lkkbd0: no keyboard<br>
[ 1.0000000] wskbd0 at lkkbd0 mux 1<br>
[ 1.0000000] lkms0 at dz0<br>
[ 1.0000000] wsmouse0 at lkms0 mux 0<br>
[ 1.0000000] tc0 at vsbus0 csr 0x36800000 didn't interrupt<br>
[ 1.0000000] asc0 at vsbus0 csr 0x200c0080 vec 774 ipl 17
maskbit 0<br>
[ 1.0000000] asc0: NCR53C94, 25MHz, SCSI ID 6<br>
[ 1.0000000] scsibus0 at asc0: 8 targets, 8 luns per target<br>
[ 1.0000000] lcg0 at vsbus0 csr 0x21801000 vec 440 ipl 15
maskbit 2<br>
[ 1.0000000] panic: LCG model not supported<br>
[ 1.0000000] cpu0: Begin traceback...<br>
[ 1.0000000] panic: LCG model not supported<br>
[ 1.0000000] Stack traceback :<br>
[ 1.0000000] Process is executing in user space.<br>
[ 1.0000000] cpu0: End traceback...<br>
Stopped in pid 0.1 (system) at netbsd:vpanic+0x171: pushl $0<br>
<br>
</p>
<p>And I also can confirm that applying the patch from Mr.
NCommander mentioned here: </p>
<p><a class="moz-txt-link-freetext" href="https://mail-index.netbsd.org/netbsd-bugs/2024/05/15/msg083093.html">https://mail-index.netbsd.org/netbsd-bugs/2024/05/15/msg083093.html</a> </p>
<p>on a NetBSD-9.4-GENERIC fixes the problem, lcg0 initialization is
skipped.<br>
</p>
<p>Håkon<br>
</p>
</body>
</html>
--------------LSXGq1Og003OtdtG5MNmYmAh--
From: David Brownlee <abs@absd.org>
To: gnats-bugs@netbsd.org, port-vax List <port-vax@netbsd.org>
Cc: port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems
Subject: Re: port-vax/58261
Date: Thu, 6 Jun 2024 17:26:12 +0100
Hi
The usage of vax_siedata has diverged over time - various callers are
making their checks with quite different idioms.
I've taken a quick pass to try to clean up the vax_siedata usage, and
provide a convenient IS_SIE_MICROVAX() macro (among others)
Diff is at:
https://sync.absd.org/vax/vax-sie.diff (also via http:// for those who
prefer that :)
Plus prebuilt kernel from today's current at:
https://sync.absd.org/vax/vax-sie.netbsd.gz
Would you be able to test boot it to confirm it still avoids the lcg
vaxstation issue?
Also feedback/thoughts appreciated on the vax_siedata cleanup
Thanks
David
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: David Brownlee <abs@absd.org>
Cc: gnats-bugs@netbsd.org, port-vax List <port-vax@netbsd.org>,
port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems
Subject: Re: port-vax/58261
Date: Fri, 7 Jun 2024 07:11:42 +0200
--vEao7xgI/oilGqZ+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, 2024-06-06 17:26:12 +0100, David Brownlee <abs@absd.org> wrote:
> Diff is at:
> https://sync.absd.org/vax/vax-sie.diff (also via http:// for those who
> prefer that :)
> Also feedback/thoughts appreciated on the vax_siedata cleanup
LGTM, but one comment on locore.c: I'm not sure whether or not there
are machines where this matters, but the new code removed a few
instances where previously it reported an "unknown" machine. (And it
seems TAB/SPACE indention is different in some spots?)
MfG, JBG
--=20
--vEao7xgI/oilGqZ+
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQlDTvPcScNjKREqWEdvV51g5nhuwUCZmKWiAAKCRAdvV51g5nh
u+oAAJwN8SlZva/rsZsih4Rlqx5m125m1gCeLWDcP6Y2tQK4NI4P8GzirRS6MMg=
=pMDo
-----END PGP SIGNATURE-----
--vEao7xgI/oilGqZ+--
From: David Brownlee <abs@absd.org>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: gnats-bugs@netbsd.org, port-vax List <port-vax@netbsd.org>,
port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems
Subject: Re: port-vax/58261
Date: Fri, 7 Jun 2024 10:47:29 +0100
On Fri, 7 Jun 2024 at 06:11, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
> On Thu, 2024-06-06 17:26:12 +0100, David Brownlee <abs@absd.org> wrote:
> > Diff is at:
> > https://sync.absd.org/vax/vax-sie.diff (also via http:// for those who
> > prefer that :)
>
> > Also feedback/thoughts appreciated on the vax_siedata cleanup
>
> LGTM, but one comment on locore.c: I'm not sure whether or not there
> are machines where this matters, but the new code removed a few
> instances where previously it reported an "unknown" machine. (And it
> seems TAB/SPACE indention is different in some spots?)
Thanks for the space/tab catch, diff updated :)
On reporting "unknown" machine rather than microvax/vaxstation, I've
never seen nor heard anyone report that output, but it will be easy
enough to put back the behaviour (though I make make it "Unknown
Mariah model VAX" or similar)
From: matthew green <mrg@eterna23.net>
To: David Brownlee <abs@absd.org>
Cc: port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems,
gnats-bugs@netbsd.org, port-vax List <port-vax@netbsd.org>
Subject: re: port-vax/58261
Date: Mon, 10 Jun 2024 04:37:23 +1000
> https://sync.absd.org/vax/vax-sie.diff (also via http:// for those who
thanks for working on this. looks pretty good to me.
couple of minor comments:
- switch is a keyword, so add/retain the spaces after it before the (.
- ka46.c change could do with a line wrap to retain 80 cols
- VAX_BTYP_46 check now assumes not 1 is 2, instead of checking for 1,
2, and then deciding unknown. also VAX_BTYP_48. also VAX_BTYP_420
for 0 and 1..
- if you want to clean up a little more, changing these '1', '2', etc.,
magic numbers could be named, "vax_cpudata & 0xff" could become a
macro (GET_SIE_MICROCODE_VER(x)?)
.mrg.
From: David Brownlee <abs@absd.org>
To: matthew green <mrg@eterna23.net>
Cc: port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems, gnats-bugs@netbsd.org,
port-vax List <port-vax@netbsd.org>
Subject: Re: port-vax/58261
Date: Sun, 9 Jun 2024 23:18:33 +0100
On Sun, 9 Jun 2024 at 19:37, matthew green <mrg@eterna23.net> wrote:
>
> > https://sync.absd.org/vax/vax-sie.diff (also via http:// for those who
>
> thanks for working on this. looks pretty good to me.
Thanks for the check
> couple of minor comments:
>
> - switch is a keyword, so add/retain the spaces after it before the (.
> - ka46.c change could do with a line wrap to retain 80 cols
Done & done
> - VAX_BTYP_46 check now assumes not 1 is 2, instead of checking for 1,
> 2, and then deciding unknown. also VAX_BTYP_48. also VAX_BTYP_420
> for 0 and 1..
> - if you want to clean up a little more, changing these '1', '2', etc.,
(as mentioned before) I've never seen nor heard anyone report that
output, but it will be easy enough to put back the behaviour (though
I'll make it "Unknown
Mariah model VAX" or similar). Will do that next.
> magic numbers could be named, "vax_cpudata & 0xff" could become a
> macro (GET_SIE_MICROCODE_VER(x)?)
Sometimes the ucode rev is in 0xff (which is accessed sometimes as "&
0xff", "& 0377", and my favourite "% 0377" :), and sometimes the
hardware3 rev is in 0xff, and ucode rev in 0xff00. Its common enough
that I think it's worth a macro, with a /* usually, not always */
comment
Actually, looking again I really rather like the approach in
vax/ka780.c:345 - create a bitflag struct for sid
struct ka78x {
unsigned snr:12,
plant:3,
eco:8,
v785:1,
type:8;
};
and then use
aprint_normal(": KA%s, S/N %d(%d), hardware ECO level %d(%d)\n",
cpu_getmodel() + 7, ka78->snr, ka78->plant, ka78->eco >>
4, ka78->eco);
I think for the cpu specific files which just print out hardware rev
and similar, that could be a lot cleaner. Need to think more.
Updated diff for most changes at original url, will look at changing
the '46 & '48 back to switch with "unknown". (The '402 is using
GET_SIE_STYP for a similar but unrelated check :),
Thanks
David
From: Johnny Billquist <bqt@softjar.se>
To: David Brownlee <abs@absd.org>, matthew green <mrg@eterna23.net>
Cc: port-vax-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, ncommander@restless.systems, gnats-bugs@netbsd.org,
port-vax List <port-vax@netbsd.org>
Subject: Re: port-vax/58261
Date: Mon, 10 Jun 2024 00:29:32 +0200
On 2024-06-10 00:18, David Brownlee wrote:
> On Sun, 9 Jun 2024 at 19:37, matthew green <mrg@eterna23.net> wrote:
>>
>> magic numbers could be named, "vax_cpudata & 0xff" could become a
>> macro (GET_SIE_MICROCODE_VER(x)?)
>
> Sometimes the ucode rev is in 0xff (which is accessed sometimes as "&
> 0xff", "& 0377", and my favourite "% 0377" :), and sometimes the
> hardware3 rev is in 0xff, and ucode rev in 0xff00. Its common enough
> that I think it's worth a macro, with a /* usually, not always */
> comment
If anyone did "% 0377" that would be a bug. It's a different thing.
However, if they did "% 0400" it would be fine, and I would suspect the
compiler would reduce that to an AND (or actually a BICL in VAX
assembly) in the end anyway.
> Actually, looking again I really rather like the approach in
> vax/ka780.c:345 - create a bitflag struct for sid
>
> struct ka78x {
> unsigned snr:12,
> plant:3,
> eco:8,
> v785:1,
> type:8;
> };
>
> and then use
>
> aprint_normal(": KA%s, S/N %d(%d), hardware ECO level %d(%d)\n",
> cpu_getmodel() + 7, ka78->snr, ka78->plant, ka78->eco >>
> 4, ka78->eco);
I do agree that using a bitfield is a very reasonable approach for this,
and I did the same for the ka86. But looking at the quoted lines above,
I really think eco should be split in two parts instead of the shifting.
That seems just silly, if that really is two different numbers to the eco.
Also, cpu_getmodel() returns a string, and then 7 is added to that
pointer. That seems rather horrible coding, and I think that should also
be cleaned up a bit. But that's not really a part of your work, so I
wouldn't worry about that here.
However, again - I think changing to use bitfields for these kind of
things make the code much cleaner.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home