iscsi_trgt: scsi_cmnd_start(1035) Unsupported 85

This seems to be related to the iscsi opcode

ATA COMMAND PASS THROUGH (16)

However I'm not sure what is triggering it, could it be related to spinning down of disk during idle?

Still present with a natty server.

Just stumbled into this on Precise.

Both client and server are precise. It always pops up on reboot then at random during usage. No ill effects have been observed however.

I'm seeing the same thing as Avery-yates, with an exception. I have the same setup. The iSCSI server is hosting KVM virtual machines so getting lots of activity. I'm seeing them at a rate of several per second when they do appear. It may be related to a VM booting when it appears, but I'm not sure of that. The same error message show up in /var/log/syslog.

I have the same issue opcode 85 not supported, I am using Quantal packages. I've been using it for storing virtualbox guests only and this happens even when vbox or any guests are not open. It seems to occur sporadically, for example here, after I woke up my iniator from suspend:

Sep 7 03:08:43 debian kernel: [61460.232064] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 03:08:43 debian kernel: [61460.232369] iscsi_trgt: cmnd_skip_pdu(459) 1c000000 1c 85 0
Sep 7 03:08:43 debian kernel: [61460.233053] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 03:08:43 debian kernel: [61460.233381] iscsi_trgt: cmnd_skip_pdu(459) 58000000 1c 85 0
Sep 7 12:40:37 debian kernel: [95774.104298] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 12:40:37 debian kernel: [95774.104607] iscsi_trgt: cmnd_skip_pdu(459) 6c000010 1c 85 0
Sep 7 12:40:37 debian kernel: [95774.113470] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 12:40:37 debian kernel: [95774.113738] iscsi_trgt: cmnd_skip_pdu(459) 1000010 1c 85 0
Sep 7 12:40:37 debian kernel: [95774.114317] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 12:40:37 debian kernel: [95774.114768] iscsi_trgt: cmnd_skip_pdu(459) 26000010 1c 85 0
Sep 7 12:40:37 debian kernel: [95774.176272] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 12:40:37 debian kernel: [95774.176549] iscsi_trgt: cmnd_skip_pdu(459) 3a000010 1c 85 0
Sep 7 12:40:37 debian kernel: [95774.177166] iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
Sep 7 12:40:37 debian kernel: [95774.177500] iscsi_trgt: cmnd_skip_pdu(459) 21000010 1c 85 0

Status changed to 'Confirmed' because the bug affects multiple users.

After reading http://utcc.utoronto.ca/~cks/space/blog/linux/IETUnsupportedMessage, I think this warning is harmless.

The ICSI initiator sends an ATA PASS THROUGH command to the server, the server does not know what to do with and that's it.

According to https://groups.google.com/forum/#!msg/open-iscsi/PbKHnapEqCQ/5icFrw1fZQsJ it might be that smartd is sending this command.

I concur with Emmanuel in comment #8: This is not a bug but a harmless warning.

I noticed those message on my precise iscsi target:
Jan 20 12:31:14 mus kernel: [1785694.471334] iscsi_trgt: scsi_cmnd_start(1059) Unsupported 85
Jan 20 12:31:14 mus kernel: [1785694.471505] iscsi_trgt: cmnd_skip_pdu(472) 46000010 1c 85 0

I can generate those messages by running hpacucli (HP Array Configuration Utility CLI 9.40.12.0) on the iscsi initiator (SLES11SP3). I don't even have to give arguments or commands to hpacucli, it just scans all buses on startup and those messages appear immediately.
I wouldn't doubt that smartd is also generating the unsupported iscsi commands as it scans for devices to monitor (which seems to be a not uncommon default).