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

Search This thread

jtrosky

Senior Member
May 8, 2008
3,901
1,153
my original. I've now placed the loaner into the dock and will start using it (was just sitting there before)...

EDIT: Ok, now the loaner has done the EXACT same thing! Too weird! Left the TF docked and "open", put into standby and a few minutes later I watched it reboot itself.

It did NOT get stuck as the Asus screen (neither did my transformer).

It's wild how they rebooted so close together like that after being up for so long!


So, are there any beta testers left that still have NOT experienced any random reboot/SOD issues?

Sent from my GT-P6210 using Tapatalk 2
 
Last edited:

acc3d

Senior Member
Jan 21, 2011
60
22
Samsung Galaxy Z Fold3
I did a factory reset before and after installing the 9.2.1.21 update. My TF101 seemed to be running well until this morning when I experienced the following:

- audio playback seems to have stopped working (a problem I experienced with previous ICS builds)
- auto screen rotation stopped working
- finally, my tablet randomly rebooted and got stuck at the Asus logo


Sigh, will they ever get ICS running well on the TF101? I guess I'll put the tablet back in the drawer until the next update; it continues to be useless.



Sent from my Transformer TF101 using Tapatalk 2
 

vicw

Senior Member
Apr 3, 2011
352
43
my original. I've now placed the loaner into the dock and will start using it (was just sitting there before)...

EDIT: Ok, now the loaner has done the EXACT same thing! Too weird! Left the TF docked and "open", put into standby and a few minutes later I watched it reboot itself.

It did NOT get stuck as the Asus screen (neither did my transformer).

It's wild how they rebooted so close together like that after being up for so long!


So, are there any beta testers left that still have NOT experienced any random reboot/SOD issues?

Sent from my GT-P6210 using Tapatalk 2

My unit didn't get stuck, or ask for the PIN input either, on this reboot. I just discovered it in Reboot Logger, and confirmed it on the Up Time status.
Edit: I just realized that the reason it didn't ask for the PIN input is that the update cleared out that setting, and I hadn't reestablished it.

Sent from my Transformer TF101 using Tapatalk 2
 
Last edited:

vicw

Senior Member
Apr 3, 2011
352
43
...
Sigh, will they ever get ICS running well on the TF101? I guess I'll put the tablet back in the drawer until the next update; it continues to be useless.



Sent from my Transformer TF101 using Tapatalk 2

You might try the Wake Lock app to prevent the potentially catastrophic deep sleep reboots. I was happy using it for weeks, prior to this last update.

Sent from my Transformer TF101 using Tapatalk 2
 

sbiriguda

Senior Member
Feb 3, 2011
307
155
L'Aquila
My guess is something is gradually getting more and more corrupted
Agreed, more specifically: kernel memory corruption.
I can confirm that at least on one occasion some kernel data structures were badly corrupted (out of sheer luck, I managed to extract a full panic log from a ramdump) and one of the changes NVIDIA made in .21 hints that there is something stomping arbitrary kernel memory, but instead of finding the root cause they tried (unsuccessfully) to address one of the symptoms.
 

luquiyahni

Senior Member
May 27, 2011
104
23
my original. I've now placed the loaner into the dock and will start using it (was just sitting there before)...

EDIT: Ok, now the loaner has done the EXACT same thing! Too weird! Left the TF docked and "open", put into standby and a few minutes later I watched it reboot itself.

It did NOT get stuck as the Asus screen (neither did my transformer).

It's wild how they rebooted so close together like that after being up for so long!


So, are there any beta testers left that still have NOT experienced any random reboot/SOD issues?

Sent from my GT-P6210 using Tapatalk 2

What apps have you used on both? (browser, gmail, etc)

My TF just went over 31hr of uptime, with 26 of deep sleep. Wifi is ON, but I haven't used any apps (besides Andoku 2). I never wiped it, just a cold boot, first 24hr with wifi OFF, and for the past 7 hrs, wifi ON.

My next step would be start using some apps. Haven't decide which one, yet. That's why I asked which ones you used so maybe I could avoid or use just one and only of those.
 

jtrosky

