Date: Thu, 3 Feb 2005 12:19:03 -0800 From: "Andrew Heyn" <aheyn@jmsent.com> To: <freebsd-hardware@freebsd.org> Subject: RE: Compaq Smart Array 4200 controller question Message-ID: <CLELJKHKLJLNMNHGHFIDGEPJCAAA.aheyn@jmsent.com> In-Reply-To: <20050203120923.G76517@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.ORG] Sent: Thursday, February 03, 2005 9:10 AM To: Andrew Heyn Cc: freebsd-hardware@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CLELJKHKLJLNMNHGHFIDGEPJCAAA.aheyn>