[SOLVED in 2.3.6] Gingerbread 2.3.5 JQ3/JQ4 (soft) reboot issues (random + MicroSD)

[daniel.weck]

UPDATE: [SOLVED] Looks like the GingerBread 2.3.6 ROM fixed this issue.

When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).

So, quite simply, I just insert the MicroSD card once the device is completely booted
UPDATE: sometimes the reboot occurs in this case too, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!

Additional note: the MicroSD is perfectly stable when connected in USB transfer mode.

----------

Stock JQ3 has been rebooting randomly on my Tab (no obvious error message in logcat, disabled overclocking/undervolting, Koxudaxi or Overcome kernels, RFS or EXT4 filesystem)...sometimes I can use the Tab for days without problems, but today it keeps rebooting (with or without any interaction from my part).

UPDATE: confirmed with JQ4 too.

The logcat reveals that the watchdog detected a
system-process deadlock, and forced a full restart of the Android
runtime. Here's what [/data/anr/traces.txt] says for .ServerThread (system_server):

"android.server.ServerThread" prio=5 tid=10 SUSPENDED
  | group="main" sCount=1 dsCount=0 obj=0x4050fc58 self=0x2f34a8
  | sysTid=12309 nice=-2 sched=0/0 cgrp=default handle=3093984
  at java.util.HashMap$HashIterator.hasNext(HashMap.java:~791)
  at java.util.AbstractCollection.toArray(AbstractCollection.java:356)
  at com.android.server.PackageManagerService.getInstalledPackages(PackageManagerService.java:2385)
  at android.app.ContextImpl$ApplicationPackageManager.getInstalledPackages(ContextImpl.java:2186)
  at com.android.server.BackupManagerService.allAgentPackages(BackupManagerService.java:966)
  at com.android.server.BackupManagerService.addPackageParticipantsLocked(BackupManagerService.java:874)
  at com.android.server.BackupManagerService$1.onReceive(BackupManagerService.java:836)
  at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:709)
  at android.os.Handler.handleCallback(Handler.java:587)
  at android.os.Handler.dispatchMessage(Handler.java:92)
  at android.os.Looper.loop(Looper.java:130)
  at com.android.server.ServerThread.run(SystemServer.java:673)

"android.server.ServerThread" prio=5 tid=10 SUSPENDED
  | group="main" sCount=1 dsCount=0 obj=0x4050fc58 self=0x2f34a8
  | sysTid=12309 nice=-2 sched=0/0 cgrp=default handle=3093984
  at java.lang.String.compareTo(String.java:~60)
  at java.util.ComparableTimSort.mergeLo(ComparableTimSort.java:650)
  at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:447)
  at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:370)
  at java.util.ComparableTimSort.sort(ComparableTimSort.java:178)
  at java.util.ComparableTimSort.sort(ComparableTimSort.java:142)
  at java.util.Arrays.sort(Arrays.java:1974)
  at com.android.server.PackageManagerService.getInstalledPackages(PackageManagerService.java:2388)
  at android.app.ContextImpl$ApplicationPackageManager.getInstalledPackages(ContextImpl.java:2186)
  at com.android.server.BackupManagerService.allAgentPackages(BackupManagerService.java:966)
  at com.android.server.BackupManagerService.addPackageParticipantsLocked(BackupManagerService.java:874)
  at com.android.server.BackupManagerService$1.onReceive(BackupManagerService.java:836)
  at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:709)
  at android.os.Handler.handleCallback(Handler.java:587)
  at android.os.Handler.dispatchMessage(Handler.java:92)
  at android.os.Looper.loop(Looper.java:130)
  at com.android.server.ServerThread.run(SystemServer.java:673)

More information here:

http://www.google.co.uk/search?q=reboot+Sending+signal+WATCHDOG+KILLING+SYSTEM+PROCESS

 

[theerachai]

I got reboot whenever I enable wifi.
Hadn't test anything more than this.
Reverse back to dxjpj asian rom

 

[daniel.weck]

Yes, I realized Wifi would potentially be the cause of the problem, so I am in "flight" mode with both wifi and cellular off.

 

[daniel.weck]

This is clearly a "system_server" reboot (i.e. the adb connection via USB to my laptop remains alive), so I can capture the system logs even whilst the system is rebooting. Here's some info I found in a mailing list:

Runtime restarts are almost always for one of two reasons:  either a
component running in the system_server process has crashed outright,
or something has caused the system_server's process primary looper
thread to deadlock.  The deadlock case is announced by a line in the
logcat buffer reading something very like this:

04-04 14:06:16.888   885  1089 W Watchdog: *** WATCHDOG KILLING SYSTEM
PROCESS: null

