[KERNEL]Droid DNA Cubed Kernel Stock/System Write/Unsec ADB[01.23.13]Added HSIC fix

Search This thread

iOSh8er

Senior Member
Dec 30, 2010
632
178
Hephzibah
Get permission like you said earlier, its the right thing to do.

Please don't touch my "Thanks" button, it doesn't like you... ;)
 

Danzoman

Senior Member
Oct 9, 2010
515
75
Columbia SC
Imho not releasing it is about $. Why would D do all this work for free,something that one of qualcoms engineers who probably makes a 6 figure income to steal and implement in a future ota. Make them fix it.


But at the end of the day I hope all is ok and we can benefit from this soon.

Via Viper DNA Beta
 

elkay

Senior Member
Apr 6, 2005
693
285
github.com
What exactly is causing the msm_hsic_host wakelock issue? Just curious.

Bug in Qualcomm's code that was originally delivered to Google for the Snapdragon S4 Pro processor that is causing wakelocks on cellular activity. It's preventing the phone from going or staying in deep sleep, which is why "Phone idle" is so low in battery statistics. Qualcomm has since fixed it with a couple patches, but there's no word from HTC as to when (or if) we'll see the fix delivered via OTA. Most people think the standby battery life is good considering the size of the battery and they just don't know any better. The Nexus 4 is experiencing the same issue.

---------- Post added at 04:12 PM ---------- Previous post was at 03:58 PM ----------

Imho not releasing it is about $. Why would D do all this work for free,something that one of qualcoms engineers who probably makes a 6 figure income to steal and implement in a future ota. Make them fix it.


But at the end of the day I hope all is ok and we can benefit from this soon.

Via Viper DNA Beta

It's not dsb's nor my patch. It's a patch directly from Qualcomm. You can't blame Qualcomm or Google at this point, either, as the fix has been accepted and merged into Google's repository. From this point forward, it's up to HTC to merge the patches into their source and deliver it to Verizon for testing, so the ball is now in one of their courts. I'm simply doing the latter part on my own with a custom kernel. dsb hasn't responded to my PM yet, but his repository only has the system write change in it and is otherwise the same as the kernel source that HTC posted for everyone to work off of, so in the end I don't think it will be a big deal that I forked from this kernel's source as long as I give him credit for the system write change. It only saved me the step of pushing the completely stock HTC source and then merging in his one system write change. If I took his Cubed kernel with all the mods he's already done to that one and tried to call it my own, that would be a different story.
 

Danzoman

Senior Member
Oct 9, 2010
515
75
Columbia SC
Bug in Qualcomm's code that was originally delivered to Google for the Snapdragon S4 Pro processor that is causing wakelocks on cellular activity. It's preventing the phone from going or staying in deep sleep, which is why "Phone idle" is so low in battery statistics. Qualcomm has since fixed it with a couple patches, but there's no word from HTC as to when (or if) we'll see the fix delivered via OTA. Most people think the standby battery life is good considering the size of the battery and they just don't know any better. The Nexus 4 is experiencing the same issue.

---------- Post added at 04:12 PM ---------- Previous post was at 03:58 PM ----------



It's not dsb's nor my patch. It's a patch directly from Qualcomm. You can't blame Qualcomm or Google at this point, either, as the fix has been accepted and merged into Google's repository. From this point forward, it's up to HTC to merge the patches into their source and deliver it to Verizon for testing, so the ball is now in one of their courts. I'm simply doing the latter part on my own with a custom kernel. dsb hasn't responded to my PM yet, but his repository only has the system write change in it and is otherwise the same as the kernel source that HTC posted for everyone to work off of, so in the end I don't think it will be a big deal that I forked from this kernel's source as long as I give him credit for the system write change. It only saved me the step of pushing the completely stock HTC source and then merging in his one system write change. If I took his Cubed kernel with all the mods he's already done to that one and tried to call it my own, that would be a different story.

Sorry I thought he personally fixed it. Never mind then lol :p

I wasn't insinuating you were stealing, but it wouldn't be fair for paid engineers to steal from someone that does this as a hobby.
Via Viper DNA Beta
 

elkay

Senior Member
Apr 6, 2005
693
285
github.com
Sorry I thought he personally fixed it. Never mind then lol :p

I wasn't insinuating you were stealing, but it wouldn't be fair for paid engineers to steal from someone that does this as a hobby.
Via Viper DNA Beta

Nope. A lot of the patches applied by devs for all of these Android devices are straight from manufacturers. That's the pro/con of an open source project. While the paid engineers occasionally benefit from the work of volunteers, us end users also benefit from the volunteers fixing problems that the engineers might have taken longer to fix on their own. Also, when the handset is not locked down, we can test and have these fixes before carriers push the updates through their lengthy approval process.