Senior Member
May 8, 2008
3,901
1,153
What apps have you used on both? (browser, gmail, etc)

My TF just went over 31hr of uptime, with 26 of deep sleep. Wifi is ON, but I haven't used any apps (besides Andoku 2). I never wiped it, just a cold boot, first 24hr with wifi OFF, and for the past 7 hrs, wifi ON.

My next step would be start using some apps. Haven't decide which one, yet. That's why I asked which ones you used so maybe I could avoid or use just one and only of those.

The only apps that installed after a complete factory restore are these:

- CPU Spy
- Dual Battery Widget
- Uptime Widget
- Tapatalk

I think that was it. I also used the Gmail/Email apps, stock browser, YouTube app, etc.... Just the basics...

Sent from my Transformer TF101 using Tapatalk 2
 

jtrosky

Senior Member
May 8, 2008
3,901
1,153
Ok, now what's still driving me crazy is that even if you flash a Honeycomb ROM via CMW, the reboot/SOD issues persist, even in Honeycomb. However, if I NVFLash Honeycomb, the problems go away in Honeycomb.

That tells me that the problem lies in one of the partitions that CWM doesn't write (NVFlash just re-creates all partitions).

So, I then compared the flash.cfg file for Honeycomb and one for ICS. All partition definitions are exactly the same, except for these two:

Partition 3 (PT)
In Honeycomb flash.cfg file, the size is "4096"
In ICS flah.cfg file, the size is "524288"!

Partition 10 (CAC)
In Honeycomb flash.cfg file, the size is "554700800"
In ICS flash.cfg file, the size is "555220992"

Is it normal for the partition sized to change so much between ICS/Honeycomb? The actual NVFLash command that is run is exactly the same....

Again, longshot, but....


I guess since I'm NVFlash, it can't hurt to try changing the ICS flash.cfg to match the Honeycomb flash.cfg... Although, if those partitions were that far off, I'dd suspect we'd see other issues... However, that partition 10 is the cache partition, I'm assuming - maybe ICS thinks the cache partition is really bigger than it is, so that when you get to that spot in the cache, it reboots? Again, longshot, I know...

Sent from my Transformer TF101 using Tapatalk 2
 
Last edited:
  • Like
Reactions: amaddux

*Detection*

Senior Member
Dec 5, 2011
10,512
2,862
Durham
Ok, now what's still driving me crazy is that even if you flash a Honeycomb ROM via CMW, the reboot/SOD issues persist, even in Honeycomb. However, if I NVFLash Honeycomb, the problems go away in Honeycomb.

That tells me that the problem lies in one of the partitions that CWM doesn't write (NVFlash just re-creates all partitions).

So, I then compared the flash.cfg file for Honeycomb and one for ICS. All partition definitions are exactly the same, except for these two:

Partition 3 (PT)
In Honeycomb flash.cfg file, the size is "4096"
In ICS flah.cfg file, the size is "524288"!

Partition 10 (CAC)
In Honeycomb flash.cfg file, the size is "554700800"
In ICS flash.cfg file, the size is "555220992"

Is it normal for the partition sized to change so much between ICS/Honeycomb? The actual NVFLash command that is run is exactly the same....

Again, longshot, but....


I guess since I'm NVFlash, it can't hurt to try changing the ICS flash.cfg to match the Honeycomb flash.cfg... Although, if those partitions were that far off, I'dd suspect we'd see other issues... However, that partition 10 is the cache partition, I'm assuming - maybe ICS thinks the cache partition is really bigger than it is, so that when you get to that spot in the cache, it reboots? Again, longshot, I know...

Sent from my Transformer TF101 using Tapatalk 2

Interested to hear your results, I'm nvflashable too and your theory makes sense if those sizes are wrong

Wouldn't be the first time they got numbers wrong, even in HC some left speakers had the wrong value in the srs file and the one before last ICS update had majorly low volume on media files
 

amaddux

Senior Member
Ok, now what's still driving me crazy is that even if you flash a Honeycomb ROM via CMW, the reboot/SOD issues persist, even in Honeycomb. However, if I NVFLash Honeycomb, the problems go away in Honeycomb.

