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

Search This thread

Fromostraya

Member
May 9, 2012
13
2
Nowra
Just a thought. Before ASUS pushed ICS out in Aus my Stock TF (B70) was completely stable. After ICS I experienced RR and SODs once or twice a day (no other symptoms). I found this thread and made a couple of the tweaks suggested, and installed Wake lock and Auto Airplane. In the past six weeks I have not had one RR or SOD.

I haven't removed any apps, never wiped the device, did not accept the .21 upgrade, have the dock on 95% of the time, and regularly use gmail. I also have flash installed.

I'm not suggesting that the steps above are any sort of "answer", but as my TF was one of those experiencing failures, I can't help wondering why mine is now stable, when others have got worse.

Would it be useful (or even possible) to compare settings of an unstable TF and a stable TF - especially if they were the same model and build? (Or is it safe to assume that ASUS have already done that?) :confused:
 

devjazz

Senior Member
Jan 10, 2012
81
14
Most likely, Google would mark the report as "INVALID", since the stack trace shows that the faulty code is in /system/lib/egl/libGLESv2_tegra.so (one of the "closed source" NVIDIA bits, so no luck there - even with a custom rom).

NVIDIA strikes again, bummer. Note to self - think twice before buying anything with NVIDIA inside again :( The 0xbbadbeef crash is likely read or write access to uninitialized memory address pointer. Probably reading beyond the end of a buffer - a common bug. Those magic hex values are used to signal stuff like that. I havent come across bbadbeef before - deadbeef and baadf00d are more commonly used :) Here is a list of some of these amusing magic numbers: http://en.m.wikipedia.org/wiki/Hexspeak#section_1

BTW I just had a SOD crash today after several days uptime running with Wakelock. Yes this crashed even though Wakelock was active - stuck ASUS logo and dock drained to 10% when I noticed it. Now I have no way of knowing for sure if wakelock was *actually* still active when it crashed. I suppose its remotely possible that something caused Wakelock itself to get killed and then the SOD took over. This has happened at least a couple of times despite running wakelock. The bug is very fundamental - wakelock just defer's whatever idle state behavior triggers the crash. So jtrosky's experience with the latest beta seems to imply the root issue is alive and well just dormant. Till this thing is fixed its a time bomb. I would dread using it for something important - like a public event.
 
Last edited:

sbiriguda

