[Samsung Epic 4G Touch] mkasick:
OK, here's where I am so far:

First, if it's not already well known, the SPH-D710_Opensource.zip sources posted on opensource.samsung.com are not the sources for EG30.

For one, the release kernel was built on 7/30, but the source tree dates from 9/9 with a modified westbridge driver on 9/15. Aside from that one driver, the rest of the source dating from 9/9 is inconclusive--we can't tell exactly when the tree was modified before then, but it's unlikely to have been modified after.

Next, I took the EG30 kernel and a clean build of the open source kernel, blank out the initramfs from both, ran "strings | sort -u" and diffed the outputs of both (the garbage is spurious). There's a fair number of strings unique to the open source release, not all of which can be explained by kernel config differences. As an example, the string "tty driver == NULL!", found in dpram.c in the open source release doesn't exist in EG30, and isn't #ifdef'd to a config option. So there's at least some modifications to the dpram driver and perhaps others.

I didn't look too deeply into the source modification issues beyond that. I can't say whether any of these changes are relevant to bugs observed in open source kernel builds or not. But it does mean we're off to an unfortunate start in attempting to narrow down these isues.

Second, I found it troubling that in frifox's initial bug report the phone never suspends for longer than 60 seconds. It's often awoken exactly at 60 seconds. It took me a while to figure out the source of the interrupt, but I believe it's "max8997-irq" which is the power controller. I recently realized that each of frifox's bugreports was taken while the phone was charging (right?). I'd be a bit interested in seeing a bug report when the phone has been off the charger for a while, to see if it suspends longer, but it's entirely plausible that the phone wakes up once a minute to ensure charging conditions are OK.

The second thing I found troubling were the suspend loops where the phone would repeatedly try to suspend, fail, and kick itself back out every two seconds. Initially I thought that suspending and resuming the radio so quickly might be the source of LoS, however it looks like the suspend loops are the result of LoS. The two devices that cause suspend to fail are "dpram-device" and "alarm", the former which is definitely a result of LoS, the latter of could be related. I've not seen frequent "alarm" suspend failures in isolation, so I wouldn't worry about it unless it also happens outside of LoS.

Third, the most obvious symptom of LoS from the dmesg log is the device attempting to suspend repeatedly, specifically attempting to suspend the radio, and failing to do so. The first instance when this happens appears to correspond with the loss of radio/data connectivity, but prior to the RIL/UI indicating there's a problem.

I checked the relevant code in dpram.c to see if there was any obvious locking issue that might cause this. For example, if the kernel tells the radio to suspend at the same time the radio sends a message to the kernel/RIL. No code yet stands out to suggest there is a synchronization issue here, and unfortunately much of dpram debug messages are disabled.

We could trace through this further by compiling a kernel with all the debugging enabled (it can't be done at runtime), but I'd like to confirm first that a synchronization issue while suspending is the cause here. It might simply be that a bug in the radio firmware is triggering LoS and this is the first we're witnessing it Android-side. Though I think that's a strange explanation, given the disparity between the stock kernel and custom kernels and the frequency with which the problem is encountered.

So, my suggestion:

Grab a bugreport when the phone is off the charger, LoS or not. It probably won't tell us anything new, but would satisfy my curiosity.

After, try the "echo foo > /sys/power/wake_lock" workaround to disable suspending and see if LoS still happens. If it goes away for a long time, but comes back (some time) after a reboot, then we know it's related to suspending. If LoS happens with the workaround, then it's not. If LoS does happen with the workaround, grabbing another bug report would be very helpful.