[Asus  Eee Pad Transformer Prime] _motley:
Sorry to see you had trouble. Thanks for being honest about what happened. And also many thanks to the other guys stepping in to help. Were you able to get your device recovered?

Thanks, appreciated the vote of confidence the other night! Also, thanks for creating the blob install. I would love to hear feedback about this. If it is safer, I should definitely move to this delivery method.

When you get the source from the vendor, unfortunately there is no good way to confirm whether or not they have changed anything in the official builds vs. the open source release. Hopefully they are upping the version as they should. We know it will be very close to what they are releasing to customers, or it would be obvious and we could call them out on it. I'm sure they strive to do they best they can. Fortunately, since we have the source, we can apply patches from Nvidia and keep it up to date. If their vendor customization has bugs, we will need to address that ourselves or wait for the next source release to compare and find out what they have fixed/changed.

Interesting and related story...I haven't looked over all the drivers yet in this kernel, but many device specific kernels have device drivers with built-in firmware that gets flashed on boot. This firmware lives as code built into the kernel binary, not on disk such as wifi firmware. With the Galaxy tab 8.9, I found that the source Samsung posted had older firmware included in the kernel build for the melfas touchscreen driver. The firmware that lived on the tablet was newer and better, but every time you would boot, it would load the older firmware from the kernel binary (temporary flash). The touchscreen lagged for 1-2 seconds when coming out of sleep. At first I thought the code they gave was different. But then I tracked it down to the firmware flash happening on boot. So, I went in and unhooked the code within the driver to prevent the downgrade use the newer firmware resident in the chip.

If this is the person above, they accidentally flashed the zip file with "dd" and not the extracted boot.img. Hopefully there is not another person that has also gotten into trouble. Unfortunately, disclaimers and people are not foolproof and accidents can happen even to the best of people. If folks use the dd commands with the offsets as shown (important), it shouldn't be a problem. Hopefully the blob method is shown to be stable and safer for unlocked tablets. I have to say, I am bit nervous about it because it is foreign to me and I haven't built up the trust. I have dd'ed so many kernels in the last year, I don't even want to know!

Also, thanks for the feedback in the other posts, very much appreciated!

Thanks for the feedback! Glad to hear it is stable for the guys reporting back.

If others have flashed, please give your feedback about stability. I have only heard from one user in an early post that had stability issues and thought he needed more juice. This would surprise me since 1.7 was already in the kernel...some code just had to be tweaked to enable it. I haven't had this problem myself and ran quite awhile with the performance governor last night before posting the alpha. Not one reboot yet. I did a couple back to back performance tests and beat the tar out it with Linpack and it was getting a little warm, so I set the governor back to interactive and it cooled down fairly quick. We all know that all devices aren't created equal, so it will be curious to see what others report.

At this point, I can't speculate how far we can go, but I will likely shoot for 1.8GHz as the top frequency. After that, I think there is more to gain in governor and i/o performance tweaks for day to day usage. 1.7GHz is burning enough battery as it is LOL.