TRIM command failure causes system to lock up

S

shadowsall

Hello,

I am currently creating a ZFS storage server. I'm using a Sun Ultra 40 M2 and I added a few bits of needed hardware.

I'm using an Adaptec-PMC ASA-78055 for my host adapter
4x WD RE 4TB HDDs
2x Intel 2500 Pro 120 GB SSDs

My problem:

Whenever I try adding an ssd to my ZFS array, a TRIM command is issue to the SSD and a nastry error is printed to the console and from that point the system is no longer responsive and must be hard reset.

My error looks something like this, but with drive names tweaked.

Code: 
da0 at pmspcbsd0 bus 0 scbus0 target 0 lun 0
da0: <ATA INTEL SSDSC2BW24 DC32> Fixed Direct Access SCSI-5 device 
da0: Serial Number PHDA438604NW2403GN 
da0: 600.000MB/s transfers
da0: Command Queueing enabled
da0: 228936MB (468862128 512 byte sectors: 255H 63S/T 29185C)
da0: quirks=0x8<4K>
(da0:pmspcbsd0:0:0:0): ATA TRIM failed, disabling BIO_DELETE
(da0:pmspcbsd0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0d 06 00 01 00 01 00 00 00 00 00 00 40 06 00 
(da0:pmspcbsd0:0:0:0): CAM status: SCSI Status Error
(da0:pmspcbsd0:0:0:0): SCSI status: Check Condition
(da0:pmspcbsd0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(da0:pmspcbsd0:0:0:0): Command byte 0 bit 0 is invalid
(da0:pmspcbsd0:0:0:0): Error 22, Unretryable error

Does anyone know what might be causing this? Is it a driver issue? Is the kernel issuing a faulty trim command?

Thanks in advance.
 
I don't have an answer to the cause but does setting sysctl vfs.zfs.trim.enabled=0 or sysctl vfs.zfs.vdev.trim_on_init=0 and result in being able to successfully add the SSD?
 
shadowsall said:
Code: 
da0 at pmspcbsd0 bus 0 scbus0 target 0 lun 0
da0: <ATA INTEL SSDSC2BW24 DC32> Fixed Direct Access SCSI-5 device
da0: Serial Number PHDA438604NW2403GN
da0: 600.000MB/s transfers
da0: Command Queueing enabled
da0: 228936MB (468862128 512 byte sectors: 255H 63S/T 29185C)
da0: quirks=0x8<4K>
(da0:pmspcbsd0:0:0:0): ATA TRIM failed, disabling BIO_DELETE
(da0:pmspcbsd0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0d 06 00 01 00 01 00 00 00 00 00 00 40 06 00
(da0:pmspcbsd0:0:0:0): CAM status: SCSI Status Error
(da0:pmspcbsd0:0:0:0): SCSI status: Check Condition
(da0:pmspcbsd0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(da0:pmspcbsd0:0:0:0): Command byte 0 bit 0 is invalid
(da0:pmspcbsd0:0:0:0): Error 22, Unretryable error

Does anyone know what might be causing this? Is it a driver issue? Is the kernel issuing a faulty trim command?
Click to expand...
What is the pmspcbsd0 controller? We don't seem to have any device with that name in the source tree and Google doesn't return anything informative, either. Where did you get that driver, and did you build it from source or install a pre-built one from somewhere?

It looks like some type of RAID controller, as it says "COMMAND PASS THROUGH" which means that it isn't acting on this command itself, but "sending it down" to lower layers to the drive.

In general, what you are seeing is typical when buggy hardware "lies" and says "Yes, I support feature X" when queried, but when you actually try to use feature X, it goes "Whoa! I have no idea what you're talking about!". Given that Intel is not exactly a no-name brand;), I would tend to blame the controller and not the drive.
 
The driver is probably a binary only driver from Adaptec if I'm not completely wrong and it's not available from FreeBSD source tree, any problems in the driver are probably very hard to get addressed since it's closed source. Given how ZFS works I'd say the hardware RAID capabilities on that Adaptec card are going to waste, I'd switch it to a simple HBA that uses a driver from the FreeBSD source tree. You'll probably have more luck with getting TRIM working properly that way.
 
Hmm, odd, I thought the driver was in the kernel source, but it seems to the contrary. At any rate, I'm using the the Driver for 9.2, but I'm running 9.3... perhaps this is causing some issues. My firmware is also up to date.

Oh, looks like I forgot to trow the "H" on the end of the model, it is an ASA-7805H, so there is no built in RAID capability.

I'm going to try Junovitch's suggestion and see if that will at least get my by until I can sort this issue out.
 
I did as junovitch suggested, I can now add the SSDs to my pool. So I'm up at least. Now to figure out what the issue is. It sounds like I'll be calling Adaptec...
 
Are you perhaps trying to use some sort of USB/SATA bridge in the setup? Device da0 would point at USB disk device. Usually one gets /dev/da0 after inserting USB stick. Correct me if I am wrong but TRIM command does not translate over USB/SATA bridge and in such case, problem you are running would be perfectly natural.
 
You must log in or register to reply here.
Back
Top