Port-mvme68k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD and VMEbus RAM

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


Home | Main Index | Thread Index | Old Index