How do I install a commercial driver?

I know this is an old thread. But I'm having a similar problem after upgrding to FreeBSD 10.1. My drives become 'Removed' and my pool nearly got messed up.

I was running the mpslsi from LSI website on FreeBSD 8.3 for 2 years without any problems. NO I'm using the mps in the 10.1-RELEASE base.

After hunting around, it seems that whilst the firmware can be newer than the driver, the other way around causes major problems. Particularly with SATA drives. So basically, we need to update the firmware before updating any drivers, and it must be same versions or higher than the driver.

I will wait for my pool to finished resilvering, then flash the firmware with version 20, and use the mpslsi version 20 driver from their website. Despite that driver beeing build for FreeBSD 10.0. I'll take the risk it works on 10.1, since the ABI compatability _should_ be OK. If I have any further issues, I'll probably build it from source (again from LSI website).

My super stable 8.3 experience was with the mpslsi. I can't remember, but I think I had issue with the base mps on 8.3 as well. Or perhaps there was no mps in base at at that time, can't remember.

Oh LSI, thanks for these shananigans! I had done a perfect upgrade / migration and then I had shutdown servies for half a business day. Not to mention having a severe panic attack whilst watching my data pool break down severely.
 
I will wait for my pool to finished resilvering, then flash the firmware with version 20, and use the mpslsi version 20 driver from their website. Despite that driver being build for FreeBSD 10.0. I'll take the risk it works on 10.1, since the ABI compatability _should_ be OK. If I have any further issues, I'll probably build it from source (again from LSI website).
Click to expand...

Well I wrong about that. The latest mpslsi driver from LSI website causes the system to reboot instantly. Even when compiled from source. I guess they haven't updated it for FreeBSD 10.1 yet.

I updated my firmware to version 20.0.2.0 and the mps in 10.1-RELEASE base is based on LSI's 19.0 driver version.I still get the SCSI / CAM errors. Although not yet had a drive dropped out.

It appears to be probleM with SATA drives and SAS expanders (JBOD), with regards to timeouts. Perhaps it's also related to my WD black's firmware.

At the moment I'm pretty screwed, the data pool is in production AND it could bail out any minute. I am too tired to continue, after 2 days with no sleep. It's crazy! Both my hba card (LSI SAS 9200-8e) and my JBOB array are from LSI. The later being rebranded by Supermicro. Both products are supposed to support SATA, and yet it clearly got MAJOR stability issues. It plain doesn't work. I was told LSI was good for FreeBSD.
 
ethoms said:
Well I wrong about that. The latest mpslsi driver from LSI website causes the system to reboot instantly. Even when compiled from source. I guess they haven't updated it for FreeBSD 10.1 yet.
Click to expand...

The problem is that unlike the stable API/ABI for userland software, FreeBSD does not have a stable KPI/KBI (kernel programming/binary interface). This means the hardware vendor who wants to provide FreeBSD drivers for their products has to update their drivers for every single minor release of FreeBSD. Commercial OSes such as Windows do have stable KPI/KBI and that's why you can expect that a driver for let's says Windows 7 will work on Windows 7 and even on Windows 8 even after hundreds of updates to the OS.
 
Thanks kpa, that's interesting. It amazes me how well Microsoft have done at keeping Windows API/ABI compatibility for so long. On the other hand, I will never willingly use it again, for anything. Unices all the way, despite any shortfalls.

I managed to resolve my HBA controller issues. It was the firmware version after all.

Thanks to Borja Marcos email (https://lists.freebsd.org/pipermail/freebsd-scsi/2014-October/006506.html) in some FreeBSD mailing list, it was indicated that downgrading to version P19 solves the CAM / SCSI errors and timeouts.

So to recap, my problems started by upgrading to 10.1-RELEASE, using the base mps driver (based on the LSI P19 driver). At that time I was on firmware version P16. Then I upgraded to firmware version P20 and still had the same problems. Only after downgrading to P19 did my problems go away instantly. It's also worth noting that the following settings in /boot/loader.conf help with SATA drives in SAS arrays:
Code: 
# Change I/O queue settings to play nice with SATA NCQ and
# other storage controller features.
vfs.zfs.vdev.min_pending="1"
vfs.zfs.vdev.max_pending="1"
Also not that when flashing the LSI firmware, do a sasflsh -o -e 6 to erase the existing firmware and NVDATA. This means using the DOS flash util, not the FreeBSD one. I recommend using a FreeDOS USB image, found here: http://chtaube.eu/computers/freedos/bootable-usb/
After using dd to load the image on your USB memstick, copy the sasflsh.exe file and the firmware ROM file to the USB drive. Boot into it and perform the erase, then the flash. Also note that many modern Intel chipsets will give an error when trying to use sasflsh. I had to move the HBA controller card to another machine to perform the erase/flash.

I'm not 100% convinced the controller is working perfectly now, but it's made a huge difference at least. Time will tell. I'll try to report back after a few weeks of use.
 
To follow my issue, which is still ongoing, you may refer to another thread: https://forums.freebsd.org/threads/what-happened-to-vfs-zfs-vdev-max_pending.50591/.

In summary, currently it looks like my issue may be due to mixing SAS and SATA drives in the same enclosure. Somehow the above settings (workaround) in /boot/loader.conf made me get away with it on FreeBSD 8.3.

However, I'm unsure if a similar trick, by turning sata ncq queueing down to 1 via camcontrol tags da? -N 1 is also helping solve the issue.
 
You must log in or register to reply here.
Back
Top