A small setback - my data connection dropped and I had to reset my phone to get it back. Apparently this has been happening with other kernels including those with CM10 on other devices, and those kernel devs are backing out their HSIC changes. I'm in contact with a dev that has the msm_hsic_host fixes in place and doesn't have the data drops, and he's saying it's because there are a few additional patches that have been released that those devs may not have applied that could be fixing that small data drop issue. Rather than revert (no point as that's my only real change so far) I'm going to start applying additional patches to see if I can come up with the one(s) that fix that issue. I'll still release the kernel in its current state, but likely as 0.9.0 instead of 1.0.0 because of this known issue. It may not affect everyone (apparently it has something to do with LTE handshakes between towers), so perhaps some people won't even experience the issue. They're just beginning to deploy LTE by me and it was while I was just leaving my house area that it happened, so I would tend to believe that's the reasoning. According to VZ's LTE map, LTE is within a mile of reaching my house now.

Anyway, just wanted to give you the update. At least there are no lockups or reboots, I'm pretty certain of that now. It's just that the initial release will have a little asterisk/warning next to it now. I'll keep digging for you guys until I get to the bottom of it.
 
Last edited:
  • Like
Reactions: spinkick

ML417

Senior Member
Jul 26, 2012
387
70
Long Island, NY
Nope. A lot of the patches applied by devs for all of these Android devices are straight from manufacturers. That's the pro/con of an open source project. While the paid engineers occasionally benefit from the work of volunteers, us end users also benefit from the volunteers fixing problems that the engineers might have taken longer to fix on their own. Also, when the handset is not locked down, we can test and have these fixes before carriers push the updates through their lengthy approval process.

A small setback - my data connection dropped and I had to reset my phone to get it back. Apparently this has been happening with other kernels including those with CM10 on other devices, and those kernel devs are backing out their HSIC changes. I'm in contact with a dev that has the msm_hsic_host fixes in place and doesn't have the data drops, and he's saying it's because there are a few additional patches that have been released that those devs may not have applied that could be fixing that small data drop issue. Rather than revert (no point as that's my only real change so far) I'm going to start applying additional patches to see if I can come up with the one(s) that fix that issue. I'll still release the kernel in its current state, but likely as 0.9.0 instead of 1.0.0 because of this known issue. It may not affect everyone (apparently it has something to do with LTE handshakes between towers), so perhaps some people won't even experience the issue. They're just beginning to deploy LTE by me and it was while I was just leaving my house area that it happened, so I would tend to believe that's the reasoning. According to VZ's LTE map, LTE is within a mile of reaching my house now.

Anyway, just wanted to give you the update. At least there are no lockups or reboots, I'm pretty certain of that now. It's just that the initial release will have a little asterisk/warning next to it now. I'll keep digging for you guys until I get to the bottom of it.

have you tried charging the phone overnight? that seemed to be the most common occurrence of reboots.
try having a clock on (i use desk dock personally) and have it on all night while charging.
 

elkay

Senior Member
Apr 6, 2005
693
285
github.com
have you tried charging the phone overnight? that seemed to be the most common occurrence of reboots.
try having a clock on (i use desk dock personally) and have it on all night while charging.

Yep, 2 nights of charging overnight. I had reboots 3 times overnight on the Cubed kernel, and no reboots yet on mine with the HSIC patches. I'm confident it's not going to freeze or reboot in its current state. Just need to track down that loss of signal fix.
 

S121Guy

Senior Member
Mar 30, 2011
110
8
I think u need to make your own own thread :)
Would be easier to track your updates.
Plus I would hate to see others getting upset over thread jacking.

sent from my rooted DNA
 

Top Liked Posts

  • There are no posts matching your filters.
  • 29
    Okay folks. I built this for those of you who prefer to be on a mostly stock kernel.

    It is all stock except you can write to /system, and adb shell as root.

    I will not be modifying, maintaining, updating, or otherwise doing anything else with this.

    If you are coming from my other kernel, you need to flash the return to stock zip in the OP of that thread first to restore your files.

    Enjoy!

    Droid DNA Cubed System Write Stock Kernel
    MD5: 78dba0c85090d89fd681269a09140e5f

    D

    .
    13
    Thread unlocked. Links up.

    D

    .
    7
    Added the HSIC fix to this so the stock folk can save some battery.

    D

    .
    5
    Can you make an overclock version too?

    The end goal would be to include that, too. My primary focus is absolute stability, so overclocking won't be coming right away (but it will be on the short list). Since I'm going to have to follow the GPL in order to provide the kernel to you guys, I'm going to go official and set it up on github which might take a couple days since I'm also busy with a few real life things at the moment, too. I'm going to be splitting off from this thread for the release since it won't be this "stock" kernel anymore and I'm getting dsb's ok to include his system write patch in it. Between getting the source on github and ensuring that I've tested the stability thoroughly myself, I'm going to say probably Friday I'll start the new thread with my kernel ready for download.
    4
    Hey dsb, I know you said you weren't going to maintain this kernel nor provide individual modifications to it, but is there *any* way you could compile this kernel with just the battery fix also in it from the other kernel? I would normally agree that individual requests would become overwhelming, but that fix isn't just a random feature request. It's an actual bug in the stock kernel that should really be addressed by HTC but obviously you beat them to it. It might also be a good test to see if that fix is what is causing the freezing problem on the other kernel, since the best way to test that (unfortunately) is probably going to be testing kernels by either inclusion of changes on stock, or exclusion of changes on modded. As a developer myself, I totally understand the frustration in tracking down bugs that can't be easily reproduced by any one given method. If you'd like someone to test the extra change, I'll gladly volunteer my device.

    I understand if you don't want to fulfill this request, and no hard feelings if you can't or don't want to. Really appreciate all you've already done.