AHCI SDD problem
-
Hello All! Long time user, first time poster. My problem is that with pfSense v2.1 my msata SSD is not found when enabling AHCI. I have verified that AHCI is enabled in BIOS and BIOS can see the drive without issue. Using AHCI is a requirement as I need to enable TRIM on the drive. I have searched and read through the enabling AHCI and TRIM posts niether of which document any issues with msata drives not being found when using the ahci kernel module. My current hardware config is located below. Please let me know if I can provide anymore information.
MB: Intel DQ77KB
CPU: Pentium G620
SDD: Crucial M550 128Gb
RAM: 4GB
pfSense v2.1.4 x64 -
No idea why mSATA would not work in 2.1.4. Can you post applicable output from dmesg?
You could try 2.1.3 just to be sure it's not a regression, or better yet, try out a 2.2 snapshot. 2.2 is based on FreeBSD 10.0, and is much more up to date wrt hardware support than 2.1.x. I've been using it in production for a few months now, it's quite stable for me.
-
Charlie,
I will give v2.2 a try and let you know how it goes. As far as dmesg, I can provide nothing as the system will not boot with AHCI enabled. it will not detect any GEOM devices, but it will boot fine if I remove the ahci_load="YES" from /boot/loader.conf.local.
-
Charlie,
I have loaded pfSense 2.2Alpha build from 6/26. I cannot get the ahci to load. First I added "ahci_load="YES"" to /boot/loader.conf.local, that did not work. checked /boot/kernel and saw there was no ahci.ko module so I grabbed the FreeBSD 10.0 ISO and copied the ahci.ko from there to /boot/kernel, still no dice. Appreciate any help that anyone can offer.
P.S.
AHCI output from dmesg:ahci0: <intel panther="" point="" ahci="" sata="" controller="">port 0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf060-0xf07f mem 0xf7d32000-0xf7d327ff irq 19 at device 31.2 on pci0
ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich5: <ahci channel="">at channel 5 on ahci0
ahciem0: <ahci enclosure="" management="" bridge="">on ahci0
(aprobe0:ahcich5:0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00
(aprobe0:ahcich5:0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich5:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich5:0:0:0): RES: 51 04 00 00 00 40 00 00 00 05 00
(aprobe0:ahcich5:0:0:0): Retrying command
(aprobe0:ahcich5:0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00
(aprobe0:ahcich5:0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich5:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich5:0:0:0): RES: 51 04 00 00 00 40 00 00 00 05 00
(aprobe0:ahcich5:0:0:0): Error 5, Retries exhausted
ada0 at ahcich5 bus 0 scbus0 target 0 lun 0
ses0 at ahciem0 bus 0 scbus1 target 0 lun 0</ahci></ahci></intel> -
Hmm … if you see ahci in dmesg at all, then the driver is already present in the kernel and you do not need to load any module. I know it's built in for 2.2, and I'm pretty sure it's already built in for the 2.1 series since 2.1.3 (though I don't have one handy to check).
Anyway, the achi driver is finding the port just fine, communicating with the drive, and then the drive aborts in response to a particular command, twice. The driver then decides the device is broken and ignores it.
Is this a Samsung SSD perhaps?
Seems likely the issue is the one here:
http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070813.html and confirmed here:
https://dan.langille.org/2013/02/06/benchmarking-the-samsung-ssd-840-pro-series/There's a kernel patch to fix the issue, but it
may not beseems that it's already in the pfSense kernel.Short of building your own patched kernel, you can verify that this is the issue by
Some other things to try:- Change bios settings for the port to legacy mode rather than ahci. I don't know if mSATA support is possible without ahci though. If not, then:
- Or temporarily put the SSD on a standard SATA port in legacy mode
- Or boot a live CD of FreeBSD 9.2 or 9.3 RC (which we know has that fix) and see if the drive is detected.
- Try the SSD in a different machine, or with a linux liveCD in that machine
- Try a different SSD
Hope this helps …
-
Charlie,
Sorry for the long wait for reply, currently the drive is detected and it is running and it did run under v2.1.4 just never with the ahci_load="YES". I assumed the AHCI was not loaded in v2.2 as the device is listed as an ada device under /dev which is how v2.1.4 loaded it. Also trim refuses to enable, I have tried touching /root/TRIM_set to no avail. Is there another way to set trim to enabled? I tried "tunefs -t enable /" but it says that it cannot write the superblock. I assume due to the fact the device is mounted as R/W. I was about to try and boot from liveUSB and use it to set trim without mounting the device but am unsure if this will work. Thanks again for all the help. I am also looking into the suggestions you gave earlier about the drive error. I am not sure if Crucial uses Samsung chips or not.
P.S. Found a Dutch site that mentions a bug in FreeBSD 10 AHCI module with Crucial drives. Below is the Google translate link for the page, mentions the same issue I am having and that the issue did not exist in 9.1/9.3.
http://translate.google.com/translate?hl=en&sl=nl&u=http://gathering.tweakers.net/forum/list_messages/1452380/23%3Fdata%255Bfilter_keywords%255D%3DZFSguru%26data%255Bboolean%255D%3D&prev=/search%3Fq%3Dcrucial%2Bm550%2B%2522CAM%2Bstatus:%2BATA%2BStatus%2BError%2522%26biw%3D1920%26bih%3D945
P.P.S. I also noticed that there is a rather big byte difference between the ahci.ko module included with pfSense 2.1.4 and the one on the FreeBSD 8.3 LiveCD. Would you see any issues with replacing the pfSense module with the one from the FreeBSD LiveCD?
-
You need ahci in order to set trim; trim is not supported under the ATA driver. At least that was the case in FreeBSD 8.x, and I assume it's the same in FreeBSD 10.0.
The code that looks for /root/TRIM_set has been removed in pfSense 2.1.2 (or 2.1.3, not sure), with no good reason that I could see, and no replacement code. Workaround is to boot to single user mode (from the menu), then "tunefs -t enable /". You are right it cannot be mounted, but you can use single user mode rather than a live cd. This eliminates any way for an administrator to set TRIM on a remote box.
I don't think your problem that Samsung bug, as that was supposedly fixed already, but the error looks similar. Would be interesting to see if a recent linux live CD would find the crucial SSD in ahci mode; same for a FreeBSD 11.0 development nightly, though neither one would really help you get it going under pfSense
I can't explain the module file size difference, unless one of them includes debugging symbols, or you are inadvertently comparing i386 to amd-64 archs. Functionally there should not be any difference between pfSense 2.1.4 ahci.ko and the same FreeBSD 8.3 module.
-
Is the SSD running the latest firmware?
-
Charlie,
Thanks for the info about single user mode, I will try that shortly and if TRIM set fine I will ignore the CAM status bug as all the information I can find about that exact error is for power management. As for v2.1.4 and FreeBSD you are probably right about the debug symbols being in use on the FreeBSD copy. I made sure I was comparing x64 to x64 for ahci.ko. I will keep you all posted as to whether single user mode works.
NOYB,
It is running the latest firmware, unfortunately the M550 drives are fairly new and there are no update, it is stuck at MU01 until Crucial releases something. -
Charlie,
I will give v2.2 a try and let you know how it goes. As far as dmesg, I can provide nothing as the system will not boot with AHCI enabled. it will not detect any GEOM devices, but it will boot fine if I remove the ahci_load="YES" from /boot/loader.conf.local.
Did you convert fstab to ufslabel before adding ahci_load="YES" ?
Run the following script to do it:
/usr/local/sbin/ufslabels.shthen if it boots correctly go in single user mode and enable TRIM with:
/sbin/tunefs -t /reboot with:
/sbin/rebootand after a reboot check if it's enabled with:
tunefs -p / -
Chralie,
Your advice about using single user mode to enable TRIM worked perfectly. I also disabled advanced poer management in BIOS and now the CAM status error has also disappeared. Thanks for the assistance, I am all good now.