There appears to be a bug in the CAM interface layer which prevents the driver from queueing multiple outstanding commands to an array. A fix is being tested.

In other news, I'm working on support for the Linux-binary array manager software from Mylex. More news once it's working.

Just in time for the FreeBSD 4.2 release, the 'mly' driver has been merged back into FreeBSD-stable. All currently-shipping Mylex adapters should now be supported for out-of-the-box installation.

After a lot of testing last night, I've cut a new BETA for the 'mly' driver. There were several 'sniper' bugs which showed up if the module was being loaded at boot time or statically compiled into the kernel, and the mechanism for probing for connected devices has been improved.

There is still no management support, but you can use 'camcontrol inquiry' to check the status of array drives, as the inquiry data is now updated when events are reported by the controller.

Mylex sent me some more data last week, and I finally realised how their status monitoring interface actually works. So now there's a new driver available that understands what the controller is saying when it reports status changes. I've tweaked a few other bits inside as well. SCSI passthrough is still not working (I'm not sure what's going wrong here; I can't get it working on the AMI driver either), but just about everything else is right.

I need someone with a 4.x system to test the driver out and give me a more detailed problem report. Right now I don't have enough hardware to build and maintain a 4.x system, so I can't track down what might be wrong with this driver there.

For a while now, I've been getting complaints from owners of older adapters with 2.x firmware which only have I/O-mapped register windows. When I was adding support for this firmware family to begin with, I inferred that these controllers were extremely rare, and I could safely ignore them.

Not so! So many complaints have rolled in that I've done something about it (it wasn't really all that hard, I must confess), and the driver has been updated to support these adapters as well. There's a patchkit for users with these controllers wanting to install the 4.1-RELEASE here, follow the instructions inside and enjoy!

Quite some time ago, Mylex supplied me with a set of evaluation units for their new adapter family. One thing and another got between me and making them work, but I've finally resolved the issues and I'm happy to announce the first BETA of a driver providing support for the AcceleRAID 160, 170 and 352 as well as the eXtremeRAID 2000 and 3000. These adapters require a completely new driver, as their software interface is entirely incompatible with the previous families.

I've received a couple of bug reports from people that have seen the driver spin endlessly emitting the "error reading message log" diagnostic. I finally managed to duplicate this in captivity, and found a race condition that could occur if the controller was busy resetting a SCSI bus and the periodic event polling code fired off more than one attempt to read the event log. The fix is in -current, waiting on review before putting it into -stable.

Spoke with the good folks at Mylex today; they've loaded me down with three new controllers and yet another new firmware interface. This one "tries to look more like a SCSI device". Apparently this was meant to make the NT and Solaris drivers simpler; it's certainly going to make life interesting around here. The older firmware interfaces (v2-5) are a great match for our block I/O subsystem. This new change will probably require interaction with CAM - time will tell, I guess.