# cam(control), mpt & LSI 3081 with IT firmware



## hsmeets (Feb 28, 2011)

Hi all,

(first post, so please cut me some slack :e).

I'm building a new server, third in succession, the two before were also FreeBSD based.

Different to the two servers before this server is the fact that I'm running VMware ESXi 4.1 and I installed a LSI 3081 card. The LSI card is flashed with the IT firmware. 

I use the LSI card for two reasons: VMware's PCI Passthrough of the LSI card to the FreeBSD Guest so ZFS can talk to the raw drives instead of suppling the disks via VMware virtual discs to FreeBSD and second reason to be able to hook up more drives than the ICH10 of the motherboard allows to.

All works fine: the LSI 3081 is recognized in FreeBSD, mpt is loaded and the drives are used in a zpool.

I wanted to set up disk spindown as I did on my first two servers with *atacontrol*, obviously *atacontrol* is not working here as it is not ATA or AHCI and I need to use *camcontrol*. However with little success.

Camcontrol is very limited in use: things like `camcontrol stop/start <dev>` seem to work, however `camcontrol identify <dev>` stays very mute, only with the *-v* flag 2 lines are shown, pass1/pass2. Doing a `camcontrol standby/idle <dev>` gives an error: 
	
	



```
could not send command
```

I'm using Samsung F4 204UI drives & FreeBSD 8.2.  Is this a (known) limitation of the samsung drives? The LSI card in IT mode? mpt driver handling the IT mode? Or the cam subsubsytem?

I can live with the fact to run the drives 24/7 as there are only 2 for the moment. But in the future, when adding more drives it would be a welcome feature to have up and running.

Thanks,

Huib

(PS. I found the script to "*camcontrol stop*" all non used drives in a storage pool).


----------



## Zare (Feb 28, 2011)

Are you sure that passthrough works with full functionality? Can you try testing spindowns with another virtual guest (Linux/Windows Server), making sure that issue resides in FreeBSD itself?


----------



## hsmeets (Feb 28, 2011)

Zare said:
			
		

> Are you sure that passthrough works with full functionality?



That should be the whole idea. 



			
				Zare said:
			
		

> Can you try testing spindowns with another virtual guest (Linux/Windows Server), making sure that issue resides in FreeBSD itself?



Good suggestion, will try with an linux install tonight that will also get the LSI card PCI device in passthrough. 

Huib


----------



## hsmeets (Feb 28, 2011)

Apropos, the other option is of course to do away with the VMWare and install FreeBSD right on the hardware.....but if that worked it would throw a spanner in the works to consolidate some stuff on one piece of hardware. OTOH, 2 full systems with spindown disks might still consume more power then one with running disks......


----------



## DutchDaemon (Feb 28, 2011)

hsmeets said:
			
		

> (first post, so please cut me some slack :e).



We'll cut you some slack if you read your sign-up email


----------



## hsmeets (Feb 28, 2011)

DutchDaemon said:
			
		

> We'll cut you some slack if you read your sign-up email



Understood, saw your edit to my posting 

Regards,
Huib


----------



## hsmeets (Feb 28, 2011)

Zare said:
			
		

> Are you sure that passthrough works with full functionality? Can you try testing spindowns with another virtual guest (Linux/Windows Server), making sure that issue resides in FreeBSD itself?



Well, I quickly installed Ubuntu 10.10 into a Virtual Machine of VMWare with PCI passthrough to the LSI 3081 card.

The card and the two attached drives are recognized and with `hdparm -Y /dev/sdb` I can do the spindown. I checked that physically.

Started FreeBSD again and issued several `camcontrol` commands:


```
prometheus# camcontrol identify da1

prometheus# camcontrol readcap da1
Last Block: 3907029167, Block Length: 512 bytes

prometheus# camcontrol inquiry da1
pass1: <ATA SAMSUNG HD204UI 0001> Fixed Direct Access SCSI-5 device 
pass1: Serial Number S2HGJDWZ804989      
pass1: 300.000MB/s transfers, Command Queueing Enabled

prometheus# camcontrol standby da1
(pass1:mpt1:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 00 00 00 00
(pass1:mpt1:0:0:0): CAM status: CCB request was invalid

prometheus# camcontrol sleep da1
(pass1:mpt1:0:0:0): SLEEP. ACB: e6 00 00 00 00 40 00 00 00 00 00 00
(pass1:mpt1:0:0:0): CAM status: CCB request was invalid

prometheus# camcontrol stop da1
Unit stopped successfully

prometheus# camcontrol start da1
Unit started successfully
```

Regards,
Huib


----------



## bplein (Apr 5, 2011)

I am having the same issue.

FreeBSD 8.2-release, in a VM under VMware ESXi 4.1.

PCIe passthrough of the onboard LSI SAS (1068e chipset) to the VM. I can see all 6 drives attached. There are two different brands/models of drives, all exhibiting the same behavior.

Example:

```
[root@dante /usr/home/bill]# camcontrol identify da3 
[root@dante /usr/home/bill]# camcontrol readcap da3 
Last Block: 1953525167, Block Length: 512 bytes
[root@dante /usr/home/bill]# camcontrol inquiry da3 
pass3: <ATA Hitachi HDT72101 A3AA> Fixed Direct Access SCSI-5 device 
pass3: Serial Number       STF602MR3GP2YP
pass3: 300.000MB/s transfers, Command Queueing Enabled
[root@dante /usr/home/bill]# camcontrol standby da3 
(pass3:mpt0:0:5:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 00 00 00 00
(pass3:mpt0:0:5:0): CAM status: CCB request was invalid
[root@dante /usr/home/bill]# camcontrol sleep da3 
(pass3:mpt0:0:5:0): SLEEP. ACB: e6 00 00 00 00 40 00 00 00 00 00 00
(pass3:mpt0:0:5:0): CAM status: CCB request was invalid
[root@dante /usr/home/bill]# camcontrol stop da3 
Unit stopped successfully
[root@dante /usr/home/bill]# camcontrol start da3 
Unit started successfully
```


----------



## mav@ (Apr 8, 2011)

camcontrol standby/sleep (unlike stop/start) use ATA commands to talk to device. For disks connected via SCSI controller (including ones doing ATA->SCSI translation inside) they are not applicable. I have feeling that SCSI has own close alternative for these commands, that could be added to camcontrol, but I am not completely sure.


----------

