JAC kernel bug: using audio randomly kills phone

---

(I figured to post this in Android Development as it wasn't really a fit for any other forum; and made its own thread since multiple ROMs and threads use non-stock kernels.)

I ran into an issue running JAC's OC/UV kernel, as detailed at http://forum.xda-developers.com/showthread.php?t=806116 . Essentially, whenever any kind of audio was playing, whether through headphones or the speaker, local media (i.e. mp3 player) or remote (i.e., Pandora), at some point the phone would just.. die. Capacitive buttons wouldn't light up, no unlock; music would die; and basically a battery pull was required to turn the phone back on. adb logcat reports nothing - you can see the audio streaming, then the logcat shut off with the phone.

Based on the thread above (and searching the Bionix thread), it seems that a non-stock kernel does this. (There are only a couple of posts out of the thousands on Bionix's thread.) I have not tested KingKlick's kernel, only JAC's; perhaps KK doesn't suffer from this. This issue is independent of overclocking/underclocking the phone (verified by setting JAC kernel to 1000/200, then uninstalling setcpu); Voodoo lagfix (verified by disabling lagfix and running audio for about an hour); and ROM (tested using multiple versions of Franken-Twiz and Hybrid - maybe there's an inherent issue with eugene's mods, but I haven't seen any other posts.)

I suppose this thread serves as a warning/bug report for anyone that might encounter this issue if running a non-stock kernel. The best way to resolve AFAIK is to revert to a stock kernel.

Thank you for posting this! My phone had suffered from this at random times since I started using JAC's kernel. I asked about it in a couple of threads but never got a single reply. Glad to know it's not only me :)

I'm running the same kernal and about 20 minutes ago running pandora my phone just turned off too and had to pull the battery to restart

Sent from bionix 1.9.1 jacs oc/uv kernel

Had that issue at the Gym the other day, not even on Bionix.

I had similar issues, also with the KK Kernel, its not just JAC's kernel. You don't have to pull the battery either to get out of the freeze, you can hold the power button for several seconds and it does a hard reset.

I have found though that the KK Kernel is less likely to do it if you set your setcpu to 400 min and 1000 max before using pandora. Those settings seems to have worked for me every time..also after setting up pandora make sure to fix permissions with rom manager.

Just a little work around, try it to see if it works for you.

Sent from my SGH-T959 using XDA App

Actually this is a known problem since even the G1.

If you have anything like setCPU, which I do, and you set the idle or lowest speed lower then 400 Mhz the phone will more then likely freeze up when playing music or when going to idle.

I don't remember off the top of my head what causes it to do this when it goes below that certain Mhz, but Im sure I or someone here can dig the old thread up.

Man without this thread I could never get pandora to work with a custom kernal. I setcpu at 400 min and 1000 max and not a single freeze. Thanks so much for posting that tip, you made my day.

Sent from my SGH-T959 using XDA App

Ive had this problem to.... but it was ONLY with Jacs 1.1, I revert every ROM back to his 1.0 and have no problems. Everytime I dont, I get a phone freeze.

I was having this problem with jac's newest kernel so I went back to his first OC/UV, it is a known problem and he's working on it according to his twitter. how I got around this is I used his OC script and got rid of setcpu, from what Quadrant says I'm still running 100/1200. Hope that helps you guys

Originally Posted by jmercil

I have found though that the KK Kernel is less likely to do it if you set your setcpu to 400 min and 1000 max before using pandora. Those settings seems to have worked for me every time..also after setting up pandora make sure to fix permissions with rom manager.

Interesting. I'll try installing JAC OC/UV/Voodoo again and see if this observation is consistent.