Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove paragraph describing problem with initialising VMEbus RAM cards' 

parity bits. Initialisation now handled during kernel startup.
This commit is contained in:
scw 1997-11-01 19:18:39 +00:00
parent db674c76eb
commit d0d3cc7965
1 changed files with 1 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
sys/arch/mvme68k/README.VMEbus-RAM
View File

@ -1,4 +1,4 @@
$NetBSD: README.VMEbus-RAM,v 1.1 1997/10/12 15:45:12 scw Exp $ $NetBSD: README.VMEbus-RAM,v 1.2 1997/11/01 19:18:39 scw Exp $
NetBSD/mvme68k port: VMEbus RAM card configuration NetBSD/mvme68k port: VMEbus RAM card configuration
@ -62,20 +62,6 @@ onboard RAM and will not attempt to use any VMEbus RAM.
Some extra notes on VMEbus RAM cards Some extra notes on VMEbus RAM cards
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most VMEbus RAM cards support parity checking in some form or another.
This can cause problems with the kernel. It's fairly normal for a card
to only initialise the parity bit on write accesses. This means that
the card can generate lots of parity errors following power-up. What's
happening is that NetBSD doesn't zero the RAM's contents on boot-up
so there's stale (and probably incorrect) parity data in the card.
If this happens with your card, try block-filling the card with zero
from the 147Bug> prompt (see the 'BF' command) before booting NetBSD.
If that cures the problem, see if there's a jumper on the RAM card to
disable parity checking. If not, you might have no choice but to block-
fill the memory following a power-up.
So... You've got your nice shiny VMEbus RAM card up and running with So... You've got your nice shiny VMEbus RAM card up and running with
NetBSD, and you're wondering why your system runs slower than it did NetBSD, and you're wondering why your system runs slower than it did
with less RAM! with less RAM!