I'm going to talk about the NON-deadlock cases first; they're simpler
to diagnose:  just look in the logcat trace for the messages about the
system process crashing.  There will be a Dalvik stack trace there to
the point at which the fatal exception was thrown, and you then know
where to go looking for the bug.  As always, the event log and the
primary text log contain different information; both are useful for
reviewing the state and activity of the device leading up to a crash.

If the crash *was* due to a deadlock, things get a little interesting.
 When the watchdog declares a deadlock and forcibly kills the system
process, it first captures the current stack trace of every
system_server process thread into the usual ANR stack trace file
(/data/anr/traces.txt on most devices).  This file is automatically
included in a bugreport -- yet another reason to pull a full bugreport
rather than just logcat.

Look at the timestamp of where the watchdog declared a problem.  In
the example line I gave above, it was 04-04 14:06:16.888.  That tells
you which set of stack traces you're interested in within the "LAST
ANR" section of the bugreport.  Find the system_server stack dumps
that were captured at the time of the watchdog's message.  For
example, in the bugreport that my example came from, the "LAST ANR"
section was headed:

------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-04-04 14:06:14) ------

and the file holds *two* sets of system_process stacks.  One of them
starts like this:

----- pid 885 at 2011-04-04 14:05:42 -----
Cmd line: system_server

and the second starts like this:

----- pid 885 at 2011-04-04 14:06:12 -----
Cmd line: system_server

Note that the first was taken 30 seconds before the second, and the
second was just a few seconds before the watchdog message about
killing the system process to restart the system.  The watchdog takes
a thread snapshot after 30 seconds of the looper being unresponsive,
then another snapshot after a full minute of unresponsiveness; and
it's after that full minute that it declares the deadlock and restarts
everything.  You probably want to start with the later thread stacks,
the ones that reflect the state of affairs when the watchdog finally
gave up.

In most Android applications the primary looper thread is called
"main", but this is *not* true of the system_process.  The primary
system_process looper thread is titled "android.server.ServerThread".
Find that thread's stack trace that was taken at the time the watchdog
declared the deadlock, and you'll be off and running as far as
diagnosing what has caused that looper thread to be unresponsive for >
60 seconds.

At this point you've got the information you need to figure out what
locks are being contended for, what unapproved long-running operations
might be mistakenly being run on the system process's main looper,
etc.  Dalvik's stack dump output is very useful, especially since it
tells you things like which other thread currently holds a lock being
requested.

 

[af974]

Finally, so it's not my custom rom that cause random reboots to some users.
The strange thing is that not everyone get this issue, me for example, have not none a reboot since i've flashed it.

Daniel, did you have this problem in pure stock jq3?
Meant without overcome kernel installed.

Anyway, you should have this issue with jq4 too, since there are less differences between both versions.

 

[daniel.weck]

I'm not sure how to Heimdall-flash the JQ4 PDA tar over the ext4 partition? (since I installed Overcome, which aggressively converted /system and /data from RFS to EXT4 without any user-prompt).

Ok, that was simple: I flashed [factory.rfs] from JQ4 using Heimdall without repartition (and with the usual PIT file), and on reboot the Overcome kernel automatically converted to EXT4 once again (a short 2 minutes process, as my /data partition had already been converted before). The APKs are now being Odex'ed (Dalvik cache reset)...waiting...

I hope this will fix the reboot issue. UPDATE: no

 

[daniel.weck]

Finally, so it's not my custom rom that cause random reboots to some users.
The strange thing is that not everyone get this issue, me for example, have not none a reboot since i've flashed it.

Daniel, did you have this problem in pure stock jq3?
Meant without overcome kernel installed.

Anyway, you should have this issue with jq4 too, since there are less differences between both versions.

As soon as I installed stock JQ3, I had a couple of reboots, however the ROM "became" stable rapidly and I enjoyed using the Tab for a number of days without any major issues. All this time, I was using Koxudaxi's build (overclocked, undervolted). Today, I updated some apps using the Market, I launched ezPDF and the system then entered this reboot frenzy! I went into flight mode to eliminate potential wifi/radio issues, I removed the overclocking/undervolting, and finally I switched to the Overcome kernel (just to try something different)...to no avail.

I have now flashed JQ4 [factory.rfs], but the system is rebooting again. Frustrating!!

I'm going through /data/anr/traces.txt again, hoping to find the culprit...

 

[teacher1960]

I was running stock froyo for the longest time, almost a year. I had huge problems with random reboots. Typically two-three days with frequent reboots followed by a week or two with few or no reboots.
I related the reboots mostly to two different things.
One was sim related and even though I had a new simcard I eventually had to get a new. I've also read about other tabowners with similar problems so maybe tabs are "simsensitive". With the new simcard, this problem went away.
The other problem was with wifi.
The easiest way to make my tab find my wireless quickly, was to put it into flightmode and back on again immediately. In 30-40 percent of the cases this would cause it to crash and reboot. After the reboot everything was fine again.
A month ago I finally dared to flash and I've been on the latest Overcome for a month now. I've had just a single random reboot in this time.
Just my two cents...

 