That tells me that the problem lies in one of the partitions that CWM doesn't write (NVFlash just re-creates all partitions).

So, I then compared the flash.cfg file for Honeycomb and one for ICS. All partition definitions are exactly the same, except for these two:

Partition 3 (PT)
In Honeycomb flash.cfg file, the size is "4096"
In ICS flah.cfg file, the size is "524288"!

Partition 10 (CAC)
In Honeycomb flash.cfg file, the size is "554700800"
In ICS flash.cfg file, the size is "555220992"

Is it normal for the partition sized to change so much between ICS/Honeycomb? The actual NVFLash command that is run is exactly the same....

Again, longshot, but....


I guess since I'm NVFlash, it can't hurt to try changing the ICS flash.cfg to match the Honeycomb flash.cfg... Although, if those partitions were that far off, I'dd suspect we'd see other issues... However, that partition 10 is the cache partition, I'm assuming - maybe ICS thinks the cache partition is really bigger than it is, so that when you get to that spot in the cache, it reboots? Again, longshot, I know...

Sent from my Transformer TF101 using Tapatalk 2

That at least could make sense, with the assumption being that the cache is what is stomping on the kernel...and goodness knows what else... It would also mean the environmental difference is how much cache is written out (data usage?) I'll be curious how the experiment works out.
 

sbiriguda

Senior Member
Feb 3, 2011
307
155
L'Aquila
Partition 3 (PT)
In Honeycomb flash.cfg file, the size is "4096"
In ICS flash.cfg file, the size is "524288"!
That flash.cfg comes from a really old Honeycomb version, since the size of blob.PT shipped in 8.6.5.21 matches the one in ICS flash.cfg.

Partition 10 (CAC)
In Honeycomb flash.cfg file, the size is "554700800"
In ICS flash.cfg file, the size is "555220992"
Dunno about this one, the actual size should be written somewhere inside blob.PT (which I'm unable to decode at the moment, since I haven't found any description of its structure).

Anyway, flashing the stock recovery from 8.6.5.21 through CWM and then applying 8.6.5.21 as EP101_SDUPDATE.zip from the microSD (followed by a full wipe of /data) gives back a fully functional HC system with no RRs, no SODs, no battery draining, no screen tearing (except in the default browser, but that thing is hopelessly broken anyway) and no disappearing audio output.
 

*Detection*

Senior Member
Dec 5, 2011
10,512
2,862
Durham
I see a different value for Partition 12 too

And also there is no percent_reserved=0 in ICS partition 15


EDIT - Thing is though, as ICS was an update, would it have even resized any partitions for people who only updated via FOTA ?
 
Last edited:

jtrosky

Senior Member
May 8, 2008
3,901
1,153
Well, I figured what the hell, I've already spent countless hours troubleshooting this, might as well try changing the size value for the CAC partition... I left the PT partition size alone since someone said it matches newer versions of Honeycomb (I think the cache partition would be the important one anyway).

So, I changed the flash.cfg file and NVFLash'd again - no errors or anything - everything was still successful - we'll see what happens....

Sent from my Transformer TF101 using Tapatalk 2
 

jtrosky

Senior Member
May 8, 2008
3,901
1,153
I see a different value for Partition 12 too

And also there is no percent_reserved=0 in ICS partition 15


EDIT - Thing is though, as ICS was an update, would it have even resized any partitions for people who only updated via FOTA ?

You are correct - I missed those two differences! I believe that partition 12 (USP) is User SPace - not sure what partition 15 (UDA) is.... User DAta??

Sent from my Transformer TF101 using Tapatalk 2
 

*Detection*

Senior Member
Dec 5, 2011
10,512
2,862
Durham
Well, I figured what the hell, I've already spent countless hours troubleshooting this, might as well try changing the size value for the CAC partition... I left the PT partition size alone since someone said it matches newer versions of Honeycomb (I think the cache partition would be the important one anyway).

So, I changed the flash.cfg file and NVFLash'd again - no errors or anything - everything was still successful - we'll see what happens....

Sent from my Transformer TF101 using Tapatalk 2


