mfi "unexpected sense" when using mfip/smartctl

[Kevin Day]

On Oct 12, 2010, at 8:02 PM, Scott Long wrote:

> On Oct 12, 2010, at 3:15 PM, Kevin Day wrote:
>> 
>> Hey, SCSI people!
>> 
>> I'm trying to use smartctl (from smartmontools) with an mfi card. I can kldload mfip, and use smartctl to access SMART data on the member drives fine. The problem is that each time I do so, I get:
>> 
>> mfi0: 13501 (340232122s/0x0002/info) - Unexpected sense: PD 05(e0x04/s0) Path 50030480006deec4, CDB: 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00, Sense: c/6d/00
>> 
>> I'm assuming this shows up because the RAID controller isn't expecting the reply to the command that smartctl is sending behind it's back.
>> 
>> If so, this is pretty harmless, but it looks very very similar to what happens when there's a serious problem with a drive. Is there a way this could be muted, or is this indicating that something is actually not working right? 
>> 
> 
> You're exactly right about the controller firmware seeing a side effect of running smartctl.  You can cross-ref the sense codes at http://www.t10.org/lists/asc-num.txt if you're interested.  The reported code of "c/6d/00" doesn't make any sense to me, but I guess it's ok.  As long as it's not kicking the array into failover mode, it's harmless.  I think that there is an official way of doing SMART in-band with the controller that avoids this confusion, I'll look into it.  It likely means that smartctl will need learn how to talk to the /dev/mfi0 interface, or mfiutil will need to learn about SMART commands.  Neither option is terribly easy.
> 
> Scott

I've been looking at this a bit more...

Smartctl on Linux uses a special ioctl to talk to the controller like a passthrough device, which makes the code path nearly identical to FreeBSD+smartctl+mfip. But on Linux, it's not generating any log entries on the controller. (I even checked to make sure they weren't somehow not being printed on the console, but they really aren't being generated at the card itself). 

I don't see a great deal of differences between what Linux is doing and what happens here, but I also agree that the sense code being reported doesn't make sense. I'm kinda wondering if somehow we're not sending the controller a bad/additional/unhappy passthrough frame, which is making it send an additional command to the drive. Smartctl seems mostly functional, but requires turning off some sanity checks that aren't necessary on identical hardware/drives under Linux to make it work.

Before I dig much deeper, do you have any wild guesses? :)

-- Kevin