On Tue, 14 Sep 1999, Tom Livingston wrote:
> note that actual PCI setup is:
> AGP Slot: Trident 975 (IRQ disabled)
> PCI 1PDC20246: IDE controller on PCI bus 00 dev 78 hdm/n/o/p
> PCI 2PDC20246: IDE controller on PCI bus 00 dev 68 hdi/j/k/l
> PCI 3PDC20246: IDE con
On Tue, 14 Sep 1999, Rogier Wolff wrote:
>If you're seeing THIS kind of errors, it SURE looks like a hardware
>issue. If the software is making errors, I'd expect a random byte
Don't understimate the RAM. Some month ago reports like this got solved by
replacing the only RAM in the system.
Andre
Rogier Wolff wrote:
> If you're seeing THIS kind of errors, it SURE looks like a hardware
> issue. If the software is making errors, I'd expect a random byte
> inserted somewhere. A block of data shifted one byte. A whole block
> corrupted (delivered to the wrong address in memory). Things like
>
Andre Hedrick wrote:
> AGP Card Slot
> PCI 1 PDC20246: IDE controller on PCI bus 00 dev 78 hdm/n/o/p
> PCI 2 PDC20246: IDE controller on PCI bus 00 dev 68 hdi/j/k/l
> PCI 3 PDC20246: IDE controller on PCI bus 00 dev 58 hde/f/g/h
> PCI 4
> PCI 5
>
> Update "2.2.12.uniform-ide-6.20.hydra.patch.gz" t
Someone whose name I snipped wrote...
> > > dd if=/dev/md0 count=50 2> /dev/null | md5sum
> > > done
> > 08d3b2b34dfc667ca96c549f8a8a3c15 -
> > cee7aa5dd1ee81ff63a93bba3830ca31 -
> > a577d2d50f9ebc535b9e49905c29631c -
> > f8c6aea89094543aaf2982ef6504285d -
> > 596f99e3047d18eef9798634a091
I wrote:
> Ingo Molnar wrote:
> > just a suggestion - if it's a faulty cable or a single faulty disk, then
> > you can find the problematic disk (or group of disks) by using
> less than 9
> > disks in the RAID0 array. I'd first split it into a 4 and 5-disk group.
> > This presumes the test doesn't
Ingo Molnar wrote:
> just a suggestion - if it's a faulty cable or a single faulty disk, then
> you can find the problematic disk (or group of disks) by using less than 9
> disks in the RAID0 array. I'd first split it into a 4 and 5-disk group.
> This presumes the test doesnt take too long.
Thank
On Mon, 13 Sep 1999, Tom Livingston wrote:
> It doesn't work correctly with RAID0 either. [...]
> > dd if=/dev/md0 count=50 2> /dev/null | md5sum
> > done
> e4e661d1bbfa23ddbf3e326b18a3312e -
> 143f82fcc0634affdf3d05966e785eed -
> b31f38842f4b17c2e29a013447eeb582 -
just a suggestion - i
Ingo Molnar wrote:
> just to make sure wether this is a RAID5 problem, could you test a RAID0
> setup with the same number and physical layout of disks? That way you can
> simulate similar IO load, without the complexity of RAID5. RAID0 is simple
> and long-tested enough to be trusted 100%.
Certa
On Mon, 13 Sep 1999, Tom Livingston wrote:
> I am encountering reproducible read time errors while reading from my
> existing RAID array with at least one disk running on a HPT-366 driven
> channel. This manifests itself as random errors... [...]
just to make sure wether this is a RAID5 proble
Hello all,
I am encountering reproducible read time errors while reading from my
existing RAID array with at least one disk running on a HPT-366 driven
channel. This manifests itself as random errors... e.g. if you read the
same thing five times, you will get five different answers. I first
enc
11 matches
Mail list logo
