ICS tf101 reboots - The definitive thread!

[janner43]

There are many discussions on this subject, with various views expressed. Having a pretty open mind & also having read / contributed to many of them, I now feel pretty sure that we can make an informed observation on the causes.

These, in my view, are the reasons for these reboots. Some have been affected by one, some by more than one.

1. The significant upgrade from one OS to another.
This full change in the OS means that doing a full Factory Reset has resolved the system instability that was created by remnants of the old OS & apps remaining after the standard update process.

2. Apps that are not updated for ICS or which are not well coded
Some apps have repeatedly been proven to cause system instability & thereafter, reboots.

3. Alterations to the OS by Asus
The Asus tweaks through Asus Customised Settings have caused issues to some. The second firmware update with ICS was tantamount to an acceptance of this with their inclusion of a new addition regarding wifi and sleep.

4. Underlying Screen Driver Issues.
It has been widely rumoured that there is a problem with the nVidia screen driver under ICS. This rumour is probably true, IMO. The fix for this will only be forthcoming from nVidia working with Asus.

5. Underlying OS issues
Another widely promulgated view concerns underlying Android 4.x issues that will need to be addressed by Google working with Asus. These issues revolve around "kernel panic" and "ram fragmentation". This issue seems to mesh with 4, above, to cause the most serious of all cases of system instability.

The most puzzling feature of this reboot situation is why it affects some users & systems so badly, while others appear relatively unaffected.

To any who are affected, the best advice is this. You can help yourself to deal with issues that are mentioned in points 1, 2 & 3. Working through these issues is best achieved by reading through & following the advice offered here
[HOW TO] ICS update problems? - fix them with these steps
and here
[HOW TO] Perform a Factory Reset

Yet more threads containing more suggestions can be browsed here
Ice Cream Sandwich

Following the advice offered has "fixed" significant numbers of issues for many owners who had experienced them. Sadly there are still those who report being affected even after trying to perform fixes. For those, if you have performed a full Factory Reset, unless your system is demonstrating hardware like faults, there is no real point in RMAing your device to Asus at this stage. They are currently working on resolving these issues using their own R&D team and also 3 groups of private users who are exhibiting the problem who are providing Asus with system logs, & in some cases, within these groups, replacing the unit in order to have a "fault generating unit" in Asus' hands to work with directly.

It is anticipated that further firmware updates will be pushed OTA to systems although no official date has been announced.

Rumour control, here are the facts...
Gary Key, Asus Technical Marketing Manager for Asus says...

MAY 22 2012 Update -

Sorry for the delay, tried not to die from pneumonia last week after a relapse. I will start answering general questions again today and forwarding CSR events to the Service Team. Good news is that we have hired a full time employee to assist our Tablet owners in the Android centric forums. His name is Tien Phan and he is available here under the user name Asus_USA. He is part of our new Customer Loyalty Group and will be taking over forum coverage and assisting our valued customers. I will still be around, especially to handle technical problems and coordinate with Engineering until Tien is completely up to speed. However, as always, if you run into a problem that is not solved by our Service Group please feel free to contact me.

MAY 31 2012 Update -

We are working on another release with updated code from NV/Google. I will be in Taiwan next week to discuss this version and once a beta is available we will release it to a small group of testers. So far, this updated code based has worked extremely well on the TF201/TF300 in beta testing. As soon as I have an update it will be posted.

June 11 2012 Update -

We received additional code enhancements from NV/Google while I was in Taiwan last week. We will create a beta update shortly for testing and hopefully the next firmware update will occur in the next two weeks. I/O and Thread priority changes are the top two items and will address ANR and Sleep issues, however, still testing various application loads as some applications do not want to play nice with thread overrides.

Official ASUS Thread - ICS Update on TF101 (20-Mar-2012) - xda-developers

.27 is now released... http://www.transformerforums.com/for...0120615-a.html

[Ads]

[bogolisk]

this is from his log:

