On Thu, 13 Aug 2020 at 19:35, Chris Hanson <cmhanson%eschatologist.net@localhost> wrote: > > 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’d 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 board as system RAM; around the time ntpd starts the system hangs and I get a yellow FAIL light on the MVME167. > > I’ve confirmed that the RAM board works by writing a little program to write data to it via /dev/mem at power up, the RAM board’s parity error light comes on, and writing to it via my program clears the light, 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 itself shouldn’t 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