> On May 10, Richard B. Johnson wrote:
>
> > On Mon, 10 May 1999, Stephen C. Tweedie wrote:
> >
> > > Hi,
> > >
> > > On Thu, 6 May 1999 10:54:21 -0700 (PDT), Dan Hollis
> > > <goemon@sasami.anime.net> said:
> > >
> > > >> at least on cold power-on you first have to write something to RAM
> > > >> to initialize the parity bit(s). if you try to read RAM first,
> > > >> odds are 50% that the parity bit is wrong and you'll get an NMI...
> >
> > You don't really have to clear memory, i.e., write to it. All you
> > have to do is read all of it with NMI disabled.
> >
> > Write 0x80 to port 0x70 to disable NMI, enable later by writing 0
> > out the same port (it's the index register for the CMOS clock-chip).
> > Since a read or write takes about the same time, it is usual to
> > just write all memory to zeros, but it is not necessary.
>
> why should reading memory update/set parity or ECC data ?
>
Because that's how it works! Every memory access, read or write, adjusts
ECC data. If it's a write, the compare-with-previous (actually an XOR)
operation is skipped.
> updating parity/ecc information can't happen for sure for every read
> because of performance reasons.
Yes it does! Since it's part of the memory controller and the RAM itself,
it doesn't add time, the value of the ECC is known well before the slower
RAM access actually occurs. It's a parallel operation.
> are there special bus/memory cycles if ecc/parity fails ?
If ECC is correctable, the memory controller may introduce a wait-state.
It depends upon the RAM speed. Basically, with ECC, the controller knows
what the data must be if it is correctable. Some controllers on some
machines DEC/Alpha rewrite corrected data. This takes extra time,
hence the wait-state.
Otherwise, the NMI line on the CPU is operated.
> I don't believe (at least for 8088/186/... this did _not_ happen).
>
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/