Welcome back Gerard,
I fear I made a mistake in the post you were replying to. Just to get you
up to speed as quickly as possible with my problem I'll give you a quick
run down of where I am now.
I have two machines both plugged into the same RAID controller. I was
doing all of my testing on one machine. The last test I ran with the 32
max, 32 default ended up eating my root filesystem. Since I had the other
machine rather than reinstalling I just moved over to the backup (while
the machines are shareing /usr and /home, / and /var are unique).
On the backup I continued my tests. 8 max, 8 default worked. 32 max, 8
default, okay. That is when I tried the 255 max, 32 default. That also
worked, and puzzled me, thus the post.
I have since tried 255 max, 255 default. That also works, but I think
might be able to cause trouble as the controller sees 5 drives, but they
are in fact all on 1 RAID controller with a max combined queue depth of
1024. If I pushed all 5 drives as hard as possible, could I queue up more
than 1024 commands? Reguardless...
Sometime last week after getting most of the way to crazy, not being able
to reproduce the problem. I went back to the first machine I was
using. Bam, instant problem (255/255), and the was just with dd'ing
/dev/zero over the disk.
I said, "hmmm", went to the second machine, tried the dd, worked
fine. Built a new kernel with 8/8 queueing. Tried it on the first
machine. I watched the "Dirty Cache %" on the RAID controller as I
dd'ed. As soon as it hit 100% the driver started throwing errors. The
other machine holds out fine even when holding at 100% dirty.
These boards are supposed to be identical. But they don't seem to act the
same using the same kernel with the same test. Do you (or anyone on
l-s) have a clue as to what the problem could be?
Thanks,
Chris
On Mon, 14 Aug 2000, [ISO-8859-1] G�rard Roudier wrote:
> The difference is that the driver will use 255 different tag values
> allocated in a fifo manner, instead of 32. With a current queue depth
> value of 32, tag numbers will not be reused until at least 255-32=222 IOs
> have completed.
>
> The way the driver allocates tag numbers was intended to avoid triggerring
> races in firmwares. I donnot know where the race is, can be in the
> firmware or in the kernel, but it seems some has been fished out.
>
> If you want to play a bit, you may, for example, configure the driver for
> some reasonnable MAXTAG value and try by dichotomy on the actual number of
> tags used to get some information about the minimal number of used tags
> that leads to breakage.
>
> For example:
> - MAXTAG=32
> - Try tags=16, if OK try tags=24, if not OK try tags=20, and so on ...
>
> Gerard.
--
Two penguins were walking on an iceburg. The first one said to the
second, "you look like you are wearing a tuxedo." The second one said,
"I might be..."
--David Lynch, Twin Peaks
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
