Thorild Selen wrote:
Brad Campbell writes:
> In one machine, I'm using 15 disks on 4 SATA150TX4 cards with
> 2.6.11.7 and have been now for over 4 months.. it's working
> perfectly.. not so much as a glitch.
Is this a single-processor system without hyperthreading or the like?
In that case, it could be that the problem only appears on SMP/HT
systems, which would be interesting to know.
(I was hit by the bug on a single-processor Xeon system, but with HT
enabled. I never thought of testing if disabling HT would make the bug
disappear or not. And now that the system is up and running again, I
don't really have the possibility to experiment with it.)
If you have partitions on different devices that you can spare and
feel a little risky, you can try running badblocks -w (WARNING: this
will destroy any data on the disk/partition!) on several disks
simultaneously. That appears to be the simplest way to quickly
reproduce the bug.
These 15 drives are in a RAID-6 that gets thrashed from time to time quite hard.. so there is almost
*always* simultaneous IO to them.. But it is certainly a UP machine (both of them are).
This one has 15 drives RAID-6, the other has 10 drives RAID-5 and 3 drives RAID-5 (two on the
Promise ctrlr and one on the on-board VIA)
No free partitions to spare, sorry.. all md's are pretty full.
However I did all sorts of badblocks/dd/bonnie runs when I was burning in the box and never had an
issue at all.
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
