Hi!
On Fri, 9 Apr 1999, Brian Leeper wrote:
> On Wed, 31 Mar 1999, Tony Wildish wrote:
> > Try booting with the 'mem=xxxM' option to limit yourself to a small
> > amount of RAM. If you are lucky then the problem is high enough in the
> > memory that you can limit yourself to a good region and i
On Wed, 31 Mar 1999, Tony Wildish wrote:
>
> Try booting with the 'mem=xxxM' option to limit yourself to a small
> amount of RAM. If you are lucky then the problem is high enough in the
> memory that you can limit yourself to a good region and it will work.
There's also a memtest86 utility t
Hi,
On Tue, 06 Apr 1999 10:39:21 +0100, Richard Jones
<[EMAIL PROTECTED]> said:
> Can it be a cabling fault? I thought that SCSI had parity
> checking.
Yes, it does, and all _decent_ scsi cards support it. Some old ones do
not (especially ISA cards).
--Stephen
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Mon, 29 Mar 1999 11:28:25 +0100, Richard Jones
> <[EMAIL PROTECTED]> said:
>
> > Not so fast there :-)
>
> > Mar 26 20:52:35 fred kernel: EXT2-fs error (device md(9,0)): ext2_free_blocks:
>Freeing blocks not in datazone - block = 550046767, count = 1
Hi,
On Mon, 29 Mar 1999 11:28:25 +0100, Richard Jones
<[EMAIL PROTECTED]> said:
> Not so fast there :-)
> In the stress tests, I've encountered almost silent
> filesystem corruption. The filesystem reports errors
> as attached below, but the file operations continue
> without error, corrupting
hi ya...
does these bugs exists for raid5?? under linux-2.2.5 ??
am running 2.2.4 w/ raid0 ( trivial stuff )..
have fun
alvin
> Richard Jones wrote:
>
> "D. Lance Robinson" wrote:
> >=20
> > I have also experienced file system corruption with 2.2.4. The proble=
> m most
> > likely lies in th
"D. Lance Robinson" wrote:
>
> I have also experienced file system corruption with 2.2.4. The problem most
> likely lies in the /fs/buffer.c file which the raid patch had a conflict
> with.
I'm also fairly sure now that the problem is
with 2.2.4. I'm currently taking the machine
back to 2.2.3 an
On Mon, 29 Mar 1999, Richard Jones wrote:
> The stress test script is attached so people can try
> this out for themselves.
I tried this test script with kernel 2.2.3 and the RAID patch dated
19990309. I let it run for almost 4 hours with 8 processes on a machine
with the following configurat
I have also experienced file system corruption with 2.2.4. The problem most
likely lies in the /fs/buffer.c file which the raid patch had a conflict
with.
<>< Lance.
Tony Wildish wrote:
> this sound to me like bad memory. I had a very similar problem recently
> and it was a bad SIMM. I was luc
Hello,
this sound to me like bad memory. I had a very similar problem recently
and it was a bad SIMM. I was lucky enough to have four SIMMS in the
machine so I can still run with only two, having removed the bad SIMM and
its partner.
Two suggestions:
Try booting with the 'mem=xxxM' option t
Here is some further information about the
filesystem, produced by dumpe2fs. The blocks
being freed seem to be far outside the actual
filesystem.
The block numbers generated are not random,
the same blocks appear over and over again.
And for those of you into spooky numerology,
if you subtract (h
Richard Jones wrote:
>
> Apart from a couple of minor and easily fixed patch problems,
> patch-2.2.4 can be applied to linux-2.2.3 + raid 19990309.
> I've been running some stress tests on the new kernel and
> a large array of SCSI RAID disks very successfully over-
> night. Well done to all!
No
12 matches
Mail list logo
