Messages in this thread | ![/](/images/icornerl.gif) | | From | Alex Pikus <> | Subject | Libc 5.3.9 did not help ... | Date | Sat, 27 Apr 1996 13:13:05 -0500 |
| |
I have installed libc.so.5.3.9 Compiled 1.3.96 Rebooted
still get those fcntl_setlk() errors ...
lrwxrwxrwx 1 root root 13 Apr 26 18:41 /lib/libc.so.5 -> libc.so.5.3.9* -rwxr-xr-x 1 bin bin 579395 Apr 5 09:40 /lib/libc.so.5.3.9*
---------- From: Kai Henningsen[SMTP:kai@khms.westfalen.de] Sent: Friday, April 26, 1996 2:30 AM To: linux-kernel@vger.rutgers.edu Subject: Re: memtest86, built into kernel
mjb@sophos.com (Matthew J Brown) wrote on 23.04.96 in <199604230750.IAA02280@elbereth.sophos.com>:
> I don't think that parity gives you that much protection, though, so > I'm not convinced that it's worth seeking out systems that support it. > ECC may be a different story.
Parity _could_ be good - _if_ you could use it end-to-end. That's true for all error detection schemes, of course.
So what we would really want to see is parity on the data bus, generated and checked by the devices hanging on that bus.
For example, on a memory read, the CPU gets to check the RAM parity bit. On a I/O write, the FDC gets to check the CPU parity bit. And so on.
That would catch things like oxidated connectors.
Oh well, we can dream.
MfG Kai
| ![\](/images/icornerr.gif) |