[PATCH] [Kernel] The spontaneous reboot (solution?) thread

Search This thread

toadlife

Inactive Recognized Developer
Aug 19, 2008
1,208
1,012
Lemoore, CA
Both appear to be tied to my lockscreen. I run a random rom 3.2. I'm about to start work so I'll get that info out to you later today as well. Reboots don't bother me too much, but it would be nice to fully squash them.

Per our PM conversation, your logs didn't contain any LAST_KMSG file. I assume this means that the system crashed/rebooted so quickly that the kernel had no time to flush the log buffer to disk. Maybe your charging cable is flaky and there was a short?

Anyhow, to anyone else, the file you need to pull after experecing an unexpected reboot/shutdown is the one with "LAST_KMSG" in the file name and it will be located in /data/system/dropbox.
 

toadlife

Inactive Recognized Developer
Aug 19, 2008
1,208
1,012
Lemoore, CA
So, I didn't have a freeze this time, but rather a shutdown. It appears to have been connected to a failed system update. Any thoughts?

Sent from my Epic 4G

Edit: the shutdown on my phone was between 4:15 and 4:30. Is it possible that the updates/system itself is causing the freezes and reboots/shutdowns?

To get an idea of what happened, I would need the LAST_KMSG files from /data/system/dropbox
 

jeffro18

Senior Member
Jun 3, 2011
531
119
Illinois
Per our PM conversation, your logs didn't contain any LAST_KMSG file. I assume this means that the system crashed/rebooted so quickly that the kernel had no time to flush the log buffer to disk. Maybe your charging cable is flaky and there was a short?

Anyhow, to anyone else, the file you need to pull after experecing an unexpected reboot/shutdown is the one with "LAST_KMSG" in the file name and it will be located in /data/system/dropbox.

Well I just had another one, this time off charge. The only remaining thing I can find in common with all 3 is that it happens while waking the phone with the power button. None of the reboots, including the few I had on samurai 2.0.8 froze up before rebooting the android system. I have experienced those as well on various leaked builds and earlier samurai builds, but have not seen them with any kernel with your patches. The logs I indicated possibly being related to the lockscreen must mean something else. I guess if I knew what they meant I would not have had to send them to you :)

As we talked in the pms, I will be sure to keep my eye on those logs from now on. Thanks for taking a look at them for me.

Sent from my SPH-D700 using xda premium
 

521

Senior Member
Jul 11, 2010
171
33
Baytown, Texas
To get an idea of what happened, I would need the LAST_KMSG files from /data/system/dropbox

Can you send me an email address that I can send file to? Board email is not allowing attachments nor is PM that I can find.

Thanks.


Edit: I'm using stock CleanGB rom and the latest kernel that Toadlife provided. No oc/uv.

On another note though, we were asked to supply feedback from the OP...Nobody said it was his rom or kernel creating the issues. My understanding was that he was trying to track down the reboot/shutdown issue with the Epic 4G to create a patch - something nobody else has been able to do. Fear not though, I won't waste my time providing any more feedback or comments since this seems to always be an issue for a few members on this site.

If I am misinterpreting what i'm reading, my apologies for that too. Just getting tired of seeing people getting their a**es jumped in all these threads for nothing, just because people have nothing nice to say.

Thank you for your hard work, Toadlife. Good luck.
 
Last edited:

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
to throw in my $0.02, using samurai 2.0.8 which includes your patches in my rom, aside from installation data issues relating to working with backups, reboots have been non-existent even dealing with the 4G and those reporting any reboots have been strictly related to data corruption or incompatibility

-- in integrating and testing the lockscreen mod from scratch (not counting TSMParts - strictly lockscreens) in SleeperROM, i explicitly decided not to include it because it adds variable instability depending on too many things - not to mention an increased chance of data incompatibilities when restoring from backups, so while it's a neat way to customize the phone at will, it could potentially be detrimental so it's an unfortunate decision between customizability and stability.

