Found the problem, SSL LDAP connection - Re: problem with two Intel SSD in Mac Pro

It's been nearly two weeks now with *zero* problems. I'm now confident I found the problem, but it was very strange.

The resolution: Do not use SSL encryption to a Leopard LDAPv3 / Open Directory server from a Snow Leopard client.

-- A re-statement of the problem follows --
A problem report, and a shout out to see if anyone else has seen the like.
After installation of Snow Leopard, this MacPro became unreliable. Manifesting as system hangs requiring a power cycle and unreliable resume from sleep.

Base info, the hardware:
Model Name: Mac Pro
Model Identifier: MacPro3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 3.2 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per processor): 12MB
Memory: 16GB
Bus Speed: 1.6 GHz
Boot ROM Version: MP31.006C.B05
SMC Version (system): 1.25f4

With 2 Intel SSD 150gb drives and one VelociRaptor 300gb:
INTEL SSDSA2MH160G1GN:
One SSD is 50/50 partitioned for Boot Camp and OS X. (Bootable backup OSX system.) Second SSD is a single partition for OS X. (Working OS X system.) Velociraptor is for large working space and large support directories. E.g., VMware virtual machines, Studio Pro supporting data directories, work in progress audio/video files, backups.

This machine and OS had been rock solid since purchased with Leopard in its various revs.

Snow Leopard: (Installed in early September)
Intermittent, perhaps two or three times a week, system hang to begin with. Fairly consistent failure to completely come back into operation from sleep. Frequency of failures seemed to be increasing.

These hangs were not immediate total system freezes, but apparently any running process could continue until its next disk I/O. New Applications, including Terminal, could not be started once the 'hang' started. System could not fully shut itself down when commanded either via the GUI or a "shutdown -r now" command. [Disk I/O was my original hypothesis. Turns out that it must have been until the next auth/permissions check was performed after the failure mode started.]

After weeks of this once rock solid but now unreliable system my patience broke and it was time to start debugging. Including installing a clean SL OS in a new partition and booting both the 32 and 64 bit kernel. After a day of running the system as the 'clean installed' Snow Leopard running various test with zero issues I thought it must just be some problem due to having done an upgrade from Leopard to Snow Leopard and I'll just start installing/configuring everything on this clean system.

Soon after binding the system to the Leopard Server Open Directory the problems were back. This was conclusively proven as the problem by booting back to the 'original' system which had been running Leopard for a long time and was recently 'upgraded in place' to Snow Leopard and deleting what Snow Leopard Client now calls the "Network Account Server" under Preferences | Accounts | Login Options. (This used to be done using the Directory Assistant application in Utilities.)

The resolution: Turned off use of SSL encryption to a Leopard LDAPv3 / Open Directory server from a Snow Leopard client.

There was never anything in system.log on either the client or server clearly pointing out where the problem was. Closest I found was when a hang happened during a Mobile Me Sync and I saw error messages stating that <some file or dir> didn't exist or could not be written to.
-Ron G.

(This reminded me of a recent apple doc on LDAP but the only one I can find (2009) is OS X Server v10.5, 10.6: Enabling iCal server access for users of Active Directory or third-party LDAP servers - now titled "Turn on Calendar for Active Directory and LDAP servers".)

BTW - Had another reader reply to this post he'd also seen the same problem:

"Re: LDAP/Snow Leopard/SSL
I have a similar problem with Active Directory and my MacBookPro (2.6 Ghz Core 2 Duo, 4 GB RAM) on Snow Leopard (10.6.2). Same kind of hangs, requiring using the power button to recover. Just proved it yesterday by binding to Active Directory on a 2008 Win server after several weeks of no problems when I unbound (and it returned within minutes).
-Jack"