I have two different NVFLASH versions of HC, .13 and a newer one I forget which one, 2nd newest I believe

Anyway, the 3 partitions in question along with the missing line in partition 15, are identical between the HC files, and only different in the ICS ones
 

jtrosky

Senior Member
May 8, 2008
3,901
1,153
I have two different NVFLASH versions of HC, .13 and a newer one I forget which one, 2nd newest I believe

Anyway, the 3 partitions in question along with the missing line in partition 15, are identical between the HC files, and only different in the ICS ones

Interesting... If my current test fails, I'll try making them all match.... Like I said, at this point, I'll try almost anything!

Sent from my Transformer TF101 using Tapatalk 2
 

*Detection*

Senior Member
Dec 5, 2011
10,512
2,862
Durham
Interesting... If my current test fails, I'll try making them all match.... Like I said, at this point, I'll try almost anything!

Sent from my Transformer TF101 using Tapatalk 2

Yea I am at that stage too, I've lost faith that ASUS will fix it and the fact that you altered a pretty important part of the flashing process and it didn't do anything terrible gives hope that you might be on to something here
 

luquiyahni

Senior Member
May 27, 2011
104
23
I have reached 36hr of uptime. The double of my best uptime since ICS. With a little over 28hr of deep sleep. I have started using *some* apps: twicca, tapatalk and also checked which updates were available at the store (MX Player - didn't update, though). I will not use any other app at least until I reach the 48hr mark.

Things I haven't done in the past 36hr and that I'm starting to fear: charge the tablet. dock/undock the tablet. use the browser. watch a video or use youtube.

Since I didn't wipe, I'm not under the "honeymoon effect", but maybe the tablet is, since I haven't used it that much (how many sudoku games can someone play?!). The next 12hr will give me a better idea if any of my theories make any sense, or if I will be wakelocking soon.



Sent from my Transformer TF101 using Tapatalk 2
 

rxnelson

Senior Member
Aug 30, 2011
676
76
I've never wiped and I estimate it made it 70+ hours on the first charge and 50+ on the second..... wait for it....;)

Sent from my Galaxy Nexus using Tapatalk 2
 

Top Liked Posts

  • There are no posts matching your filters.
  • 85
    Hi,
    We have not been able to replicate the battery drain and random reboot issue that several users have reported after the ICS update and subsequent firmware updates.

    As such we are looking for a few volunteers here to run a custom logging problem and report back their results. The system needs to have either the random reboot or battery drain issue and cannot be rooted.

    If you are willing to run this logging problem (very much appreciated) then please PM with the following information.

    Name
    Email Contact Information
    Serial Number
    Problem Description

    Sincerely,
    Gary

    Update -
    I will start sending out the logging file and instructions to the test group tomorrow.
    The logging tool simply captures low level OS routines that might lead us to the source problem.

    3/21/2012 Update -
    The logging tool was delivered to the first control group tonight. I will send the tool to the second control group tomorrow. Thank you for your assistance and replies.

    3/26/2012 Update -
    Thank you for your assistance and log reports. R&D is working on them feverishly right now. I will send out the tool to a third control group shortly.

    4/2/2012 Update -

    First off, thank you for your assistance and log reports. We are still investigating root causes for some of the problems. As such, personnel from the three control groups might be contacted directly for a system replacement so we can further investigate the lockup problem. I will have an update later this week.

    4/9/2012 Update -

    Thank you for the continued log reports. We are working through all the data now within R&D and at NVIDIA/Google. As soon as I have word on a Firmware update I will post it here.

    4/18/2012 Update -

    We sent out a beta Firmware release to a few users for testing. So far, it has solved the problems these users have experienced but I am still waiting on a couple of test updates. We also received back a unit that had the random lockup and screen corruption problem and so far after 22 hours of testing no problems. If the balance of the test updates are positive, we will get this build qualified and releases ASAP.

    4/24/2012 Update -

    9.2.1.21 will roll out today in North America. This release addresses several of the random reboot and lock problems reported by a few users after upgrading to ICS. It also provides new functionality with WiFi-Direct, Unzip in File Manager, Restore Tab function in the Browser, and general performance/stability tweaks. Although we had a high success rate in the beta testing phase in solving the random reboots, there were a couple of users who still experienced it during deep sleep mode. We are having those systems returned to us for further analysis and regression testing with their particular setups.

    5/3/2012 Update -

    We will release 9.2.1.24 into beta testing shortly. This firmware contains new NV code based upon the beta test group who still had issues with .21. I will provide updates once the firmware goes out to the beta group but it did fix returned units that experienced random lockups after .21.

    5/9/2012 Update -

    I have been out with pneumonia but will have messages forwarded to the Customer Care Team. The .24 release is in final qualification testing and will be released shortly.

    5/10/2012 Update -

    The .24 release is approved and will be released in the near future.

    5/14/2012 Update -

    The .24 release should go to FOTA later today or early tomorrow. Please shutdown and perform a cold boot after updating.

    5/15/2012 Update -

    Bad news, Google has changed their CTS qualification requirements on firmware so the .24 release is delayed for a couple of days. We have asked for an exception to release earlier, especially since it already passed qualification testing.

    5/16/2012 Update -

    The .24 release should go to FOTA very shortly. :)

    5/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.

    5/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.

    6/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. ;)

    7/4/2012 Update -

    New .27 Firmware is released and addresses browser and ANR problems among other items. As always, after the update is complete, clear browser and system caches, shutdown and then power up.
    14
    Hello TF101 users

    If you are still experiencing SOD or RR after updating to .24, please send me a PM. When sending a PM, please provide some brief details along with the following information:

    - SOD, random reboots, or both.
    - Observed uptime before issues or how often they happen.
    - If you are stock, rooted, flashed ect.
    - best contact e-mail

    Also, if you have a bug report you'd like to submit, I am working on gathering them up to send to HQ for analysis. Please PM me also.

    Tien
    10
    On the other end of things, my .27 unit is still absolutely fine @stock. Just watched the end of a movie, then played a little bit of a game, then sat and listened to music while I waiting for my laundry to be done, all while using my bluetooth stereo headset. No problems whatsoever.

    I've had it with ICS.

    I am running stock rooted on my B90. I found .24 quite stable with wifi disabled during sleep. I find .27 more unstable and now I am experiencing problems with GMail & Maps where I had none before. No ICS version is as stable as HC was. I want HC back. ICS has no advantage for me that justifies the aggravation.

    I am not interested in custom ROMS or kernals. I've got better things to do than chase that **** around.

    Asus, give me HC back, now!

    Well, that didn't take long. Not only did my husband's TF101 RR once already, but my games have begun to crash like before and yesterday evening, my WiFi cut out requiring a reboot to get it back, just as it has been doing on .24. *sigh* So much for "fixes", Asus. Oh, and the hubby's TF101 also lost sound already, too.

    well that's nice and consistent....

    For my part, when the tablet is alive and working, .27 seems good and stable and better than .21 and .24. No crashes, just one case where Dolphin stopped responding - and that was a failure on the wireless signal where I was using the tablet.

    I do, however, have an issue regarding the device sleeping. I can only wake the device by a long-press of the power switch and it does seem to drain the battery excessively too.

    Asus & Gary: I'm sorry about your impressions about people's responses here but you are largely the cause of this harsh language by your lack of communication. There are two activities that are crucial to the management of any problem - be it IT related or not. One activity is obviously the activity needed to fix the problem and you clearly have people working on this, albeit without apparently considering a roll back to Honeycomb.

    And then there is the communication. This in many ways is the more crucial activity and it is here that you have been weaker than you should have been. You may disagree, but let me put this in perspective:

    Ask yourselves
    • How much communication has there been about your new products?
    • How much communication has there been about this issue?
    • What channels do you use to communicate to your NEW customers
    • What channels have you used to communicate to your TF101 users?

    I follow you on Twitter, Facebook and here. I look at your Asus web site, I am a 'VIP' on your system. The communication about this issue has been woeful. This is why you now have angry users, not because you've not fixed it, but because you seem to be ignoring it - and therefore us.

    Let's look at the news on your Global site today:
    ASUS Global said:
    The ASUS Transformer Pad Design Story
    2012/06/25
    Always at the forefront of technology, ASUS has proven with its Transformer Pad family of tablets that they are in tune with what consumers require from their mobile devices. Launched in March 2011, the Eee Pad Transformer showed ASUS' ingenuity and innovative thinking with the Mobile Dock design...
    Really? In tune? Come on. Prove to me, prove to us all that this is true. Give us HC back. Come up with a communication strategy that lets us know what is happening, regularly. Until you do, until you realise that the world is not just made up of 'new sales' but also of 'existing users' who you have already won to your cause. Remember, a bird in the hand is worth two in the bush.

    Asus. We are all part of the same team here. The ball has been passed back to you, you have an open goal in front of you, do you score? Do you miss? Or do you pass it back to us and give up?

    Your call.
    10
    Gary's note in post #1 says to do it after the update.. Seriously doubt it makes a whit of difference.
    It doesn't, it just shows that they don't have a fscking clue on how their own product works.

    This is what happens during an OTA update:
    1. DMClient writes the dlpkgfile and the commands for recovery in /cache
    2. DMClient updates the boot parameter partition to force a boot in recovery mode and reboots the system
    3. the boodloader cold boots the current recovery kernel image from partition SOS
    4. the recovery kernel image runs init which transfers control to recovery
    5. recovery picks up the parameter file from /cache, then unpacks and verifies the dlpkgfile
    6. recovery runs the updater-script which in turns verifies the integrity of the target system (if you modified some key files it will bail out and show the red exclamation mark), applies patches, extracts new files, resets all permissions (that's where you lose root access :rolleyes:), flashes the blob to the staging partition, wipes the Dalvik cache, clears the boot parameter partition and then reboots the system
    7. the bootloader picks up the blob from the staging partition, verifies its layout and rewrites the partitions specified in its header (for a .21->.24 OTA this means EBT, SOS and LNX - bootloader, recovery and main kernel image)
    8. the bootloader restarts itself to pick up the new partition layout and/or a new version of itself
    9. the bootloader cold boots the main kernel image from partition LNX
    10. the system boots normally up to AndroidRuntime startup, at which point dexopt is started up on all user apps to rebuild the Dalvik cache
    11. end of the update process :)
    As you can see, a cold boot before or after upgrading is absolutely pointless because both are going to happen anyway (it's the way the bootloader works when switching between recovery and main kernel - it always performs a cold boot).
    9
    This thread started under a spirit of cooperation. It had since devolved into one of confrontation. Now we are trying to lift the discourse back to cooperation once again. Change is often hard fought, and the natural tendency of things is to fall and degrade. And, let's face it, the levels of people skills here can vary widely. Let's not give into temptation and regress again now into personal arguments. We need to look forwards and ever upwards, together.

    It is, of course, ASUS's responsibility to provide a solution to this problem, and I still expect no less from ASUS. Let that be clear. None of us on XDA caused it, and none of us on XDA can fix it [Nvidia closed source drivers]. Some "solutions" on XDA help mask it, but masking it is not a fix nor does that help the greater non-XDA TF101 ownership at large. It would be morally and ethically reprehensible for ASUS to leave the TF101 ownership in this state - but I still have faith that they will do the right thing. I have faith that their people, Gary Key and Tien Phan, are good men, honorable men, trying to do the right thing to the best of their capabilities and positions. Gary has proven to me, by the speed and content of his last in-thread response, that he does read this thread, and I commend him for that. He has not abandoned this issue, despite the various levels of discourse, and I do trust he will persevere until he ultimately brings us the solution we need.

    The major culprit in front of us has been identified: it is the "out of memory" issues being kicked up by Nvidia OpenGL. We need someone within ASUS championing our cause, and that person can only be Gary. However, Gary does not go about this alone. Many of us in this thread are still very willing to cooperate. Gary only needs to tell us what he needs from us, what he needs us to do, who he needs us to call and harass, etc. Please, by all means, use us if we can help at all. All I ask is that we please try our best to reach the solution soon and to pursue it with renewed vigor. We are all getting a little bit restless over this, and the tide can't be held back forever.