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