Re: NetBSD and VMEbus RAM

David Brownlee <[email protected]> Thu, 13 Aug 2020 20:36:28 +0100
Newsgroups gmane.os.netbsd.ports.mvme68k
Message-ID <CAGN_6pbXkEbPhL9daPAU4HpCPWugCPG5Q-yqrKN8v37bBxpq2w@mail.gmail.com>
On Thu, 13 Aug 2020 at 19:35, Chris Hanson <[email protected]> wro=
te:
>
> NetBSD has grown a bit over the years and my 32MB MVME167 appears to hit =
swap during execution of /etc/rc from the 9.0-stable branch. So I thought I=
=E2=80=99d try adding a RAM board.
>
> I added a Micro Memory MM-6230 8MB board (addressed at 0xFB000000) to my =
system, and followed the instructions in the installation guide for telling=
 NetBSD about it.
>
> Unfortunately, it appears that NetBSD dies on the first access to the boa=
rd as system RAM; around the time ntpd starts the system hangs and I get a =
yellow FAIL light on the MVME167.
>
> I=E2=80=99ve confirmed that the RAM board works by writing a little progr=
am to write data to it via /dev/mem at power up, the RAM board=E2=80=99s pa=
rity error light comes on, and writing to it via my program clears the ligh=
t, so I suspect an issue with NetBSD or something in its VME interaction.
>
> Has anyone else had success recently with VMEbus memory boards? Where do =
I even begin to debug this? The board supports A32 and D32/16/8 so access i=
tself shouldn=E2=80=99t be a problem. Would I be better off just writing a =
dumb block device driver and treating the board as a fast swap device? Did =
I make a mistake in leaving the board set to 0xFB000000?

Random thoughts (not necessarily of any value :)
- Is the VME memory board DMA capable - if not then the SCSI
controller code could end up in a bad place...
- Did the little program write a combination of patterns to test
parity to all 8MB
- Try telling NetBSD to use the first, and then the last 1MB of memory
to see if either helps
- In the absence of anything else your proposed simple block device
driver could be used to run a test program to heavily exercise it
while the rest of the system is busy (*)

*: Off in the realm of bizarre interactions, like a marginal power
supply which causes issues with the memory board when everything else
is busy. All the I/O is on the main board so that shouldn't be
interacting, but maybe DMA to the ethernet could be an issue

David