After unpacking, racking, and mounting the JBOD, I waited until the weekend had started before powering down the server and installing the RAID card. Connected it all up, rebooted into the Adaptec BIOS, and configured the 6x 1TB drives into a RAID6 array. After that, I installed the RAID StorageManager off of Sun’s website, and then the “Common Array Manager” software. CAM is supposed to provide a web GUI to an organization’s worth of Sun JBODs, so you can update JBOD firmware and query status and whatnot from a single interface. There’s client and server bits written in Java that run on the various boxes, so the data path was going to look like this:
JBOD -> XEN dom0 running remote proxy tool -> XEN domU running web GUI
I say “was going” and “supposed to” because all the remote proxy tool in CAM ended up doing was consistently triggering a kernel panic in the aacraid driver whenever it’s detection code fired up.
Take a long drag off the irony of driver and firmware issues, and download the latest-n-greatest aacraid driver and firmware from Intel via Sun, and update. Same results. Repeat in various configurations, and before throwing in the towel, get a basic dump and file a bug. I didn’t put any more serious thought into debugging it simply because this whole thing has to be up and running yesterday, and the last time I asked for documentation on the topic, I was rebuffed with a variant of this classic: “If you were smart enough to debug the kernel, you wouldn’t need documentation on how to debug the kernel.”
Take a moment to stand in awe of the massive poisonous cobaggery involved in that statement being offered to someone who wants to help fix a crasher. I’ll wait.
That kind of shit would never fly in any GNOME venue, which is why GNOME kicks so much ass.
Update: The cobaggery about kernel development did not come from Sun or any representative of any company involved in open-source, and was unrelated to this situation at all. I relate it simply as it pertains to debugging kernel issues, and why I don’t do it.