[CarpeNoctem]

The issue appear indeed in the two versions of the ROM, the jq4 also have this issue and tweaking the build.prop does not change it, af974 I've try you're patch but still the issue remains, what is weird is that I spend the last 10 hours on wifi with no reboot and this morning, boom, reboots... the networks is not the same but still...

 

[daniel.weck]

SOLVED.

UPDATE: [SOLVED] the reboots stop once the MicroSD card is removed from its slot. I have also tried to remove the SIM card. As soon as the SD card is inserted, the Apps2SD applications are analysed by the Nazca/Media Scanner and from this point onwards the Package Manager sub-system goes crazy. I will restore my apps on the device, and I will format the MicroSD, again... I doubt it is a problem with the Micro-SD hardware itself, more like a driver issue. It seems quite common with mobile phones, all brands concerned.

 

[af974]

Nice one Daniel,

let us know how it goes after some test in the meantime i'll point my users to here.

UPDATE: [SOLVED] the reboots stop once the MicroSD card is removed from its slot. I have also tried to remove the SIM card. As soon as the SD card is inserted, the Apps2SD applications are analysed by the Nazca/Media Scanner and from this point onwards the Package Manager sub-system goes crazy. I will restore my apps on the device, and I will format the MicroSD, again... I doubt it is a problem with the Micro-SD hardware itself, more like a driver issue. It seems quite common with mobile phones, all brands concerned.

 

[daniel.weck]

Additional note: the MicroSD is perfectly stable when connected in USB transfer mode.

 

[daniel.weck]

I made a selective backup of important stuff from [/sdcard/external_sd/] (whilst in USB data transfer mode with my laptop), making sure to copy all the [*.asec] App2SD files from [/sdcard/external_sd/.android-secure/]. Then I formatted the MicroSD card on my laptop, and formatted again from the tablet as it detected a corrupted/damaged card (I suppose the FAT driver on the tablet is picky). I then copied the [*.asec] files back to [/sdcard/external_sd/.android-secure/] (several megabytes which I am happy not to have to download again via the Market), and the Package Manager seems pretty stable so far. Win!
I haven't put the SIM card back in yet, first I am updating my Titanium backup!
Cheers, Dan

 

[daniel.weck]

When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).

So, quite simply, I just insert the MicroSD card once the device is completely booted

 

[teacher1960]

When the MicroSD card is scanned at startup (i.e. the card is already inserted when the device starts), the MediaScanner / PackageManager analyses the card and this seems to generate a deadlock within the system_server process (.ServerThread), which results in a soft reboot. I don't know if this happens only when there are Apps2SD files (I didn't test this particular edge-case).

So, quite simply, I just insert the MicroSD card once the device is completely booted

I don't use App2sd so maybe that's why I don't have reboots with Gingerbread.

There are actually people who think that I with my SG Tab am jealous of their ipads. Moahaha!

 

[weichei]

What I did.....

What I did, when I first read this thread, I removed my SD-Card and formated it adapted to my PC (FAT32).
Next I reincerted it to my Tab. Til now (32 hours) it didn't reboot an single time:

I can check this, because of my Plantronics Discovery 975 BT headset that is permanently connected to the Tab.

Whenever in the past the Tab did a soft reboot (JQ3) it was hard work to get the headset reconnected.

PS: Used wifi for about two hours today. Seems to by stable for now. Will push some apps2sd and so on to see if it takes over rebooting.

 

[CarpeNoctem]

Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...

 

[daniel.weck]

Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...

UPDATE: sometimes the reboot occurs even when I insert the MicroSD card after boot, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!

 

[weichei]

UPDATE: sometimes the reboot occurs even when I insert the MicroSD card after boot, so the deadlock is not completely unavoidable. However, if I long-press the search button, the system doesn't respond which generates a Force Close popup dialog for "Android System" => if I force-close this process, then the device starts responding again and everything works as normal!

Not really satisfying!

Unfortunately I doubt this is the solution, the reboots remain even when I remove my sdcard...

Yes, same with me. Really annoying.

And by the way: android browser task often crashes, when trying to open an additional tab.

 

[af974]

Oh damn, i really would like to have too this annoying bug.

In % , this happens in what situations? Browsing, wifi, any addictional info please.

Could someone with this bug post a logcat? Dowload alogcat from market, enable to view only errors and export the log, i don't have any reboots but my log show many errors regarding mtp, keyboard and sensor.