lkml.org 
[lkml]   [1996]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectLibc 5.3.9 did not help ...
Date
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




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.022 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site