<4>[ 4707.484356] notifier_call_chain 5 call=-5 tegra_dvfs_pm_notify+0x0/0x40  val=4 
<4>[ 4707.484799] ------------[ cut here ]------------
<4>[ 4707.484830] WARNING: at include/linux/gfp.h:152 __alloc_pages_nodemask+0x58/0x658()
<4>[ 4707.484840] Modules linked in: bcm4329 texfat(P) tntfs(P) battery_rvsd(P)
<4>[ 4707.484897] [<c0048a04>] (unwind_backtrace+0x0/0xf0) from [<c007c4ec>] (warn_slowpath_common+0x4c/0x64)
<4>[ 4707.484919] [<c007c4ec>] (warn_slowpath_common+0x4c/0x64) from [<c007c51c>] (warn_slowpath_null+0x18/0x1c)
<4>[ 4707.484940] [<c007c51c>] (warn_slowpath_null+0x18/0x1c) from [<c00d27d8>] (__alloc_pages_nodemask+0x58/0x658)
<4>[ 4707.484961] [<c00d27d8>] (__alloc_pages_nodemask+0x58/0x658) from [<c007add0>] (copy_process+0xb8/0xdc0)
<4>[ 4707.484980] [<c007add0>] (copy_process+0xb8/0xdc0) from [<c007bbd8>] (do_fork+0x100/0x270)
<4>[ 4707.485004] [<c007bbd8>] (do_fork+0x100/0x270) from [<c0043898>] (kernel_thread+0x70/0x80)
<4>[ 4707.485023] [<c0043898>] (kernel_thread+0x70/0x80) from [<c0094890>] (kthreadd+0xac/0xf8)
<4>[ 4707.485040] [<c0094890>] (kthreadd+0xac/0xf8) from [<c0043698>] (kernel_thread_exit+0x0/0x8)
<4>[ 4707.485052] ---[ end trace 896a0ed708458bf6 ]---
<1>[ 4707.485137] Unable to handle kernel paging request at virtual address 08bd8054
<1>[ 4707.485148] pgd = c0004000
<1>[ 4707.485155] [08bd8054] *pgd=00000000
<0>[ 4707.485167] Internal error: Oops: 5 [#1] PREEMPT SMP
<0>[ 4707.485175] last sysfs file: /sys/devices/system/cpu/cpufreq/conservative/down_threshold
<4>[ 4707.485186] Modules linked in: bcm4329 texfat(P) tntfs(P) battery_rvsd(P)
<4>[ 4707.485206] CPU: 0    Tainted: P        W    (2.6.39.4 #1)
<4>[ 4707.485222] PC is at clk_disable_locked+0x14/0xa4
<4>[ 4707.485231] LR is at clk_disable+0x38/0x60

tegra_dvfs_pm_notify is a notifier routine of the Nvidia's SoC driver in the file dvfs.c. value=4 means POST_SUSPEND, i.e. waking up from sleep.
The warning was from the kernel because the memory allocation request (from the nvidia driver???) has bad parameters.
The kernel panic was triggered by a bad address presumably caused by memory trampling...

[Yvan]

As for #3 in OP, the wifi sleep function does not work at all. Wifi stays on regardless of this setting is on or off. Solution, turn off wifi manually and tablet has not rebooted or locked up in 2 weeks.

[bogolisk]

As for #3 in OP, the wifi sleep function does not work at all. Wifi stays on regardless of this setting is on or off...

Are you sure? My tf101 definitely turned off wifi during sleep. Trying to "ping" it (when it's sleeping) will failed.

As for hanging, i remember my tf101 does respond to ping even during a SoD. That might explain why people saw haning and battery drain overnight. The kernel-panic just hang the whole system and the hardware devices never go to sleep/low-power-mode.

[janner43]

As for #3 in OP, the wifi sleep function does not work at all. Wifi stays on regardless of this setting is on or off. Solution, turn off wifi manually and tablet has not rebooted or locked up in 2 weeks.

It works for me Yvan. That's one of the problems here - different folks seem to have different results

[Ridata]

As for #3 in OP, the wifi sleep function does not work at all. Wifi stays on regardless of this setting is on or off. Solution, turn off wifi manually and tablet has not rebooted or locked up in 2 weeks.

did not work for me .i always turn off wifi manually. today i woke up and saw the tablet reboot by itself while it was on a shelf alone

[loganss]

As for #3 in OP, the wifi sleep function does not work at all. Wifi stays on regardless of this setting is on or off. Solution, turn off wifi manually and tablet has not rebooted or locked up in 2 weeks.

That ASUS setting activates during deep sleep and not when the screen turns off. It does indeed work like other members have said.
If you want wifi to turn off when the screen turns off install Auto Airplane Mode (AAM) by Don.

Crude timeline of events:
Screen off -> This is where AAM turns off wifi-> Some time elapses -> Deep Sleep -> This is where ASUS setting would turn off wifi

[towers1209]

Are you sure? My tf101 definitely turned off wifi during sleep. Trying to "ping" it (when it's sleeping) will failed.

As for hanging, i remember my tf101 does respond to ping even during a SoD. That might explain why people saw haning and battery drain overnight. The kernel-panic just hang the whole system and the hardware devices never go to sleep/low-power-mode.

What is SoD??? Also, wht is SoC?

[RonnieD]

SoD stands for Sleep of Death. Can't help you with SoC

[perk]

SoC is System on a Chip.