Compaq Smart Array 4200 controller question

[Andrew Heyn]

Hi Matthew,

Yes, that is correct.  If a program is using I/O when the controller decides
to be
uncooperative, there's a chance that it will recover, and continue on, and
there's
also a chance that it will be stuck in-kernel forever waiting for the data.
Meanwhile, other program _can_ access data...until they get stuck some time
later
in the kernel.

root    2865  0.0  0.0  1312  860  p0  D    11:28AM   0:06.71 find /
Thu Feb  3 12:20:53 UTC 2005
top says that find is stuck in 'ufs'

Meanwhile, I catted 6.0-CURRENT-20050202-SESNAP.tar.bz2 to /dev/null
It took quite a few seconds the first time, and subsequent times took
a much shorter amount of time.  I can also cat /dev/ida0xxx to /dev/null,
and all sorts of other I/O...while that find is stuck in-kernel.

Anything else I can do to help?

Thanks,
Andrew


-----Original Message-----
From: Matthew N. Dodd [mailto:mdodd at FreeBSD.ORG]
Sent: Thursday, February 03, 2005 9:10 AM
To: Andrew Heyn
Cc: freebsd-hardware at FreeBSD.ORG
Subject: RE: Compaq Smart Array 4200 controller question


On Thu, 3 Feb 2005, Andrew Heyn wrote:
> I noticed that with 6-CURRENT the machine doesn't crash anymore and
> reboot when the controller stops responding.  It tended to before...
> Instead, whatever program that caused the problem hangs on a kernel
> function forever, and subsequent reads/writes kinda work...in the same
> manner as they did(n't) before.

Wait, so other IO on the array continues to work?  (Make sure you're not
seeing the result of caching.)

--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00