[AT&T Samsung Galaxy S II Skyrocket SGH-I727] Da_G:
Problem with SoD is that it is present in the stock configuration, just not exposed as often as when overclocking is introduced. See here for one thread about it (this concerns the T-Mobile SGS II, but it is running a nearly identical kernel/chipset/ROM): http://code.google.com/p/android/issues/detail?id=21607

Root of the problem is unknown, but the conditions to trigger it are somewhat known, if the phone enters deep sleep, after a random period of time the CPU continues functioning normally but no longer responds to the normal wake methods. Compiling with the latest codesourcery branch triggers a different type of SoD (it occurs 100% of the time, and won't ever wake to a power button press, but will to USB/charger connection) - and with gcc 4.6.2 SoD never occurs (but neither does deep sleep)

I don't personally get the SoD issue at all, so that makes it quite tricky to debug on my end! This is one reason I exposed all the voltage tables, I suspect voltage may play a part, hoping someone who experiences SoD can try with increased voltages/decreased L2 speed :)

Feel free to branch off 0.3, the source has always been available, I update it with every test build I push to IRC testers :) The more eyes on it the better! Right now I am injecting a whole bunch of debug code into the sleep/wake codepaths to try to track down the issue. This is something qualcomm/samsung are fully aware of, and occurs in their own source trees judging by debug code present in the kernel, I'm quite sure! Difference is they have at least 2 phones available so they can plug one into JTAG and get JIT debugging output from the kernel when it gets into that state and I don't! (not that it has helped them fix it yet, hehe)

Re: the current sysfs interface being compatible, it functions nearly identically to the existing sysfs interface for voltage, but there is no "sysfs interface discovery" process for the kernel, so all of the apps simply have no idea that it exists. It is entirely up to the app devs to add support for it, I wouldn't hold my breath as the code currently exists on exactly 1 kernel for one device, and you are here :) I hate Java to the point I can 100% guarantee it won't be me working on it! The info in logcat is not terribly helpful to this, /proc/kmsg and /proc/last_kmsg are marginally helpful, but not so much without mountains of added debug code (which I am working on adding) - if you would like to help test IRC is always there :)

As far as the phone exploding into flames, check the source, I have added sanity checks across the board, you would be hard pressed to accidentally type an extra zero and have it explode, as the kernel would simply lock it to the maximum voltage/speed which has tested safe (1.6v from stock 1.225v)

So to summarize, there are 2 currently known bugs with the kernel (both of which I cannot duplicate locally so can't really address at the moment): SoD and an issue with the MHL adapter mentioned earlier. I use this kernel as my daily driver and don't have an MHL adapter/don't experience SoD. SoD work-around is simply disabling deep sleep (which will also murder your battery in standby)