As I suspected early on the issues boil down to corruption within the User Data or Cache partitions, less often on the system partition due to an unexpected shutdown of the device. Shut on these devices need to follow the proper shutdown routine as any linux environment. Following this best practice will ensure that all data is written out to its corresponding file system by flushing all cache, unmounting the file system, etc..
Here are the culprits of why we see so frequent random Force Closes, Market Resetting, etc. ultimately resulting in an unclean shutdown, corrupting some data.
1. The button we use is also a forced off button. Typically if you hold it down too long you are powering off the device.
2. Some times when in sleep mode you see the Viewsonic logo upon starting - that means that the system shutdown (most likely crashed).
3. If your running Vegan your hitting the reboot.. I dont know for sure but I suspect this is NOT performing a clean shutdown... (I dont have a copy of the source)
Anyway... wanted to pass this on... as last night my data partition became corrupt after using the Reboot function on the Poweroff menu of Vega 5.1..
shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing
My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.
roebeet said:
My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.
Click to expand...
Click to collapse
I have been on stock since I got the device just moving to the newer versions when they come as OTAs and have never ever had to mess with my partition, so I don't THINK the issue is in the stock software. In fact, the only problems I've ever encountered were when I used the enhancement pack, in which case my screen started to become unresponsive and the calibration.ini I was told to try did not work. Since then I went back to 3389 and the device has been perfect ever since.
I could be wrong though and just very, very lucky....here's to hoping. Another thing to consider is maybe the memory is going bonkers for some reason. I've had flash memory that lasted forever and I've had flash memory that has gone wacky over a period of 6 months....even a wipe by the utility designed to do it doesn't fix it properly. I don't know how CWM wipes or partitions the memory, I do know there's supposed to be a special way to do it.
If it's not faulty memory off the bat, then that leaves something in the 'extras' being put into these ROMs. Maybe some of the newer tegra drivers or some coding to make the ROMs faster - I'm just saying, can't leave any stone unturned.
Has anyone that has stayed loyal to stock encountered these issues? We have to ask that question I think. Then we ask how many of the people playing with ROMs are seeing the issues, this would include people that have used CWM to partition and mess with their mounts initially.
I can say I've never seen data disappear from my internal memory or my SD and I can also say I've never seen multiple FCs except after putting in the enh. pack (keep in mind I got my tab on Dec 20something, so I had 3053 and then 3389 soon after).
The first sign of anything being 'corrupted' on it's own at stock and I'll be sending mine back. As an owner of Android since Android's been around, I've never had my G1 or MT4G (or any smartphone before it) become corrupted due to not being shutdown or reboot properly and while this is a tablet I think the fundamentals should be the same. Pampering 'faulty' memory is a risk. You can wipe and re-do all you want, but if it's faulty it's going to stay that way.
Ive done that but I guess you can say unfortunately I have had only clean shutdowns since then... The last corruption I had I formatted my data and cache partitions before I ran logcat.... Of course thought of that afterward....
Generally if any has FCs, etc. etc. run a logcat and post it here... we will be able to confirm this...
We could change the way the partitions are created and add a sync which will further reduce chances BUT will take a performance hit...
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I reviewed the out of the box framework source on the google GIT and technically if a reboot command is given a clean shutdown is performed via the framework... but the widget on the shutdown screen I suspect is not calling the method properly or is not being called at all... All speculation at this point... But for sure there is corruption occurring..
Since the last corruption I switch over to pershoots kernel... Even though his kernel seems to be a little slower he seems to have included the latest drivers which other items relate to data integrity (im reading into the release notes).
NEO: The first thing I did when I got my device install CW, Vegan... Updated Kernels also... Never had an issue until the first time (yes about a day ago) I used the reboot feature of Vegan. That corrupted my user data. I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
But again.. between the wrongly placed power switch, the unprovoked reboots (ie viewsonic screen showing when trying to wake up the device) and the reboot button possibly not performing a proper shutdown will sure increase the chances in a wider distribution of users. So it may not be a CW issue and just some poor design.
When I have time today I will verify if the reboot function performs a clean shutdown... if anyone has the time please post the logcat... Im going to be running around today and will try to get to it..
watson540 said:
shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing
Click to expand...
Click to collapse
stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
Click to expand...
Click to collapse
AFAIK they're running yaffs ATM. Next move is to ext4...
Read some articles about this several weeks ago, apparently many apps do not properly flush file caches. One of the articles was a Google developer post about file corruption along with their API method which did a cache flush prior to a close, then a bit later was the Google indication that they were planning to move to ext4 FS to further help alleviate the problem.
stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
Click to expand...
Click to collapse
That's my point. How many times since we've had our Android and smart phones have we had situations where they are turned off or rebooted without the proper procedures? Power drains till they die, they drop and reboot, we clog them up with stuff or some app drives them nuts and they reboot or shut off....Yet you rarely if ever hear about a phone's data being 'corrupted' with stock software. Sure it may happen with official OTAs etc, but never just off-the-bat like what's happening with the G-Tab. But it's not happening to everyone either so I'm just looking to see if there's a pattern.
Even since the G1 and newer phones, you don't really hear about or see file corruption issues on stock software with these phones. It's when users start going to ROMs that you hear of issues cropping up. That's not to say it doesn't happen at all at stock, I just think we're seeing it in a more concentrated fashion here because of all the formatting, re-partitioning, etc. At first you hear, 4GB is a great partition size, then you hear there are problems so move to 2048, then you hear 256MB swap, then no swap since Android doesn't use it. Then dataloop for speed, then no dataloop because of critical issues. Rules and instructions change almost on a daily basis. I think it's more than these poor flash drives can take I find sometimes it's good to keep it simple.
I owned a Vibrant for a while...decided it was a PoS when at stock I was seeing bad lag (because of Sam's terrible FS). People said...do the speedhack, it'll be fast!, but what was the caveat? Having to reboot the phone almost weekly, sometimes several times a week, and people were seeing what? Data corruption. That's not for me. Give me something that is lag free (doesn't have to be a bullet train, just don't skip on video or audio and make sure my live wallpaper and drawer animation is fluid and I'm happy!). Point being....keeping it simple may help to alleviate some of the issues. If people are seeing these problems with stock, then you're absolutely right and it would be a point of contention that the failsafe isn't working right.
Otherwise it seems the stock OS on these things are able to self correct in most situations and it may just be some of the many tweaked features in these ROMs doing something it shouldn't - or, I may just be very lucky indeed.
I'm still dying to get the OTA - I haven't seen one since 3899 yet.
Related
Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes
When i did mine i did the 2048 for the first setting and watched it complete.
NEVER got the second option.
Allenfx said:
When i did mine i did the 2048 for the first setting and watched it complete.
NEVER got the second option.
Click to expand...
Click to collapse
it is possible that it will not give you the second option. as long as you choose 2048 for partition size and then 0 if asked for a swap size then you are good.
i think the second options isnt there if you use Rom Manager from the market to install your ClockWork Recovery.
ext3 journal errors for /data partition
I had this problem and it was due to ext3 journal errrors in the /data partition which caused it to be mounted as read only at startup (thus all applications force closing when they cannot write its data).
See: http://forum.xda-developers.com/showthread.php?t=895628
There might be other causes but I strongly suspect that this is the same since only a re-partitioning of the sdcard helps in this case as well (believe me, I have basically tried every other possible and impossible option).
Why the ext3 file system becomes inconsistent/corrupt (not sure of the right term) I don't know. Anyone has an idea or a way to prevent it from happening in the future?
fr33h33l said:
I had this problem and it was due to ext3 journal errrors in the /data partition which caused it to be mounted as read only at startup (thus all applications force closing when they cannot write its data).
See: http://forum.xda-developers.com/showthread.php?t=895628
There might be other causes but I strongly suspect that this is the same since only a re-partitioning of the sdcard helps in this case as well (believe me, I have basically tried every other possible and impossible option).
Why the ext3 file system becomes inconsistent/corrupt (not sure of the right term) I don't know. Anyone has an idea or a way to prevent it from happening in the future?
Click to expand...
Click to collapse
Agreed on the journal idea. A few things come to mind - dirty shutdowns from power button issues could potentially cause a problem, though in theory that shouldnt be an issue with ext3.
The other possible cause is something to do with the way Clockwork Mod wipes that data partition, sometimes leaving the journal state inconsistent with the newly wiped state.
Most significantly, this seems to only happen once to many users. That could mean the initial journal state is weird in some way from the factory and repartitioning once sets it up properly, never to occur again.
Sent from my VEGAn-TAB-v1.0.0B5 using Tapatalk
rothnic said:
Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes
Click to expand...
Click to collapse
This also seems to be the fix for 'boot looping" and the market not having enough space error
Stuck this nice post
rothnic said:
Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes
Click to expand...
Click to collapse
I am getting this same problem, everything was working fine yesterday. But when I turned the tablet on, Everything FC's except for stock android apps. I am using Vegan my partion is setup as 2040/0.
papote18:
Did you literally mean 2040/0? Or is the 2040 a typo?
It should be 2048, but it's beyond me what would happen if you used another value!?
Rev
Solution works great, thanks.
iDroidNow said:
it is possible that it will not give you the second option. as long as you choose 2048 for partition size and then 0 if asked for a swap size then you are good.
i think the second options isnt there if you use Rom Manager from the market to install your ClockWork Recovery.
Click to expand...
Click to collapse
Confirmed.
I am using clockwork premium from the market.
Does Viewsonic Have a Fix for This?
Does Viewsonic Have a Fix for This that does not involve installing software that Viewsonic says will void your warranty?
This does not seem right to me that the way to fix this problem is to install third party management software and partition the SD card.
If Viewsonic doesn't offer a fix for this, then in effect there is a hardware problem with the G Tablet and Staples was completly justified in pulling the product.
I was having all kinds of forced close issues and restored the tablet in settings to factory reset and that fixed the problem for now.
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?
GaryHypnosis said:
Does Viewsonic Have a Fix for This that does not involve installing software that Viewsonic says will void your warranty?
This does not seem right to me that the way to fix this problem is to install third party management software and partition the SD card.
If Viewsonic doesn't offer a fix for this, then in effect there is a hardware problem with the G Tablet and Staples was completly justified in pulling the product.
I was having all kinds of forced close issues and restored the tablet in settings to factory reset and that fixed the problem for now.
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?
Click to expand...
Click to collapse
Its a software problem. The hardware is fine.
butchconner said:
papote18:
Did you literally mean 2040/0? Or is the 2040 a typo?
It should be 2048, but it's beyond me what would happen if you used another value!?
Rev
Click to expand...
Click to collapse
It was a typo, I am going to repartion the SD card and update to Vegan 5.1 hopefully that fixes the problem.
Manufacturing Issue
thebadfrog said:
Its a software problem. The hardware is fine.
Click to expand...
Click to collapse
I think Viewsonic had said that the recall by Staples was due to a customer experience problem and not with a manufacturing issue. This is not a direct quote but very close.
An internal SD card is hardware, and this defect seems to be that these were possibly not formatted correctly by Viewsonic or their supplier prior to being installed into the G Tablets. And, that is a manufacturing issue. I don't want to get into a flame war with you over the terms software or hardware. My point here is that the solution should come from Viewsonic. Many people on this forum are quite comfortable with these MODs. That is not the point of my post. These may be wonderful ways of making your tablet perform the way you want it to. My problem with these solutions is that once you have made them, you have let Viewsonic "off the hook" because you have voided your warranty.
Here is a quote from Roebeet talking about opening the case on the G Tablet to push the reset button in another post. However the same could be said for all of these issues! "We shouldn't have to void our warranty (open the case and push the hard reset button), just to do a hard reset". Here is my quote "We shouldn't have to void our warranty just to get the tablet to work at an acceptable level either".
Viewsonic should provide a way to partition the SD card that does not involve voiding your warranty! Until Viewsonic comes up with a way to fix these problems in software, their stock answer when you call their tech support line is to send the unit in for repair.
GaryHypnosis said:
I think Viewsonic had said that the recall by Staples was due to a customer experience problem and not with a manufacturing issue. This is not a direct quote but very close.
An internal SD card is hardware, and this defect seems to be that these were possibly not formatted correctly by Viewsonic or their supplier prior to being installed into the G Tablets. And, that is a manufacturing issue. I don't want to get into a flame war with you over the terms software or hardware. My point here is that the solution should come from Viewsonic. Many people on this forum are quite comfortable with these MODs. That is not the point of my post. These may be wonderful ways of making your tablet perform the way you want it to. My problem with these solutions is that once you have made them, you have let Viewsonic "off the hook" because you have voided your warranty.
Here is a quote from Roebeet talking about opening the case on the G Tablet to push the reset button in another post. However the same could be said for all of these issues! "We shouldn't have to void our warranty (open the case and push the hard reset button), just to do a hard reset". Here is my quote "We shouldn't have to void our warranty just to get the tablet to work at an acceptable level either".
Viewsonic should provide a way to partition the SD card that does not involve voiding your warranty! Until Viewsonic comes up with a way to fix these problems in software, their stock answer when you call their tech support line is to send the unit in for repair.
Click to expand...
Click to collapse
And they will update the software
GaryHypnosis said:
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?
Click to expand...
Click to collapse
I think I understand what you are saying, but at the same time they have released the source code and are giving updates. Another option would be just to abandon it and come out with a new device (ie samsung). I bet the majority of people buying these just think they don't work and return them. Viewsonic is probably eating their hat on this whole issue. This will be how they learn. "Return for service" seems like a really stupid way to deal with all these issues people are having
On the other hand, how many problems have you had with windows or linux which required 3rd party software to solve? I can think of quite a few.
I'm just thankful people on here 1/ know what they are doing and 2/ care enough to share answers. Thanks.
I agree with GaryHypnosis comments, as for the past 24 hours i've been struggling with a brand-new G Tablet that crashed within 5 hours of being first powered up.
Unfortunately for me, i bought it from an ebay dealer that will not accept returns and after i called the Viewsonic G Tabet line the rep told me that the best thing to do would be to return it and ask for a new one, or try to do a reset from the "settings" control tab (since my G Tablet crashed i can't even access that any longer), or WAIT FOR 30 DAYS FROM DATE OF PURCHASE TO SEND IT TO VIEWSONIC FOR REPAIR [email protected]#f**k !?
At this point i am not even sure that Viewsonic will accept it under warranty considering that i bought it from an ebay dealer...
I can't download these Mod files because my G Tablet's web access is blocked due to the fact that i can't sign-in because the tablet's keyboard doesn't appear onscreen any longer and i tried downloading Mods by way of an USB connection between my desktop and the G Tablet, but it did not work.
Right now i feel that i committed a huge mistake by buying this piece of crap that uses an unfinished OS that doesn't even offer disk defragmentation or disk clean-up, let alone a hard button for re-set. I understand there is such a hard button located internally, but i don't see why buyers should have to deal with opening the case and voiding whatever warranty it comes with.
I will never buy another product from VIewsonic, and after my call to the company's G Tablet "experts" phone line and hearing what he told me, i would advise people to do likewise
As best I can tell, no one has actually permanently bricked one of these things. Anyone have a broken one for doing software mods?
Anything you install on it can be changed back to the "stock" software and I'm not sure how anyone would even know you had done anything to it. Returning it to viewsonic for software problems is equivalent to killing a gnat with a nuclear weapon. It doesn't seem worth the cost and time. I'd only do that if I lost a monitor or a touchscreen went bad (ie truly hardware related failure).
It only takes installing clockworkmod, and then vegan (5) already had working market and flash for me. It was the easiest one yet. The newer tntlite had working flash. To get the market working required about ten button presses and a reset.
I still don't understand why people try to keep going on the tnt software at all (unless you count tntlite...). OBVIOUSLY the people who made that didn't do an A+ job.
Hope I don't sound mean here, but with the wealth of knowledge on this website, why would you expect a minimum wage worker answering at the call center to know 1/10th as much as the people developing custom roms?
Is there a way to confirm the partitoning worked? I am on tntlite 4.0 and things seem to have gotten worse with more force closures after the partition. This is what I did:
Clockwork backup of tntlite 3.1.4
Clockwork partitioning
reboot
clockwork update from update.zip of 4.0
Any help appreciated.
I guess I've been fortunate I have never had all the issues with system dumps and force closings some others have had the misfortune to experience. My Tab has been rock steady for months.
I have been good about cleaning everything up before installing new ROMs.
Today that all changes. Tab went completely discharged and after hooking back up to the charger, it now loads into forced closings on every app and launcher.
I can see all my apps in the main dir and under apps settings, but none will run and the Tab is in a constant cycle of force closing.
I think it had something to do with letting the Tab run completely dead?
I know I can wipe all the data and repartition to correct, but damn I have a ton of user data and apps on this baby and if there was a way to correct this problem, Ie replace a file, that would be a much better solution.
So if anyone has had the same situation with constant force closings, let me know if you figured out a way to correct without starting from scratch.
Thanks, [email protected]
What ROM are you using or is this on stock?
Have you attempted clearing cache and dalvik using CWM?
The ONLY thing I can really think of optimistically speaking is that the force closings are somehow caused because your SD card may not be loading/loaded properly - ie: maybe theres a file system error or something? Apps that load from it or depend on files loaded/loading on it would FC, of course the fact that you say nothing can run may indicate a more dire problem....
The worse case scenario is that the flash drive inside has been corrupted somehow - but I highly doubt that. I've seen other people report constant FCing before, so your problem, if not the SD issue, is probably somewhere in the middle - where your file system got messed up somehow but no hardware is damaged.
I've had mine discharge on me many times with no issues whatsoever.
I tired a few of these already, but I haven't tried pulling the SD card. Thanks!
I am one of the many who have been experiencing the random reboots. I have seen talk about it, but have not seen anyone really looking into why this is happening. Some people claim it happens only when docked, or when SD card is in etc. Yet others post that they still get the reboots without doing those things either.
I have been monitoring my reboot problem very closely. I have yet to determine the cause other than it only happens when the device is put into sleep mode manually or automatically, and I am looking for some help from some of the DEV's around here.
When our TF's do this reboot, it is a system crash. When this happens, a ROMDUMP file is placed on the internal "sd card".
These can be viewed with a simple txt editor, like windows notepad. I myself can not read the code and understand what info it is revealing to me. According to an Asus tech on the phone this file can tell you what went wrong and made the device reboot. However the buggers won't tell you crap over the phone and want me to send the device in with the ROMDUMP files.
When I try and read the files, I do see one thing in common, in 99% of them, right near the end of the file, or the very last line before the crash, this line is present,
Kernel panic - not syncing: Fatal exception in interrupt
<2>[ 162.985309] CPU1: stopping
If our reboot issue is kernal based, which would indicate it's a firmware issue;
I was thinking one of the talented DEV's around here could fix us up.
Hell maybe even just a reflash of the current firmware would fix the issue.
Anyway, if a DEV around here want to or willing to look into this, I have some ROM dumpfiles they can look at, just send me a PM.
For reference,
I have a B60K modle
Stock 3.1
GPS 1.3.1
Wifi 5.1.42
BluT 6.17
Kernal 2.6.36.3-00001-gf377a2b [email protected] #1
Build HMJ37.US_epad-8.4.4.5.2-20110603
Thanks.
I don't have any more dumps recently, deleted them so I can't pull up and see what mine said to give you, but wanted to just say I was having these multiple times a day every day and it started once I bought an AData 16GB SDCard for the dock. Then I ended up removing that card and bought a MicroSD 16GB card instead and it has quit doing the random reboots, so definitely seemed to be something with my SDCard in the dock.
Post your whole log here (as .txt or .zip) and I will look at it.
I've had these once or twice but have always deleted the file.
The Kernel Panic is the kernel's way of telling you that something unrecoverable has happened and the integrity of the whole OS is in question. Think of a kernel panic like a BSOD on Windows.
I've never seen that specific one before, but a quick Google search indicates it may be a problem with I/O operations - like bad RAM or a bad SD card.
sassafras
Thanks for the response. I have included 4 RAMDUMP files. I find these 4 special because they all happened in quick succession. Four separate reboots all within 8 mins of each other without any interaction of the device myself. I never touched the device, I just sat there and staring at the device rebooting 4 times in 8 mins. On the final reboot the device never came back on. AT this point I picked up the device and had to hold the power button down for over 10 seconds for the device to come back on to an Asus splash screen. This was mins after I did a fresh factory reset via the OS options internally then a hard reset using the hardware buttons.
...It's a bug alright...
It doesn't seem to be caused by the same problem though, just that the watchdog program invokes a kernel panic and reboots. Weird. I'll backtrace it later and see what's up.
sassafras
went a whole day without a reboot. I did have an odd lock up/freeze at the lock screen where i couldnt unlock the device or get it to rotate the screen. It was locked up tight. Held hte power button down for 20 secs before it shut down. Rebooted, no new RAMdump created. No issues since.
sassafras_, Did you have any luck reading those ramdumps?
I did - sort of.
They're all related to the watchdog program assuming it's soft locked up. Which it may very well have been, but since you weren't using the device at the time, it's hard to know for sure.
The function's that were called immediately prior to the fault were different, which to me indicates that it's just buggy software. Honestly, without doing a backtrace I wouldn't know, but I can't without a system.map from around the time of the lockup. I'm going to assume it's just buggy code from 3.1 and wait and see if the 3.2 release lowers the rate of these. If not, then maybe I'll do some more digging.
sassafras
sassafras_ said:
I did - sort of.
They're all related to the watchdog program assuming it's soft locked up. Which it may very well have been, but since you weren't using the device at the time, it's hard to know for sure.
The function's that were called immediately prior to the fault were different, which to me indicates that it's just buggy software. Honestly, without doing a backtrace I wouldn't know, but I can't without a system.map from around the time of the lockup. I'm going to assume it's just buggy code from 3.1 and wait and see if the 3.2 release lowers the rate of these. If not, then maybe I'll do some more digging.
sassafras
Click to expand...
Click to collapse
Is there any progress on this issue? I bougth a brand new tf and during day random reboots maybe 50 times. And that romdumps are appeared on my internal storage. I dont have external sd by the way. Im stuck.
Hi.
Im having a same problem with my Transformer. Its a week old B60 and its reboots probably 50 times a day and give me log files.
Also im using Honeycomb 3.2
I really want to find out what is going on
i guess its a hardware issue or something.
i'm going to give back my TF today and take back a new one.
if i get same errors, i'll let you know.
I posted a workaround that helps immensely for rooted tablets somewhere around here. I can't find it tonight, but it's in one of the other 'random reboot' threads.
sassafras
sassafras_ -
Did you ever find anything with this issue? I am on my second TF and it is exhibiting the same random reboot while sleeping issue as the first. I know you have a post on another thread indicating how to tell the kernel to ignore "oops" conditions - have you received any feedback on how that is working? I assume this requires root access, I haven't yet rooted my device.
I have collected a few ramdump log files, but as of now only one out of 6 shows a kernel panic. I am new to Android, and I am trying to make sense of the dump logs. It appears that these dumps are maintained in a ring buffer, so the last entries are usually somewhere in the middle, is that correct? All of them also have some garbage at the end, but I assume that is just another effect of the ring buffer strategy.
Like I said, I am new to Android, but I am a long time embedded and real-time programmer, and pretty handy in Linux. It seems to me that the log files aren't providing enough information, but I'm not sure how to debug kernel/system crashes in Android. If anyone could point me in the right direction of where I should look next to get more information on these crashes, perhaps we could get to the bottom of this problem.
From what I can tell via the logs, when the TF is sleeping, it wakes up from time to time for various reasons, then suspends when it is done. It looks like it is during this wake/suspend cycle that something occasionally goes wrong and causes the tablet to reboot.
I am hoping that this is a software/firmware issue (or a hardware issue that can be worked-around with software), because I really like the TF platform and this issue makes keeping apps like IM or email running while it the device sleeps kinda iffy.
Any help from the awesome experts here at XDA would be greatly appreciated, and I look forward to learning more of the gory details and inner workings of Android.
I have had the same issues. Configuring the kernel to ignore oops only helped a bit. The tf would still freeze in standby eventually (once a day or so). My supplier (i.e. not Asus) replaced it and my new tf (a SBK v2 one, unfortunately) has not rebooted once in 2+ weeks. So my guess is that it was a hardware issue (memory, something not coming out of backup mode properly, ...?). Not sure if one could work-around it in software.
Now, this was probably not very helpful but I thought I'd share my experience here. And possibly my tf suffered from an entirely different defect, although the symptoms were the same (ramdump logs from random reboots in standby, independent from wifi on/off, sync on/off, and lots of other settings I tried).
flipflipflip -
Thanks for your reply! I was hoping that it wasn't a hardware issue, and since I got two in a row with the identical problem I was thinking that maybe a software fix could get around it. After reading about your experience, I went ahead and returned it and ordered another one from a different source. Hopefully the third time's a charm!
I'm keeping my fingers crossed that this one is not an SBK v2, but I'll be happy just to have one without sleep-apnea!
This did give me a chance to load up ADB and poke around a bit under the hood of the last one, so if nothing else it is a learning experience. Hopefully I will have something to contribute to the community once I get my hands on a working device.
I know it's been a while (had a big work-related headache), but just wanted to post and let people know that I finally received a TF101 (B50!!) that seems to be working just fine - so I guess it was just a combination of bad luck and a hardware issue after all.
The only issue I have now is that sometimes when it is sleeping, it loses its internet connection (it still seems to be connected to the AP) - but I think I can work around that.
Cheers!
Hey gang -
Yesterday at home I pulled my phone out of my pocket and it was at the "touch the Android to begin" (!) screen. But it was still connected to my WiFi... And I was confused.
Rather than do that, I reset the phone, wiped Davlik cache and Fixed Permissions (took a long time!), then rebooted.
That sort of worked, but a LOT of my apps are crashing on start, and others are missing altogether. Even when I re-download them and re-install them, they don't work.
What's the way-ahead here? Am I stuck doing a factory reset? Or even formatting the SD card?
Thanks in advance.
When things get that fouled up, a clean install over a freshly formatted microSD is probably the best thing to do. You might be able to get away with restoring from a "nandroid" backup from before things started going bad, but "Your mileage may vary."
jeffsf said:
When things get that fouled up, a clean install over a freshly formatted microSD is probably the best thing to do. You might be able to get away with restoring from a "nandroid" backup from before things started going bad, but "Your mileage may vary."
Click to expand...
Click to collapse
Okay, thanks!
Anything else on the SD card I should back up besides DCIM / Media-> Ringtones/MP3s / "ui" / TitaniumBackup?
(Got about an hour while this stuff goes off to my HD...)
Hoo! Thought I effed myself for a sec - from CWM I was wiping all partitions... including /sdcard.
Then I realized... $#¡+... my ROM is on there!
Fortunately CWM has the "mount USB storage" option.
*whew!*
I was going to add format the sdcard from the phone. But you did that. Typically when what happened to you would happen to me it would be from some app updating and for whatever reason got corrupted during install and fouled the phone up. If you use TiB I highly suggest setting a automated task to back up your TiB backups to drop box, google drive or box.net. Then in these situations you have a recent TiB to fall back on.
JaimeZX said:
Hey gang -
Yesterday at home I pulled my phone out of my pocket and it was at the "touch the Android to begin" (!) screen. But it was still connected to my WiFi... And I was confused.[...]...a LOT of my apps are crashing on start, and others are missing altogether. Even when I re-download them and re-install them, they don't work.
Click to expand...
Click to collapse
Hi JaimeZX,
I am curious if you have recently rooted, flashed to stock, or installed the VB or Basic w/a twist kernel? I am running the exact same setup as you list (minus the modem) and this *exact* same scenario happened to me on the exact same day. March 12th, at about 10pm.
Detail as much information as you can, I've had many problems since flashing back to stock, formatting the SD, wiping everything multiple times, and re-installing Valhalla Black, Basic w/a Twist and all fresh apps d/l'd from the market. I'm on multiple attempts to stabilize the device and have questioned whether or not there is some issue with either the Rom or the Kernel. Perhaps there is an issue with the stock packages, or the USB driver ghosts (I've deleted all USB assigns at all ports and reinstalled for device detection in Heimdall). Hopefully we can get a good list of information to help us fix an issue that is apparently quite catastrophic (in that /data seems to corrupt) and save others from a future headache.
I have searched the dev threads to no avail, and as a general rule it seems that if problems are brought up they are usually met with "try flashing back to stock," "gremlins," "no one else is having problem 'X'," etc. even in cases of users with multiple complaints of the same issue. Both the DSP Sound force close upon EQ preset select and the issue that some had with the Messages, Phone Dialer, Search, Call Logs closing to homescreen are issues that I've seen this with. I believe this is a real issue, and I need to get it fixed without wasting time on messaging replies to anyone advising "try this," "Try that," etc.
My hope is that between the two of us we can address any of the common responses from developers before taking the issue to them and reporting it. I personally cannot today get my phone to boot without freezing (after boot cycle completes - not bootlooping or freezing during the bootleader seq) and am currently attempting to get into d'l mode without much luck.
When this happened to me on Tuesday night I was able to reboot to recovery, reflash the final-fixed.zip first without wiping data (which failed-/data is corrupted somehow here) and then *with* wipe/data and it booted, ran fine, so I then re-flashed BasicWithaTwist Kernel and was fine until late last night again.
I had been using the phone for some fairly constant web searching and the screen went black, appeared to soft reboot, and then froze. I pulled the battery, waited a few mins, reinstalled battery, once again, Freeze after boot.
No indication that an app crashes, phone just completely freezes, remains screen on, capkeys lit, power button does not respond, nor do softkeys or touchscreen. Makes it though the scan device and scan SD processes *sometimes* and other times freezes before it completes them.
I pulled the both the SD and the SIM and booted up, same issue, though it makes it through the scan device processes everytime since it's not scanning 18gb of data on an SD. This tells me it is not SD or SIM related, and is most likely software related, either ROM or Kernel. I've also ruled out the possibility of an old app/data package by reformatting the SD (long format - wipe all containers to "o,") let Android rebuild menu structure on SD, redownloaded a short list of commonly used apps and installed fresh - *NO* TiBackup apps were restored and the actual backup folder was not replaced to the SD after flashing.
I've tried both the Odin (Fb KJ6 back to stock) and the one click (lumin's tutorial) back to stock. Checked the download of Final-Fixed, MD5 checksum is correct. Cannot find MD5 on the sms-T959V-KJ6-antsvx.v1.1.3.zip file. Doesn't seem to be listed on Anton's github site, perhaps I don't know how to find it there. That is the only puzzle piece I haven't double checked.
All for now, looking forward to yours or anyone's replies or suggestions for anything I may be overlooking. Thanks.
0
---------- Post added at 11:19 AM ---------- Previous post was at 11:12 AM ----------
devlinandersen said:
Hi JaimeZX,
... I've had many problems since flashing back to stock, formatting the SD, wiping everything multiple times, and re-installing Valhalla Black, Basic w/a Twist and all fresh apps d/l'd from the market. I'm on multiple attempts to stabilize the device and have questioned whether or not there is some issue with either the Rom or the Kernel....
0
Click to expand...
Click to collapse
I should add that I have been on Valhalla Black Edition since it was in beta and have been quite happy with it. I only did a back to stock flash to try to (one more time) see if I could get a cooperative DSP sound manager. No such luck, and now a few headaches, and this issue on Tuesday coupled with yours in the exact same timeframe...I'm just thinking there is a problem somewhere in the chain of attack and hope to find it with the help of others.
Also, phone freezes after boot, needless to say, I'm not able to run a logcat.
devlinandersen said:
No indication that an app crashes
[...]
Also, phone freezes after boot, needless to say, I'm not able to run a logcat.
Click to expand...
Click to collapse
Try running logcat > /sdcard/some_file and cat /proc/kmsg > /sdcard/some_other_file so you have a capture of both the Android logs as well as the kernel logs. If you're not comfortable with command-line work, aLogrec should be able to at least help with the Android logs.
Given the number of people successfully running stock and custom ROMs on this device with stability, it either is going to be a hardware problem with your phone, corruption of a file system, or some app or combination of apps you are running, not a "dev" issue. Without logs, it is going to be nearly impossible to differentiate between the causes.
jeffsf said:
Try running logcat > /sdcard/some_file and cat /proc/kmsg > /sdcard/some_other_file so you have a capture of both the Android logs as well as the kernel logs. If you're not comfortable with command-line work, aLogrec should be able to at least help with the Android logs.
Click to expand...
Click to collapse
I will try in a bit, collecting files for another fresh install, different ROM.
jeffsf said:
Given the number of people successfully running stock and custom ROMs on this device with stability, it either is going to be a hardware problem with your phone, corruption of a file system, or some app or combination of apps you are running, not a "dev" issue. Without logs, it is going to be nearly impossible to differentiate between the causes.
Click to expand...
Click to collapse
This is false logic and is just what I was trying to avoid. I will attempt to explain to hopefully help build a stronger environment that is conducive to problem solving. It still very well could be a dev issue if say, a certain ROM or Kernel begins to wrestle with an app that has recently updated. Is it the apps or the rom's fault? Maybe it is a seldom used feature of an app that just missed all the users testing until now, it's well within the realm of possibilities and would just like to see helpful comments (such as the first portion directly above) to help solve issues. Truth is, I don't know *what* is wrong and neither do you, so a focus on constructive commentary would just help everyone out.
Logs or it didn't happen.
Update...
After a factory reset/data wipe, wipe cache, wipe dalvik cache I had to let the battery charge for a bit. Came back and decided to just try to boot phone, still freezes after boot sequence. I decide that I will flash a different kernel and a different ROM in order to see if I can make a difference. Before flashing Blastoff v2.5 Kernel I decided to factory wipe/data wipe, wipe cache and dalvik again...I am not sure if this is news, but when doing the Dalvik cache wipe in CWM it returned no result, perhaps because I had previously performed and is empty, but I thought it strange that there was *no* communication that it was already empty/wiped, etc.
Installed Blastoff v2.5 and was able to boot without freezing. Something else was damaged with the Rom as well, would not load home screen, only had pulldown menu. Rebooted to Recovery and flashed Unnamed RC-2.zip and have been charging the battery, talking on the phone and reinstalling apps from market.
Same error happened twice to me and once with Jaime. Both of us on VB and Basic+Twist. After installing new kernel i'd point towards kernel. Also uninstalled DSP and installed voodoo sound on VB, but had that on previous version as well. If I had to start somewhere, I'd start right around there.
Hope this helps, will provide logs from SD backup I made before reflash of new kernel/rom. Gotta run. Adios...
-devil.
I had to get my phone going today, it appears to be working without freezing, though on this new app the phone dialer/phone caller force closes on outgoing calls (I am only mentioning here, I will visit the Q&A for the ROM if I need assistance). Unfortunately I was unable to replicate the problem without flashing back to my previous nandroid. I have it saved and given some time I will do my due diligence and get a logcat **if** Jaime doesn't do it before me...because I kinda have a feeling that something was updated in the market on Tuesday evening that is now fighting with the kernel somehow. But again...I didn't run a logcat so it's not even happening...yet...
...to be continued...
Devlin - sorry for the delayed reply.
I did notice that I'd had more and more apps FCing on me in the week leading up to the Über-crash. Unfortunately I don't have any more "background" to add than that.
I backed up everything I wanted on the SD card and then formatted that, plus /data, /system /everythingelsethatwasanoptioninCWM. Then did my installs.
FORTUNATELY (knock on wood) I have not had any recurrence of the major issue.
I couldn't find this online, or it seems the method no longer applies, and I couldn't get it to appear in a search here.
The last time I upgraded was from an S9 to the Note 20 Ultra. When I did, it asked me if I wanted to copy from the old phone, and everything was moved over, including all of the apps. The only things missing were the older texts from my side and some of the data inside some apps.
This time is used Smart Switch, and it only transferred data and a few of the apps. It was better before!
Is there a way to get everything or almost everything moved over?
I just want to get switched over quickly.
Thanks!
A clean load is best for stock phones. Do it right the first time...
SmartSwitch can screw up bad. A different device and OS version can cause issues. Potential data loss is also a possibility.
Never use SmartSwitch as the only backup... keep at least 2 copies on hdds that are physically and electronically isolated from each other and the PC.
Copy/paste critical data, then verify size, file count and if readable. If you have an SD card it should already be there on the old phone.
Otherwise develop a plan/organize your data so you can reload as quickly, accurately and painlessly as possible with zero critical data loss.
After 2 back to back boot loops in 3 days I learned that lesson
Clean Load? Do you mean don't use SmartSwitch, and just set up the new phone manually?
Maybe this device is too different for SW to work? Are there any alternatives?
Myk_Myk said:
Clean Load? Do you mean don't use SmartSwitch, and just set up the new phone manually?
Maybe this device is too different for SW to work? Are there any alternatives?
Click to expand...
Click to collapse
Yeap. Always the best option. A good load can last for years if you don't do firmware upgrades/updates. This stock Note 10+'s load will be 3 yo this June, still fast, very stable with minimal maintenance. Still running on Android 9. Android loads can be very long lived, a great OS.
A clean load means when you do find issues (and you will) you won't be wondering if you imported the problem with SmartSwitch. The last thing you want to do is a factory reset because the issue is likely to reoccur*. Instead find the root cause. Knowing you have a good base load helps with troubleshooting.
If SmartSwitch screws it up a factory reset maybe the only realistic solution. It may be lagging, system instability or subtle issues. My second N10+ may need this done because I inadvertently used more SmartSwitch options than I had wanted. So are the issues from SmartSwitch or because of Android 10? Only one way to know for sure... You get the idea.
*a boot loop or malware that can't be eradicated are the exceptions. With a boot loop you still need to track down the root cause, usually a buggy 3rd party app.