Date: Thu, 13 Jan 2011 10:08:07 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Joachim Tingvold <joachim@tingvold.com> Cc: freebsd-scsi@freebsd.org Subject: Re: mps0-troubles Message-ID: <4D2EB2E7.9080404@FreeBSD.org> In-Reply-To: <41C64262-4300-4187-B5FD-04A5EFB7F87C@tingvold.com> References: <mailpost.1294832739.2809102.16331.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw> <4D2DAA45.30602@FreeBSD.org> <B2CFC8A1-FA1D-4718-99C3-AC3430A905C2@tingvold.com> <41C64262-4300-4187-B5FD-04A5EFB7F87C@tingvold.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joachim Tingvold wrote: > On Wed, Jan 12, 2011, at 23:29:53PM GMT+01:00, Joachim Tingvold wrote: >> If I were copying from the AHCI-attached disk to the mps controller, >> and the AHCI-attached disk timeouts, wouldn't this cause the disks on >> the mps controller to timeout as well? > > Now it happened again (while copying from 'zroot' to 'storage'). This > time only mps0 produced errors; > <http://home.komsys.org/~jocke/dmesg_mps0_freebsd-scsi_2.txt>. As the > timeout seem to be over quickly, I find it strange that whatever process > that accessed the disks (in my case, 'mv'), doesn't continue once the > disks are available -- or is this some kind of safeguard against > corrupted data? I don't know such "safeguards". I would suppose there is some bug in recovery process, making some request(s) never finish. As result, application initiated that request keeps waiting for it. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D2EB2E7.9080404>