And overclocking/undervolting -- i should add, reboots/shutdowns have been heavily reported for even slightest undervoltages on some phones. I know it should be obvious, but i've personally experienced a random reboot and in investigating the problem, had forgotten that i was playing with the cpu clock/voltage settings.. and it wasted a couple of hours on a wild goose chase when the solution was to return the clock settings to default since my phone can't handle it.
 
Last edited:

jeffro18

Senior Member
Jun 3, 2011
531
119
Illinois
Can you send me an email address that I can send file to? Board email is not allowing attachments nor is PM that I can find.

Thanks.

I just sent him a link to my public dropbox folder in the pm.

So I just got home and checked the logs on the lady's phone, which as a nearly identical setup to mine, and see that she has none of the SYSTEM_LAST_KMSG logs since running kernels with your patches. There are 5 of them in there, but from previous samurai kernels. I cleared all of mine before running this kernel, so that is why none were present in the log I sent last night(As you know from my pm). It shows she had one reboot, but similar to the one's I have reported. It seems as though this has fixed the 10-15 sec lock up and reboot type.

I do know the stable values for uv/oc on these two devices, but made sure to retain stock values for this test, and really have not found a need to overclock on gb for my uses. I always wipe data, cache, and dalvik before flashing roms and do not restore data on my device. I sometimes restore minimal data (texts) on hers, but try to keep things as clean as possible.

Please know that I only post here to help the community and better my understanding of this device.

Sent from my SPH-D700 using xda premium
 

jeffro18

Senior Member
Jun 3, 2011
531
119
Illinois
Yeah, I should clarify that if you are messing with frequencies or voltages, I don't want to hear about your reboots here. ;)

In my experiences, unstable uv/oc settings have only caused a full reboot or would not wake from screen off, not just the android system reboots. I don't think the quick android system reboots that I am having will ever be fully "fixed", as there are so many various reasons to cause them as stated a few posts above. At least when running highly modded custom roms. I do think your efforts were successful in squashing these specific types of reboots as described in the op.

Sent from my SPH-D700 using xda premium
 

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
Yeah, I should clarify that if you are messing with frequencies or voltages, I don't want to hear about your reboots here. ;)

indeed, that's just a whole other can of worms. but i think the clarification is absolutely necessary in debugging, as some don't realize the impact it can have until there is a problem that is hard to track down - so many things to point a finger to.
 

k0nane

Inactive Recognized Developer
Feb 7, 2008
3,991
3,783
127.0.0.1
www.k0nane.info
Lovely, got my first spontaneous reboot on EI22. Haven't patched my kernel yet, will do so later - but I'm going to pull kmsg and lastkmsg and attach them here before I forget. Consider this a placeholder for now, I'll read through the logs a bit later to see if there's any new info.

EDIT: last_kmsg added; I'll have to grab the current one after a (requested) reboot. Forgot to cat kmsg as the device booted. It appears that I may have ran into a WiMAX bug - and also, I forgot to chmod /system/vendor/bin in my updater-script. D'oh.
 

Attachments

  • lastkmsg.txt
    64.3 KB · Views: 9
Last edited:

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
Lovely, got my first spontaneous reboot on EI22. Haven't patched my kernel yet, will do so later - but I'm going to pull kmsg and lastkmsg and attach them here before I forget. Consider this a placeholder for now, I'll read through the logs a bit later to see if there's any new info.

EDIT: last_kmsg added; I'll have to grab the current one after a (requested) reboot. Forgot to cat kmsg as the device booted. It appears that I may have ran into a WiMAX bug - and also, I forgot to chmod /system/vendor/bin in my updater-script. D'oh.

i had a good two releases plagued with poorly set permissions, once i straightened all that out no one has reported a reboot even on 4g ... actually i take that back, the browser reboot, i can't track that one down to fix it, and i can't cause one so i can't diagnose it.
 

Djinn23

Senior Member
Oct 23, 2010
390
29
reproduicible issue

Hello all.

I posted the story here in the cleangb thread but the short of it is as follows:

