Date: Thu, 22 Jan 2009 14:48:58 -0700 From: Scott Long <scottl@samsco.org> To: Steve Polyack <korvus@comcast.net> Cc: Mike Tancsa <freebsd-stable@freebsd.org>, freebsd-hardware@freebsd.org Subject: Re: amr driver issues in 7.1-RELEASE Message-ID: <4978E9CA.8040908@samsco.org> In-Reply-To: <4978E4AA.8050601@comcast.net> References: <4978CDE3.4040700@comcast.net> <4978E202.70408@samsco.org> <4978E4AA.8050601@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Polyack wrote: > Scott Long wrote: >> The fix for this that I was thinking of is already in 7.1. There >> might still be a driver bug, but I'm leaning more towards the >> controller simply being busy. Do you have a reproducible test case >> that I could >> try? >> >> Scott >> > We saw this one while backups wrote from an array on the PERC4/DC to a > tape drive (on a separate controller). > amr1: Too many retries on command 0xffffffff80a6d060. Controller is > likely dead > > The other four which I noted came during writes to the array attached to > the PERC4/DC (external Dell PowerVault). I want to say they showed up > while writing a 30G junkfile (/dev/random) to the array which we were > using to test the tape access; either that, or while we wrote that file > out to the tape drive. > > If it matters, we also use ports/sysutils/linux-megacli2 to periodically > check the status of our arrays. It's possible that this happened during > one of these long writes/reads. I'm not having any luck reproducing at > the moment, but if I come across a reproducible test, I will let you know. > I don't know too much about the internals of the AMR firmware, but I imagine that it could be possible that a management command from megacli could stall the firmware and make this warning pop up. I'll see if I can reproduce it. The warning is harmless, though, even if it is strongly worded. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4978E9CA.8040908>