HP DL180G hpsa errors, CentOS 6 (2.6.38.4)

[oczeng]

I have a DL168G with a HP Smart Array G6 controller rev 01 P410.

After running nicely for a week, yesterday morning it choked out 6 hpsa messages, then kept on running.

Jan  3 10:55:18 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00]

Jan  3 10:55:18 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00]

Jan  3 10:55:25 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00]

Jan  3 10:55:25 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00]

Jan  3 10:56:05 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00]

Jan  3 10:56:05 qahp kernel: hpsa 0000:04:00.0: cp ffff880037900000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00]

The host OS is CentOS 6.0 (64) with the kernel upgraded to 2.6.38.4.

I've seem some of the similar posts, but, I'm not sure how to interpret these messages. Can someone (please) shed some light on what they mean and what or whether I should do to fix things?

Many thanks, -Dave G

[Jimmy Vance]

Those are ata passthru commands. Some user space tool is doing ata commands to the Smart Array, not supported and harmless.

[Matti_Kurkela]

Those are pretty much raw SCSI error codes, and the raw low-level SCSI commands that resulted in the errors.

Wikipedia seems to have nice tables for decoding SCSI commands and error values.

http://en.wikipedia.org/wiki/SCSI_Status_Code

http://en.wikipedia.org/wiki/KCQ

When a SCSI command is sent to a device, the device responds with a status code that identifies if the command was successful or not. In this case, when a command was sent, a result code 0x2, also known as "check condition" code, was received. It means the device can provide some additional data (so-called "sense data") to further qualify what went wrong - but this information is only provided if explicitly requested, using the "Request Sense" command.

Apparently the driver requested the sense data and got it. Looking at Wikipedia's KCQ table, sense key 0x5, ASC 0x20 and ASCQ 0 means "Illegal Request - invalid/unsupported command code". So, something asked the SCSI/SAS device to do something it cannot do.

The last part of the messages ("cmd=...") is the actual command that produced the error result. To decode that, you need yet another table:

http://en.wikipedia.org/wiki/SCSI_command

The first byte is 85 (hexadecimal), and the table tells us the command is "ATA COMMAND PASS THROUGH" and it's supposed to be 16 bytes long (which is correct). That means it should be an IDE/SATA command embedded within the SCSI protocol. Further decoding would require the appropriate ATA standards documents, which apparently are not quite so easy to find.

Anyway, my first question would be: did someone try to run smartctl/smartd/hdparm or some other disk diagnostic command at the time these errors were produced?

[oczeng]

Hey there MK - Thank you for the helpful information. It is helpful to know where to go and what to look for when messages like these are seen. You are correct, I was issuing some smartctl (5.4.2) queries and a database update at the time these messages were posted. Thank you, -Dave G.