I experienced an issue on a kernel with the toolchain updates (b17) of cleangb. I read some are saying there is a hardware issue but I did not have any such issues on pre-gb builds.

The situation was that I was adding an accesspoint while connected to 4g and both were on at the same time and I locked then rebooted. Noted the same pre-toolchain fix this AM where I was entered into a flurry of reboots while 4g and wifi were both on at the same time. I may have grabbed it late but logs attached.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    I've been getting occasional random reboots EI22, and I've seen reports in the general forum of the same.

    There seem to be two main causes of reboots:


    WIFI Related (bcm4329 DHD Bus Module TX Queue overflow)​
    The reboots always happen when WIFI is on. The system will freeze up hard for about 10-15 seconds and then just reset. The LAST_KMSG file shows 60KB of nothing but the following:

    Code:
    [ 5315.816399] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.820979] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.825411] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.829922] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.834499] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.838929] dhd_bus_txdata: out of bus->txq !!!
    [ 5315.843505] dhd_bus_txdata: out of bus->txq !!!


    OneDram driver related reboots​

    After patching the WIFI related bugs I started to get these more often. Here is an example of the log leading up to the reboot.

    Code:
    [   13.319028] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1
    [   13.339579] [OneDram] dpram_drop_data, head: 319, tail: 319
    [   13.351715] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1
    [   13.366965] [OneDram] dpram_drop_data, head: 319, tail: 319
    [   13.379178] [OneDRAM](dpram_write) Failed to get a Semaphore. sem:0, PHONE_ACTIVE:HIGH, fail_cnt:1

    Another log sample from a reboot, right before it restarts...
    Code:
    [   11.585629]
    [   11.585665] dpram_shutdown !!!!!!!!!!!!!!!!!!!!!
    [   11.590957]
    [   11.590986] dpram_shutdown ret : 0
    [   11.598695] Restarting system.
    [   11.600629] KERNEL:magic_number=0 CLEAR_UPLOAD_MAGIC_NUMBER
    [   11.608974] arch_reset: attempting watchdog reset

    For the WIFI issue, I searched and found a set of patches on the linux driver project mailing list that address this issue.

    See: http://driverdev.linuxdriverproject.org/pipermail/devel/2011-March/012948.html

    After applying the patch verbatim I still got the WIFI related reboots, so I slowly pushed the TXQLEN values up until the reboots stopped. Here is the commit from my github that contains the patch that seems to have done the trick.

    As for the OneDRAM related reboots, I think I may have found the solution to these too. The problem seems to have gone away when I switched the specific ARM toolchain that is mentioned in the Samsung kernel source README. Previously I was using the 4.4.x toolchain from Googles repo. Thanks to Earthbound for working with me on this one. Aside from Earthbound (he uses the recommended Codesourcery one), I don't know what toolchains others use, but I do know that I have not had one reboot in the four days since switching to the CodeSourcery toolchain.

    Here is a kernel (source) with the WIFI fix that was compiled with the 2009-q3-68 toolchain. Aside from the WIFI fix, the kernel contains the following features:



    • root/su/busybox
    • init.d script support
    • bootanimation.zip support
    • overclock to 1.4/voltage control
    • keyboard delay fix
    • ext4/rfs support
    • CWM5/ROM Manager support (reboot bml8 recovery)

    If you are having WIFI or dpram/onedram related reboots, you might want to give this kernel a try and report back.

    NOTE: If you overclock or over/under volt please stop doing so if you want to test this kernel and post logs.
    3
    Lovely, got my first spontaneous reboot on EI22. Haven't patched my kernel yet, will do so later - but I'm going to pull kmsg and lastkmsg and attach them here before I forget. Consider this a placeholder for now, I'll read through the logs a bit later to see if there's any new info.

    EDIT: last_kmsg added; I'll have to grab the current one after a (requested) reboot. Forgot to cat kmsg as the device booted. It appears that I may have ran into a WiMAX bug - and also, I forgot to chmod /system/vendor/bin in my updater-script. D'oh.
    2
    by competing, i don't mean as in a contest, i mean that i wouldn't want to work on anything that someone else has already in the works, is all.

    i do think devs see their effort as a contest for superiority which hinders everyone in the process - there needs to be a bit more transparency involved, like - not to stoke an old fire but "IAP samurai's" latest source should be checked in/available by this point, which makes possible a comparison of upstream/stock/rodderick's vs nubernel vs samurai's to get at each of their strengths for a unified kernel since everyone focuses on their area of enjoyment (i.e. frequency tuning)

    i feel like some of the mods that were ported or kept along from EH17 and earlier may or may not bring with them old bugs or the mods are being made without consideration or attention to what other areas they will affect (adding/editing one feature damages another), since i presume the fully stock kernel doesn't have these issues? but that's the price of improvement, it's just that with more eyes and expertise allowed to approach an issue, the more well rounded it becomes. i know you know this, i was just clarifying my stance.

    as far as the reboot issue, it's so sporadic that i haven't yet caught it again since discussing... it only happened for the first time yesterday, but it occurred multiple times, which was a cause for alarm so i'm still looking out for it.



    It has been random and rare, a special combination of two radios (3g/wifi, 4g/wifi) coming on at once before either has an address at a certain time such as during media scanning during startup where everything is momentarily slow (before the launcher is responsive). Also on 4g when browsing internet with stock browser (with very low 4g signal, where i'm assuming it's going to drop/rescan), i haven't looked at logs but saw your post in other thread about this so i dunno.

    Coming to think of it, could this be solvable with some sort of timeout or brief pause, considering that most mods aim to solve lag or remove delays, maybe some delay is required in the preamble to establish a connection.. or actually, in how the network chain prioritized, as in 3g > 4g > wifi (if they are all enabled) because of the apparent conflict - perhaps a ConnectionManager/android.net issue (as noted when switching on Wifi while still connected to 4g, wifi connects > 4g disconnects > 4g pops up momentarily trying to connect and goes away again when wifi gets its IP) probably having nothing to do with the kernel...

    any thoughts?

    EDIT: This is all really only happening to me with enabling/disabling wimax... and it's getting nastier with every reboot (currently it just rebooted, then hung at the bootanim till i pulled the battery then it was fine... if i leave 4g off, i have no problem

    IAP won't even listen to the community's suggestions anyways.
    i tried to get some sort of failsafe for noobs and all these crazy overclocks
    and was told it was just garbage.

    also I've only had few reboots. and one was when i had first flashed a increment update from CleanGB. which in since was in sync with what you guys describe about both 3g and wifi being on. but I also think maybe could data sync's/activation of 3g/4g could be apart of this? cause i noticed on certain roms i couldn't data sync while using wifi, orr that wifi would interrupt the data sync on 3g which would cause the double signal's and therefore sometimes cause a reboot.
    2
    to throw in my $0.02, using samurai 2.0.8 which includes your patches in my rom, aside from installation data issues relating to working with backups, reboots have been non-existent even dealing with the 4G and those reporting any reboots have been strictly related to data corruption or incompatibility

    -- in integrating and testing the lockscreen mod from scratch (not counting TSMParts - strictly lockscreens) in SleeperROM, i explicitly decided not to include it because it adds variable instability depending on too many things - not to mention an increased chance of data incompatibilities when restoring from backups, so while it's a neat way to customize the phone at will, it could potentially be detrimental so it's an unfortunate decision between customizability and stability.

    And overclocking/undervolting -- i should add, reboots/shutdowns have been heavily reported for even slightest undervoltages on some phones. I know it should be obvious, but i've personally experienced a random reboot and in investigating the problem, had forgotten that i was playing with the cpu clock/voltage settings.. and it wasted a couple of hours on a wild goose chase when the solution was to return the clock settings to default since my phone can't handle it.
    1
    @ toadlife...
    Mtd may actually solve these random reboots, because we won't be using samsung's onedram driver.

    sent from my always aosp epic