amr driver issues in 7.1-RELEASE

Scott Long scottl at samsco.org
Thu Jan 22 13:49:06 PST 2009


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


More information about the freebsd-stable mailing list