February 14, 201115 yr Hello all, I'm new here and this is my first post. I'm using this post to (1) document the various things I've learned here and elsewhere that have worked for me in getting a 3ware 8006 SATA controller to work with unRAID (at least partially), and (2) ask for help in solving my remaining problem: getting the drives to spin down with this controller. I'm currently testing 5.0beta4 on an old desktop that I want to repurpose as a media server. It seems to work well so far, and I am really impressed with both the software and the community support that is available here!! BAckground: I'm trying to use an old RAID card, the 3ware 8006-2LP in JBOD mode. Using the stock install of 5.0beta4, the card was not recognized and the drives were not visible anywhere. With this card, JBOD is enabled by simply not setting up a RAID array in the BIOS. I confirmed JBOD was working OK by booting another OS (WinXP). Working: Loading a Driver Module: After a lot of digging here on the forums I learned that a driver for this card was available as a loadable module residing in this directory: /lib/modules/2.6.36.2-unRAID/kernel/drivers/scsi/3w-xxxx.ko I tested loading the driver at a command prompt using this command and got no errors: modprobe 3w-xxxx So I added the command to the beginning of my "/boot/config/go" script, and performed a cold reboot. Now the card is recognized at boot time ( Yay!!!), and I am able to select and use the drives once unRAID is loaded. Here is a relevant excerpt from the syslog showing the card and 2 x 250GB drives available as /dev/sdb and /dev/sdc: Feb 13 19:17:41 Tower kernel: 3ware Storage Controller device driver for Linux v1.26.02.003. (System) Feb 13 19:17:41 Tower kernel: 3w-xxxx 0000:01:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 Feb 13 19:17:47 Tower kernel: scsi1 : 3ware Storage Controller (System) Feb 13 19:17:47 Tower kernel: 3w-xxxx: scsi1: Found a 3ware Storage Controller at 0xbc00, IRQ: 21. (System) Feb 13 19:17:47 Tower kernel: scsi 1:0:0:0: Direct-Access 3ware Logical Disk 0 1.2 PQ: 0 ANSI: 0 (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/232 GiB) (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:0:0: [sdb] Write Protect is off (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 00 00 00 (Drive related) Feb 13 19:17:47 Tower kernel: scsi 1:0:1:0: Direct-Access 3ware Logical Disk 1 1.2 PQ: 0 ANSI: 0 (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: disabled, supports DPO and FUA (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:1:0: [sdc] 488397168 512-byte logical blocks: (250 GB/232 GiB) (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:1:0: [sdc] Write Protect is off (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:1:0: [sdc] Mode Sense: 00 00 00 00 (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:1:0: [sdc] Write cache: enabled, read cache: disabled, supports DPO and FUA (Drive related) Feb 13 19:17:47 Tower kernel: sdb: sdb1 (Drive related) Feb 13 19:17:47 Tower kernel: sdc: sdc1 (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk (Drive related) Feb 13 19:17:47 Tower kernel: sd 1:0:1:0: [sdc] Attached SCSI disk (Drive related) Working: SMART monitoring. SMART requires a different syntax with 3ware controllers. Instead of /dev/sdb and /dev/sdc it is necessary to use /dev/twe0 and then use the "-d 3ware,0" to reference the first drive, or "-d 3ware,1" to reference the second drive (see examples from "smartctl -h"). Apparently, "twe0" is for 6000, 7000, or 8000 series 3ware controllers, and "twa0" is for 9000 series controllers. I've only tested my 8006 controller here. root@Tower:~# smartctl /dev/twe0 -d 3ware,0 -a root@Tower:~# smartctl /dev/twe0 -d 3ware,1 -a for example, here is the -i output: root@Tower:~# smartctl /dev/twe0 -d 3ware,1 -i smartctl 5.39.1 2010-01-28 r3054 [i486-slackware-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3250620AS Serial Number: 5QE005MP Firmware Version: 3.AAC User Capacity: 250,059,350,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Feb 13 21:31:04 2011 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled root@Tower:~# smartctl /dev/twe0 -d 3ware,0 -i smartctl 5.39.1 2010-01-28 r3054 [i486-slackware-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3250620AS Serial Number: 5QE016H1 Firmware Version: 3.AAC User Capacity: 250,059,350,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Feb 13 21:31:12 2011 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled Although temperature is not reported by the unRAID web management utility, it can be obtained on the command line using "smartctl -a": root@Tower:~# smartctl /dev/twe0 -d 3ware,1 -a | grep Temp 190 Airflow_Temperature_Cel 0x0022 067 049 045 Old_age Always - 33 (Lifetime Min/Max 33/47) 194 Temperature_Celsius 0x0022 033 051 000 Old_age Always - 33 (0 25 0 0) Problem: The drives never spin down. I want to have a reasonably energy efficient system and this is a must for me. The syslog fills up with the following error lines, repeating this block about once every 10 seconds. the spindown commands in the web interface will spin down my IDE/ATA drives but not the drives attached to the 3ware controller. Feb 13 21:53:48 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:53:48 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:53:48 Tower kernel: mdcmd (315): spindown 0 (Routine) Feb 13 21:53:48 Tower kernel: md: disk0: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) Feb 13 21:53:48 Tower kernel: mdcmd (316): spindown 1 (Routine) Feb 13 21:53:48 Tower kernel: md: disk1: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) Feb 13 21:53:58 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:53:58 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:53:58 Tower kernel: mdcmd (317): spindown 0 (Routine) Feb 13 21:53:58 Tower kernel: md: disk0: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) Feb 13 21:53:58 Tower kernel: mdcmd (318): spindown 1 (Routine) Feb 13 21:53:58 Tower kernel: md: disk1: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) Feb 13 21:54:08 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:54:08 Tower emhttp: mdcmd: write: Invalid argument (Other emhttp) Feb 13 21:54:08 Tower kernel: mdcmd (319): spindown 0 (Routine) Feb 13 21:54:08 Tower kernel: md: disk0: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) Feb 13 21:54:08 Tower kernel: mdcmd (320): spindown 1 (Routine) Feb 13 21:54:08 Tower kernel: md: disk1: ATA_OP_STANDBYNOW1 ioctl error: -22 (Errors) I tried issuing the following commands via terminal, but it did not work: root@Tower:~# hdparm -y /dev/sdb /dev/sdb: issuing standby command HDIO_DRIVE_CMD(standby) failed: Invalid exchange I also tried: root@Tower:~# hdparm -y /dev/twe0 /dev/twe0: issuing standby command HDIO_DRIVE_CMD(standby) failed: Inappropriate ioctl for device root@Tower:~# which looks a little better, but still does not work. though hdparm does work to test data speeds (for what its worth): root@Tower:~# hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 1818 MB in 2.00 seconds = 908.56 MB/sec Timing buffered disk reads: 194 MB in 3.01 seconds = 64.46 MB/sec Any suggestions for what I can try next??? ??? Thanks in advance. I'll try to attach my full syslog syslog-2011-02-13.txt
February 14, 201115 yr No suggestions from me. The issue seems to be the controller doesn't pass through the spin-down/spin-up commands to the drives. To alleviate the syslog spamming on spinup/spindown set all drives on that controller to NEVER spindown.
February 14, 201115 yr BRiT said it already, the driver module does not support the IO Control command to spin down the drives. There is some hope based on a recent post from Tom. He is thinking of changing the spin-down code. You might try using hdparm -S242 /dev/sdb hdparm -S242 /dev/sdc To set the timers on the disks themselves.
February 14, 201115 yr Author Thanks for the prompt responses! BRiT said it already, the driver module does not support the IO Control command to spin down the drives. There is some hope based on a recent post from Tom. He is thinking of changing the spin-down code. Oh, well. I suspected it might be a driver/code issue that is out of my control. In this case, I'm going to buy a cheap SATA controller to tide me over until I can invest in better hardware for the long term . Right now, I'm just trying to work with what I have at hand, at minimal expense (of course, I am willing to spend some of my free time!). You might try using hdparm -S242 /dev/sdb hdparm -S242 /dev/sdc To set the timers on the disks themselves. hdparm apparently does not succeed with any command exchange through this controller. I get the same response as above. root@Tower:~# hdparm -S242 /dev/sdb /dev/sdb: setting standby to 242 (1 hours) HDIO_DRIVE_CMD(setidle) failed: Invalid exchange root@Tower:~# hdparm -S242 /dev/twe0 /dev/twe0: setting standby to 242 (1 hours) HDIO_DRIVE_CMD(setidle) failed: Inappropriate ioctl for device To alleviate the syslog spamming on spinup/spindown set all drives on that controller to NEVER spindown. Until I procure a new SATA card, I will probably do this while I continue my testing/exploration of unRAID. Perhaps my findings will be useful to someone. Being new to unRAID/linux, it was not obvious what I should do to test my card and and I was unable to find "newbie level" instructions on how to load the driver module to see what its performance would be like. If nothing else, it has been a challenging problem to think about. Thanks again for the help. I will plan to update here with a link to a new thread after doing some research on cheap PCI (not PCIe!) SATA cards for unRAID.
February 14, 201115 yr Author For posterity, here are my latest unsuccessful investigations (mostly completed before getting the advice above from Brit and Joe L). Note that I'm just poking around to learn about unRAID and have fun and I don't care if I kill my system since its all for testing purposes at this point!! Having observed that there were several other kernal modules in the "/lib/modules/2.6.36.2-unRAID/kernel/drivers/scsi/" directory, I wondered whether I had loaded all the necessary ones? Some are obviously for other card models, but others (e.g. "scsi_transport_sas") sounded like they could be important. I assumed that module dependencies would be automatically loaded, but nothing else was revealed by "lsmod" to be loaded at boot time along with the 3ware driver, so I wasn't sure if this assumption is correct. I tried loading more of them with "modprobe" at boot time, but nothing changed. root@Tower:/boot/tmp# lsmod Module Size Used by md_mod 46913 2 xor 12849 1 md_mod 3w_xxxx 18528 2 p4_clockmod 2236 1 speedstep_lib 2135 1 p4_clockmod ide_gd_mod 11856 2 ata_piix 17268 0 i2c_i801 5620 0 i2c_core 12189 1 i2c_i801 piix 3524 1 For the heck of it, I found a binary release of sdparm in a slackware package, and copied it over to the flash drive. I'm not surprised that it doesn't work either -- I don't think sdparm is very useful today as the current version of hdparm appears to have superseded it for most tasks. Someone please correct me if I'm wrong however. root@Tower:/boot/tmp# sdparm --command=stop /dev/sdb /dev/sdb: 3ware Logical Disk 0 1.2 start stop unit: transport: Host_status=0x04 [DID_BAD_TARGET] Driver_status=0x00 [DRIVER_OK, SUGGEST_OK] root@Tower:/boot/tmp# sdparm -i /dev/sdb /dev/sdb: 3ware Logical Disk 0 1.2 malformed VPD response, VPD pages probably not supported As indicated above, my next step will be to research inexpensive and reliable PCI SATA controllers.
Archived
This topic is now archived and is closed to further replies.