Senior Member
Feb 3, 2011
307
155
L'Aquila
NVIDIA strikes again, bummer. Note to self - think twice before buying anything with NVIDIA inside again :( The 0xbbadbeef crash is likely read or write access to uninitialized memory address pointer.
I'm inclined to think that an NVIDIA dev with a twisted sense of humour used 0xbbadbeef as a "magic" viewport base address whenever their GLESv2 library encounters an unrecoverable error while RPC'ing to the GPU.

I honestly don't know why they chose an arbitrary address (which could even be mapped in the process address space) instead of returning a well-known invalid one (0x00000000 - also known as NULL).
This just makes application debugging extremely hard and unpredictable (if 0xbbadbeef is mapped to a writeable region it's memory corruption galore - try to debug that without the GLESv2 library sources telling that they MIGHT write to that address under some circumstances...).
 

vicw

Senior Member
Apr 3, 2011
352
43
At this moment, I'm planning on trying .24 first, and if it fails, and if I can't get stable gmail performance as well as reboot prevention from WakeLock if necessary, then either installing a ROM or just reverting back to HC.

One point that I can't get settled in my head is how it would be possible for a ROM to be built on top of the .21 (or even .24) update, with demonstrated stability issues, and really provide stable performance?

Somehow that doesn't make any sense to me, no matter how ingenious the developer, how does he/she avoid the defects that are presumably imbedded into nVidia/ASUS or Google code?

I'm open to suggestion and education, but it doesn't sound very promising to me.
 

st0nedpenguin

Senior Member
Jun 13, 2011
419
110
It's pretty ridiculous if Asus still can't fix the issue when I haven't seen a crash or reboot in over a week of running guevor's kernel.
 

anatmavada

Member
Nov 26, 2007
37
1
San Pedro, Belize
n00bpwners.com
What happened to the .24 update, I still stuck on the .21
What do you mean by near future?? before its was ... released shortly.

My actual .21 kill my battery and my TF101 is always very hot because of WakeLock. Will ASUS replaces batteries for free if they fried?

Any time frame for the .24 update (days/weeks).
We are having this problems now for months and nothing has changed. :(
 
Last edited:

vicw

Senior Member
Apr 3, 2011
352
43
What happened to the .24 update, I still stuck on the .21
What do you mean by near future?? before its was ... released shortly.

My actual .21 kill my battery and my TF101 is always very hot because of WakeLock.
Any time frame for updates (days/weeks).

There was a post of a translation from the Italian ASUS Facebook entry that suggested that it might start to be released on May 14, but I don't know if that will be just Italy or otherwise. I think we can expect to see it "soon".

Not sure about your problem with WakeLock. I've been using it steadily for over a month, with no Deep Sleep reboots, minimal battery drain on .17 and .21, and no problem with heating. It works for me, at least.
 

anatmavada

Member
Nov 26, 2007
37
1
San Pedro, Belize
n00bpwners.com
If I leave the pad overnight in the dock, the dock battery goes to 3%
If I leave the separate then the pad losses about 30-50% in one night.

My pad is always quit warm...

I only survive thanks WakeLock
If I remove the WakeLock I will stuck again in the reboot freeze. Since my on and off switch broke from the often use in stopping the endless reboots, Then I have to wait till the battery is dead, plug it in and start it normal. The sad thing, if you outside of the US (Central America) you have no ASUS support at all.
 

vicw

Senior Member
Apr 3, 2011
352
43
If I leave the pad overnight in the dock, the dock battery goes to 3%
If I leave the separate then the pad losses about 30-50% in one night.

My pad is always quit warm...

I only survive thanks WakeLock
If I remove the WakeLock I will stuck again in the reboot freeze. Since my on and off switch broke from the often use in stopping the endless reboots, Then I have to wait till the battery is dead, plug it in and start it normal. The sad thing, if you outside of the US (Central America) you have no ASUS support at all.

The dock battery will normally discharge down to about 3% first, then it draws from the tablet battery.

I doubt that WakeLock is your problem. I've never had the broken power switch, so I really don't know exactly what that is doing to your tablet.

I would install the Badass Battery Monitor app, then track the tablet while not connected to the dock. After a while, to let the data accumulate, you should be able to use Badass Battery Monitor to isolate which app is causing the excessive battery drain and heating.



Sent from my Transformer TF101 using Tapatalk 2
 

tpjets62

Senior Member
Mar 29, 2012
202
35
Albany, NY
www.hytechnet.com
At this moment, I'm planning on trying .24 first, and if it fails, and if I can't get stable gmail performance as well as reboot prevention from WakeLock if necessary, then either installing a ROM or just reverting back to HC.

One point that I can't get settled in my head is how it would be possible for a ROM to be built on top of the .21 (or even .24) update, with demonstrated stability issues, and really provide stable performance?

Somehow that doesn't make any sense to me, no matter how ingenious the developer, how does he/she avoid the defects that are presumably imbedded into nVidia/ASUS or Google code?

I'm open to suggestion and education, but it doesn't sound very promising to me.

This baffles me too. Granted some of these custom roms have their own little "issues", but the one thing they seem to NOT have an issue is RR's. And most users say the performance is a little snappier too. I may end up giving one or two of these roms a test drive for my own evaluation......
 

vicw

Senior Member
Apr 3, 2011
352
43
This baffles me too. Granted some of these custom roms have their own little "issues", but the one thing they seem to NOT have an issue is RR's. And most users say the performance is a little snappier too. I may end up giving one or two of these roms a test drive for my own evaluation......

I wonder if users might tend to be more forgiving of ROMs than they are of stock - where a reboot, or an operational deficiency here and there is seen as no big deal for the ROM, and unacceptable for stock? Again, I'm open to hear from those who have been successful with ROMS, especially with regard to the spontaneous reboots. If any of them have truly solved the problem - sign me up.

Sent from my Transformer TF101 using Tapatalk 2
 
Last edited:

stcanard

Senior Member
Jan 10, 2012
80
19
I wonder if users might tend to be more forgiving of ROMs than they are of stock - where a reboot, or an operational deficiency here and there is seen as no big deal for the ROM, and unacceptable for stock? Again, I'm open to hear from those who have been successful with ROMS, especially with regard to the spontaneous reboots. If any of them have truly solved the problem - sign me up.

Sent from my Transformer TF101 using Tapatalk 2

I've gone from stock + wakelock to Revolver +guevor's 17c kernel to see. But I need 3 more days to really make a call, since it took several days before my issues showed up on .21 (after 3 days the prognosis is decent, I've had one RR and lost sound; with wakelock I had one RR but kept sound - with .21 stock it was a disaster)

I'm really interested in what happens if problems do reappear, on stock it seemed like they were cumulative - once they started they stayed until the next upgrade. Now that I've got a custom ROM I'm curious if I can reset them by clearing caches or flashing the ROM again.
 

vicw

Senior Member
Apr 3, 2011
352
43
I've gone from stock + wakelock to Revolver +guevor's 17c kernel to see. But I need 3 more days to really make a call, since it took several days before my issues showed up on .21 (after 3 days the prognosis is decent, I've had one RR and lost sound; with wakelock I had one RR but kept sound - with .21 stock it was a disaster)

I'm really interested in what happens if problems do reappear, on stock it seemed like they were cumulative - once they started they stayed until the next upgrade. Now that I've got a custom ROM I'm curious if I can reset them by clearing caches or flashing the ROM again.

Thanks for the info. I agree that it will take more time to draw any conclusions. I think at least a week of solid performance should pass before any confidence can be established, and of course you've already had one failure, so I'm not sure that can be considered a complete success, even if there aren't any more in their next few days.

It seems that we some different observed system behavior patterns. On my system, the only spontaneous reboots I can remember since the first day of ICS are reboots during deep sleep, never with an active system, never while on the charger, never with WakeLock active. I do however, see periods of erratic gmail behavior, lost icon and widgets, and occasional browser glitches that usually require me to reboot to resolve.

The periods of instability come and go. I just had two days of flawless behavior, and then today was a total mess. It's just back and forth, with no apparent rhyme or reason that I can deduce.

Sent from my Galaxy Nexus using Tapatalk 2
 

renatoram

Member
Feb 26, 2009
23
32
I wonder if users might tend to be more forgiving of ROMs than they are of stock - where a reboot, or an operational deficiency here and there is seen as no big deal for the ROM, and unacceptable for stock? Again, I'm open to hear from those who have been successful with ROMS, especially with regard to the spontaneous reboots. If any of them have truly solved the problem - sign me up.

Nah. I bought my TF101 only recently. I kept it on stock (rooted) for a month, with wakelock, since it displayed the usual misbehaviors: RR, SOD, etc.

I waited patiently for an update, then when I saw .21 didn't fix anything I didn't even wait for it to become available in Italy. I took the plunge and installed Revolver 4.0RC1.

I am now on Revolver 4.0RC2 with guevor kernel 17c and I can testify I do not get reboots or SODs. The tablet goes to deep sleep regularly for hours (during which the battery is not consumed at all), battery life has been very good. I did not install wakelock, none of the tricks.

Only problem so far has been the diagonal screen tearing in the youtube app, just like I had on stock.

I have no idea how they can do it, if the problem really lies in the binary NVidia code, but it works. Mostly it's guevor's kernel's merit, though: up until version 15 or so (iirc) people were still having RRs even on Revolver RC1.
 

mribeiroap

Senior Member
Oct 29, 2010
96
16
From Asus Italy Facebook and translated by Bing:

"A quick update on 9.2.1.24 for firmware, which we know are TF101 waiting with great anxiety. We anticipated the possibility of delays and the HQ has just reported that the distribution via FOTA will gravitate from today to tomorrow. We will keep you updated."

Original:

"Un rapido aggiornamento sul firmware 9.2.1.24 per TF101, che sappiamo state attendendo con molta ansia. Vi avevamo anticipato della possibilità di ritardi e l'HQ ci ha appena segnalato che la distribuzione via FOTA slitterà da oggi a domani. Vi terremo aggiornati a riguardo."
 

jtrosky

Senior Member
May 8, 2008
3,901
1,153
Just to keep the bad news coming...

I just experienced my first SOD with .24... I opened my TF and nothing would happen. Tried pressing power button and waiting, but nothing... Tried closing and re-opening TF, but nothing. Then a few seconds later, the Asus screen appeared and the Transformer booted up.

I guess that's kind of a mix between a SOD and a random reboot... I did NOT have to hold the power in for 10 seconds like you normally do with SOD...

I *DID* just install and configure the Apex Launcher about 30 minutes before this occurred. Had an uptime over 2 days when it happened...

Not got - I was just bragging how at least .24 hasn't had an SOD... <sigh>

Sent from my Transformer TF101 using Tapatalk 2
 

msaraiva

Senior Member
Oct 28, 2007
273
93
I know that the decision to release .24 has already been made and that it's going to be any day now (I think?), but since I'm still having some reboots, I might as well continue testing and reporting to Gary for the next update...

So, my questions is this: Where do I go from here?? Now that I seem to be having some reboots with my current setup, what should my next test be? Should I completely wipe my TF and start over, being careful about what apps I install? Should I try removing the last few apps that I installed? Should I just continue with what I have?

I'm just looking for some assistance in what to test next. Obviously, I'm not a beta-tester by profession, so I'm looking for some input here!!

Thanks!

Sent from my Transformer TF101 using Tapatalk 2

I don't remember if i already asked you this or not, but...did you test guevor's kernel on your TF? It's been rock solid for me since test13, i couldn't be happier.

Sent from my Transformer TF101 using XDA Premium HD app
 

sbiriguda

Senior Member
Feb 3, 2011
307
155
L'Aquila
I just experienced my first SOD with .24... I opened my TF and nothing would happen. Tried pressing power button and waiting, but nothing... Tried closing and re-opening TF, but nothing. Then a few seconds later, the Asus screen appeared and the Transformer booted up.
Looks almost like a textbook case of a hung system kicked out of sleep by the watchdog timer...
 

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.