I have a couple development servers running centos 6.3 64bit that have LSI 9211-8i SAS2 controllers connected to a SAS2 backplane. these work fine with SATA hard disks (populated with a bunch of 3TB SATA drives)...
I'm trying to install a OCZ Vertex3 SSD on each of the two servers to do some ssd caching tests... system sees the drive, so I do the following...
# parted -a min /dev/sdu parted> mklabel gpt parted> mkpart primary ext4 2048s -1s parted> q # mkfs.ext4 /dev/sdu1
and it hangs at 'Discarding device blocks: 0/58607505' which I gather is related to 'trim' aka 'discard'.
iostat shows this drive as 100% busy with no activity, and 1 pending operation in the IO queue.
every 30 secs or so /var/lkog/messages gets...
Oct 3 12:48:42 svfis-sg2 kernel: sd 0:0:22:0: attempting task abort! scmd(ffff88062c893d80) Oct 3 12:48:42 svfis-sg2 kernel: sd 0:0:22:0: [sdu] CDB: Write same(16): 93 08 00 00 00 00 00 00 08 00 00 40 00 00 00 00 Oct 3 12:48:42 svfis-sg2 kernel: scsi target0:0:22: handle(0x001e), sas_address(0x500304800191d8e3), phy(35) Oct 3 12:48:42 svfis-sg2 kernel: scsi target0:0:22: enclosure_logical_id(0x500304800191d8ff), slot(23) Oct 3 12:48:42 svfis-sg2 kernel: sd 0:0:22:0: task abort: SUCCESS scmd(ffff88062c893d80)
and after a few of those, I see...
Oct 3 12:49:12 svfis-sg2 kernel: INFO: task mkfs.ext4:3545 blocked for more than 120 seconds. Oct 3 12:49:12 svfis-sg2 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 3 12:49:12 svfis-sg2 kernel: mkfs.ext4 D 0000000000000000 0 3545 3304 0x00000080 Oct 3 12:49:12 svfis-sg2 kernel: ffff88062bbfbc28 0000000000000086 0000000000000000 ffff88062a8f6938 Oct 3 12:49:12 svfis-sg2 kernel: 0000000000000201 0000000000000003 ffff88062bbfbbc8 ffffffff81248cfa Oct 3 12:49:12 svfis-sg2 kernel: ffff88062b699ab8 ffff88062bbfbfd8 000000000000f4e8 ffff88062b699ab8 Oct 3 12:49:12 svfis-sg2 kernel: Call Trace: Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff81248cfa>] ? __elv_add_request+0x4a/0x90 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff814edf15>] schedule_timeout+0x215/0x2e0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff812503c2>] ? generic_make_request+0x2b2/0x5c0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff814edb93>] wait_for_common+0x123/0x180 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff8105ea30>] ? default_wake_function+0x0/0x20 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff8125075f>] ? submit_bio+0x8f/0x120 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff814edcad>] wait_for_completion+0x1d/0x20 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff812574a2>] blkdev_issue_discard+0x152/0x1e0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff81257e8f>] blkdev_ioctl+0x65f/0x6e0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff811aefcc>] block_ioctl+0x3c/0x40 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff81189682>] vfs_ioctl+0x22/0xa0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff81189824>] do_vfs_ioctl+0x84/0x580 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff81189da1>] sys_ioctl+0x81/0xa0 Oct 3 12:49:12 svfis-sg2 kernel: [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
we're not running the /latest/ kernel, looks like its 2.6.32-220.17.1.el6.x86_64 so if thats significant, I can try an update.
for what its worth, the SSD"s seem to work fine plugged into a 9261-8i sas2 megaraid on the same backplanes, but I want to do my caching tests without the raid controller in the way.
anynone else seem issues like this with el6 and SSD on SAS ?
On 10/03/12 12:59 PM, John R Pierce wrote:
# mkfs.ext4 /dev/sda1and it hangs at 'Discarding device blocks: 0/58607505' which I gather is related to 'trim' aka 'discard'.
and exactly the same behavior with the latest kernel 2.6.32-279.9.1.el6.x86_64 and e2fsprogs-1.41.12-12.el6.x86_64
sd 0:0:0:0: attempting task abort! scmd(ffff880c30635080) sd 0:0:0:0: [sda] CDB: Write same(16): 93 08 00 00 00 00 00 00 08 00 00 40 00 00 00 00 scsi target0:0:0: handle(0x000a), sas_address(0x50030480018fcc6c), phy(12) scsi target0:0:0: enclosure_logical_id(0x50030480018fcc7f), slot(0) sd 0:0:0:0: task abort: SUCCESS scmd(ffff880c30635080) sd 0:0:0:0: attempting task abort! scmd(ffff880c30635080) sd 0:0:0:0: [sda] CDB: Write same(16): 93 08 00 00 00 00 00 00 08 00 00 40 00 00 00 00 scsi target0:0:0: handle(0x000a), sas_address(0x50030480018fcc6c), phy(12) scsi target0:0:0: enclosure_logical_id(0x50030480018fcc7f), slot(0) sd 0:0:0:0: task abort: SUCCESS scmd(ffff880c30635080) sd 0:0:0:0: attempting task abort! scmd(ffff880c30635080) sd 0:0:0:0: [sda] CDB: Write same(16): 93 08 00 00 00 00 00 00 08 00 00 40 00 00 00 00 scsi target0:0:0: handle(0x000a), sas_address(0x50030480018fcc6c), phy(12) scsi target0:0:0: enclosure_logical_id(0x50030480018fcc7f), slot(0) sd 0:0:0:0: task abort: SUCCESS scmd(ffff880c30635080)
On Wed, Oct 03, 2012 at 02:18:13PM -0700, John R Pierce wrote:
On 10/03/12 12:59 PM, John R Pierce wrote:
# mkfs.ext4 /dev/sda1and it hangs at 'Discarding device blocks: 0/58607505' which I gather is related to 'trim' aka 'discard'.
and exactly the same behavior with the latest kernel 2.6.32-279.9.1.el6.x86_64 and e2fsprogs-1.41.12-12.el6.x86_64
firmware issue?
http://forums.servethehome.com/showthread.php?867-OCZ-vertex4-imcompatible-w...
Tru
On 10/03/12 2:35 PM, Tru Huynh wrote:
On Wed, Oct 03, 2012 at 02:18:13PM -0700, John R Pierce wrote:
On 10/03/12 12:59 PM, John R Pierce wrote:
# mkfs.ext4 /dev/sda1and it hangs at 'Discarding device blocks: 0/58607505' which I gather is related to 'trim' aka 'discard'.
and exactly the same behavior with the latest kernel 2.6.32-279.9.1.el6.x86_64 and e2fsprogs-1.41.12-12.el6.x86_64
firmware issue?
http://forums.servethehome.com/showthread.php?867-OCZ-vertex4-imcompatible-w...
hmm, not sure thats this problem, as the drive seems to work fine as long as I don't use "Discard' aka "SSD trim"...
I've just updated the SAS2 card bios and firmware to the latest, so lets see what happens when I reboot... AHHHH, that fixed it :-/
for future reference...
9211_8i_Package_P14_IR_IT_Firmware_BIOS_for_MSDOS_Windows\Firmware\HBA_9211_8i_IR\2118ir.bin and 9211_8i_Package_P14_IR_IT_Firmware_BIOS_for_MSDOS_Windows\sasbios_rel\mptsas2.rom
flashed using Installer_P14_for_Linux\sas2flash_linux_i686_x86-64_rel\sas2flash
(the linux package3 doesn't include the firmware, so you need to download the windows package too). the IR firmware supports raid while the IT firmware is just a jbod HBA. my cards were already "IR" even though I'm not using that feature, so I saw no reason to force the restricted firmware on them.
to flash it after you collect the files you need:
# chmod +x sas2flash # ./sas2flash -b mptsas2.rom ..... # ./sas2flash -fwall 2118ir.bin ....
resulting versions are...
# ./sas2flash -listall LSI Corporation SAS2 Flash Utility Version 10.00.00.00 (2011.05.13) Copyright (c) 2008-2011 LSI Corporation. All rights reserved
Adapter Selected is a LSI SAS: SAS2008(B2)
Num Ctlr FW Ver NVDATA x86-BIOS PCI Addr ----------------------------------------------------------------------------
0 SAS2008(B2) 14.00.01.00 0e.03.00.05 07.27.00.00 00:06:00:00
Finished Processing Commands Successfully. Exiting SAS2Flash.
ok, now I can move forward. this had be stymied for 24 hours... I've not run into any problems where I had to update HBA firmware for years and years and years.
-
John R Pierce -
Tru Huynh