[ROM - 1.2] BETA ICS 4.0.X - Team DRH (Update 07/02/12)

nobe1976 · Jul 15, 2012

drkduncan said:
Thanks for the files, can't believe I did not know of this site before.

Sadly I tried everything I could think of, still no luck. Hopefully now that someone has sent their "stuck at the birds" device in for analysis there will be a fix. I have the CWM install log if that would be helpful. [Update: log attached]

These are the steps that I most recently followed: 1.1, then 1.1 w/ cwm08, then 1.2 w/ CWM 3028, 1.2 w/ CWM 5504 with formatting the partitions, and factory resets in between. Still no luck, stuck at the stupid birds as always.

At this point I will probably just go back to DRH 1.2 until someone comes up with new steps for my to try.

On that note, anyone with a possible fix - I am happy to test.

Have you ever tryed to redownload the update using your tablet not your PC. If you are able to run 1.2 you should be able to run 1.3. I will try my best to get into my hard drive that has a few tricks on it. Give me a bit.

beerman99 · Jul 15, 2012

Help?

anybody else having random reboots, was reading a kindle book and suddenly wham, battery was at least 50%, after reboot solid?

drkduncan · Jul 15, 2012

I downloaded it directly to my tablet both through the news app and from the OP link.

Sent from my TeamDRH ICS for GTablet using xda premium

lartomar2002 · Jul 15, 2012

drkduncan said:
I downloaded it directly to my tablet both through the news app and from the OP link.

Sent from my TeamDRH ICS for GTablet using xda premium

Did you do the nvflash or did you already have the 250m?

drkduncan · Jul 15, 2012

lartomar2002 said:
Did you do the nvflash or did you already have the 250m?

I nvflashed with both 250mb and the 300mb files.

Sent from my TeamDRH ICS for GTablet using xda premium

fosser2 · Jul 15, 2012

Hey guys,

I did get that tablet in the mail and can confirm that reboot issue where it just sits and reboots at the birds. I am going to need some time to look into it, so everyone still having issues hang tight...

lartomar2002 · Jul 15, 2012

drkduncan said:
I nvflashed with both 250mb and the 300mb files.

Sent from my TeamDRH ICS for GTablet using xda premium

I was just wondering if you were sure you had the 250mb partition would it be necessary to nvflash. If you could just do a wipe/factory reset, wipe cache, wipe davilk cache and the flash the 1.3 rom. I will becoming from the 1.2 rom where I had done the nvflash and the 250mb partition before flashing the 1.2 rom.:fingers-crossed:

rajeevvp · Jul 15, 2012

ll77 said:
Can someone explain to me the 2gb partition in the instructions, can we use 4gb if we like?

Yes.

Is there a hardware/system limitation, or is it preference?

It's just a convention--basically, everybody's just following how things are on VS's stock ROM.

After my whole ride of trying every combo I could, I landed on a 4gb and 12gb partition, ICS seems to run fine, will I encounter a problem later?

No.

rajeevvp · Jul 15, 2012

tsukaza said:
I think the main reason to format 4g first then 2g is to make sure the sd card part is cleared out byond the 2g region.

Nope. No such "clearing out" happens with that kind of double/triple/... partitioning. It's simply a waste of time and a distraction from real troubleshooting. An explanation of what happens when you repartition an SD card might help:

A repartition step on an SD card using CWM on the gTablet involves 2 operations.

1. The actual partitioning.
Here, only the MBR--the first sector--on the SD card is written because all SD cards (and also things like USB sticks) are NAND- or NOR-based flash (MTD) devices, but they all look like regular HDDs which means that they all have interface-matching, sector-translation and wear-levelling circuitry (and, on the expensive ones, firmware) built into them. This is also why you can put the standard HDD filesystems like extn, FAT32, etc on them. Raw (untranslated) MTD devices need specialized filesystems like yaffs2 and jffs2 which are coded specifically for them (and, incidentally, you can't put these filesystems on SD card partitions).

2. The filesystem creation.
During a filesystem creation operation, only a few scattered bits of data are actually written to the device. If we run through the creation of an ext3 filesystem on an SD card (relevant bits in bold):

Code:

~ # [B]fdisk -l /dev/block/mmcblk2[/B]

Disk /dev/block/mmcblk2: 15.9 GB, 15931539456 bytes
255 heads, 63 sectors/track, 1936 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk2p1               1        1581    12699351   c Win95 FAT32 (LBA)
/dev/block/mmcblk2p2            1582        1825     1959930  83 Linux
/dev/block/mmcblk2p3            1826        1862      297202+ 83 Linux
/dev/block/mmcblk2p4            1863        1936      [B]594405[/B]  83 Linux
~ # [B]/root/mke2fs -j -m0 /dev/block/mmcblk2p4[/B]
mke2fs 1.42.4 (12-June-2012)
Filesystem label=
OS type: Linux
Block size=[B]4096[/B] (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
37200 inodes, [B]148601[/B] blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=155189248
5 block groups
32768 blocks per group, 32768 fragments per group
7440 inodes per group
Superblock backups stored on blocks: 
        32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

~ # [B]mount /dev/block/mmcblk2p4 /root/[/B]
~ # [B]df[/B]
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                   224188        32    224156   0% /dev
/dev/block/mtdblock4    222208      1296    220912   1% /cache
/dev/block/mmcblk2p4    [B]585040[/B]     16860    568180   3% /root
~ #

you'll see that the size of the partition is 594405 1K blocks, but, only 9365 1K blocks (594405 - 585040), ~ 9.4 MB, scattered all over the place, are written to initialize the filesystem--which involves, mainly, writing a new bootblock, new superblocks and group descriptor blocks, and bitmap and inode-related blocks; plus odds and ends like the bits needed to create the /lost+found directory and the journal (16MB in our example run above, and even here the journal is not "written" fully--only the space needed for it is marked as "allocated").

The creation of a VFAT filesystem is roughly similar. So, in both cases, not a lot of actual data is written, and in each case the writes are generally scattered all over the device.

Thus far, this discussion has been at the level of logical filesystem blocks. When it comes to which physical blocks on the SD card are actually written during filesystem creation, things look even worse for people who think some sort of clearing out happens because of the intervening wear-leveling circuitry: Only the HW knows which MTD blocks correspond to which logical filesystem blocks, and the physical MTD blocks standing in for the logical filesystem blocks keep getting rotated as needed by the SD card itself.

What I think people imagine happens during a repartition is something like this:

Code:

~ # [B]time dd if=/dev/zero of=/dev/block/mmcblk3[/B]

That command writes zeros to every sector of the internal SD card. Run the command while in CWM (repartition afterwards, please) and see how long it takes to complete. If a repartition step really cleaned out the internal SD card as people imagine, then you would have to wait 45 mins or so for that operation to complete instead of the minute or so that you have to now.

This is to ensure no data is left over from the previous ROM.

See the description above. I can guarantee you that unless there are ghastly bugs in CWM, the parted/e2fsprogs code or in the HW, a single repartition operation will get rid of all (user-visible) data on the SD cards.

---------- Post added at 02:06 PM ---------- Previous post was at 01:56 PM ----------

drkduncan said:
Sadly I tried everything I could think of, still no luck. Hopefully now that someone has sent their "stuck at the birds" device in for analysis there will be a fix. I have the CWM install log if that would be helpful. [Update: log attached]

Looking at the logs, I see that the ROM installation script is still cheerfully corrupting the /cache filesystem for no good reason. It also seems to be trying to remove the dalvik-cache from non-existent devices. Somebody should really scrutinize that install script.

---------- Post added at 02:35 PM ---------- Previous post was at 02:06 PM ----------

lartomar2002 said:
I was just wondering if you were sure you had the 250mb partition would it be necessary to nvflash.

Nope.

If you could just do a wipe/factory reset, wipe cache, wipe davilk cache and the flash the 1.3 rom.

Only a "wipe data/factory reset" is needed. You'll see that it does the other 2 (wiping cache and dalvik-cache) if you look at the messages the operation prints.

lartomar2002 · Jul 15, 2012

rajeevvp, thank you for all the help you and the others provide on the forum. With out you, many of us would only have a shiny book end. :good:

fosser2 · Jul 15, 2012

lartomar2002 said:
rajeevvp, thank you for all the help you and the others provide on the forum. With out you, many of us would only have a shiny book end. :good:

I second this post. Thanks for all you do man!

cubexg · Jul 16, 2012

Working - but very sluggish

Ok - so I flashed the Rom successfully (GTab has been sitting around collecting dust for a while - figured I'd try some ICS goodness on it) and it seemed to go just fine (Was running a Honeycomb variant before). Did the wipe, partition, TNT from the first post here (nvflash) then the Rom itself. Installs just fine, but everything is running lagged like crazy.

I don't mind blowing the unit away, but what would be suggested to ensure it's completely clean and working properly? A MicroSD couldn't be causing this could it? For example, playing back a DiVX off the MIcroSD w/ MX player worked great - but chrome will take forEVER to load, and once loaded, seems OK, until something else goes on in the background - then tons of FCs.

Thanks!

Nospin · Jul 16, 2012

cubexg said:
Ok - so I flashed the Rom successfully (GTab has been sitting around collecting dust for a while - figured I'd try some ICS goodness on it) and it seemed to go just fine (Was running a Honeycomb variant before). Did the wipe, partition, TNT from the first post here (nvflash) then the Rom itself. Installs just fine, but everything is running lagged like crazy.

I don't mind blowing the unit away, but what would be suggested to ensure it's completely clean and working properly? A MicroSD couldn't be causing this could it? For example, playing back a DiVX off the MIcroSD w/ MX player worked great - but chrome will take forEVER to load, and once loaded, seems OK, until something else goes on in the background - then tons of FCs.

Thanks!

Mine running smooth for the most part. Pro tip- Don't use Chrome. It seems to be optimized for Nexus devices only, everyone else has a painfully slow time. Dolphin HD is much better.

the3dman · Jul 17, 2012

rajeevvp said:
Looking at the logs, I see that the ROM installation script is still cheerfully corrupting the /cache filesystem for no good reason. It also seems to be trying to remove the dalvik-cache from non-existent devices. Somebody should really scrutinize that install script.

Thanks for noticing this rajeevvp, I have cleaned this up for future releases. I appreciate the help.

nobe1976 · Jul 18, 2012

cubexg said:
Ok - so I flashed the Rom successfully (GTab has been sitting around collecting dust for a while - figured I'd try some ICS goodness on it) and it seemed to go just fine (Was running a Honeycomb variant before). Did the wipe, partition, TNT from the first post here (nvflash) then the Rom itself. Installs just fine, but everything is running lagged like crazy.

I don't mind blowing the unit away, but what would be suggested to ensure it's completely clean and working properly? A MicroSD couldn't be causing this could it? For example, playing back a DiVX off the MIcroSD w/ MX player worked great - but chrome will take forEVER to load, and once loaded, seems OK, until something else goes on in the background - then tons of FCs.

Thanks!

OK guys I have been running the new update for quite some time, also ran the leak for a bit also. Been messing around with the build prop and found that these setting work out pretty well. Also added my performance setting as well. Both attached as screenshots so you get the full picture.

aliensquale · Jul 18, 2012

Rajeewp,
thank you very much for your help.

regarding what you say below... since I already installed this beta build last week, is there something I need to do post install now to clean up the filesystem to speed this thing up? it seems very slow now running 1.3, prior to this I was running CM7 and the tablet was much faster.

rajeevvp;28792231 Looking at the logs said:
is still cheerfully corrupting the /cache filesystem[/URL] for no good reason. It also seems to be trying to remove the dalvik-cache from non-existent devices. Somebody should really scrutinize that install script.

fosser2 · Jul 18, 2012

aliensquale said:
Rajeewp,
thank you very much for your help.

regarding what you say below... since I already installed this beta build last week, is there something I need to do post install now to clean up the filesystem to speed this thing up? it seems very slow now running 1.3, prior to this I was running CM7 and the tablet was much faster.

Try this rom.

MD5: 37ac6d098c9891f0b06491fbe0c87303

Download: http://www.teamdrh.com/DRH-Downloads/TeamDRH-ICS-Beta-1.3.2.zip

It has that issue w/ cache fixed. It also should operate faster.

Oh and PS: here is where we're at with jellybean

aliensquale · Jul 18, 2012

I have to install the whole ROM over again? can't I just make some setting changes inside my existing ROM?

I already have my apps all back up and settings all done. I DO have a titanium backup. can I restore ALL system apps PLUS data as well as the user apps and data?

fosser2 said:
Try this rom.

MD5: 37ac6d098c9891f0b06491fbe0c87303

Download: http://www.teamdrh.com/DRH-Downloads/TeamDRH-ICS-Beta-1.3.2.zip

It has that issue w/ cache fixed. It also should operate faster.

Oh and PS: here is where we're at with jellybean

---------- Post added at 01:21 PM ---------- Previous post was at 01:12 PM ----------

the other issue I have on my Gtab... not sure if this is related to the ROM or not.. is that my battery indicator ALWAYS shows 100%. I tried wiping battery stats multiple times in Clockwork but not luck. I also let the tablet's battery drain down to power off. Then plugged it in, booted into clockwork and did another battery stats wipe. Still not luck.

any fix for this?

btw.. after I installed the rom I had to run a little app to make the touchscreen more sensitive called: TouchRecalibrate

rajeevvp · Jul 18, 2012

aliensquale said:
regarding what you say below...

That's unrelated to whatever slowdowns you're experiencing. But, to clean up /cache, just boot into CWM and "format /cache".

it seems very slow now running 1.3, prior to this I was running CM7 and the tablet was much faster.

Yeah. The performance is pretty bad and I'm not sure exactly where the problem lies. Most people point to the paucity of memory being the culprit, and while it may contribute quite a bit, I don't think that's all there is to it: For one thing, there are phones with just 512 MB of RAM comfortably running ICS on them. For another, I see a lot of ANRs and processes being sent SIGQUITs (SIG 3 in the logs) to generate those ANRs. For yet another, the CPU load looks very high when there's lag.

I also see that the ro.build.type is set to "userdebug" in /system/build.prop instead of the commonly seen build.type of "user". Changing the build.type to "user" stops most of the ANRs. I don't know how Android is built, but, in the Linux world, we usually have 2 kinds of builds for a product: release (what gets shipped) and internal (AKA engineering). The difference is mainly in what compiler flags are used when building the product. For engineering builds, compiler optimizations are turned off and the debugging flags are turned on. These builds are pretty slow and use a lot more memory and CPU than the release builds. Going by what I said about the build.type and ANRs above, this is one thing for the devs to check.

Try these things to reduce lag:

In Settings > ROM Control (set on boot if you're happy with)
1. Reduce dalvik VM heap size for apps to 64M.
2. Reduce the free memory setting to 50MB.

In Settings > Developer options (need to set on each boot)
3. Reduce the no. of Background Processes to 1 or 2.
4. Check the Destroy Activities ... option.

Those last 2 really make a noticeable difference, but, you can, if you wish, skip 1) and 4) and still not impact performance all that much.

the other issue I have on my Gtab... not sure if this is related to the ROM or not.. is that my battery indicator ALWAYS shows 100%. I tried wiping battery stats multiple times in Clockwork but not luck. I also let the tablet's battery drain down to power off. Then plugged it in, booted into clockwork and did another battery stats wipe. Still not luck.

It's the battery. Don't know what triggers it, though, or how to fix it. I'm trying to look into it.

One final thing before I hit the sack:
Most things that people do to detect bad blocks on the NAND (only looking at the dmesg output, for instance) is not very effective. Here's a simple way to be absolutely certain that the ROM has been installed correctly and fully onto the gTab. The idea is an old one, going back to Dan Farmer and his COPS package (early 1990s). Basically, it is to:

1. have the ROM packager calculate on his dev box the SHA1 checksum of every file that will be installed.
2. Install this SHA1 checksum file along with the ROM--as, let's say, /system/etc/ROM-files.sha1. (Remove entries for files not installed during installation--not very hard)
3. User can check using a shell script (or the command below) that the ROM is OK any time he/she wants. If the checksums compute OK, then you too, like me, can sleep blissfully, untroubled by thoughts of any bad blocks doing naughty things to your nice ROM.

Sample creation of ROM-files.sha1 on packager's dev box. Assuming that all files that go into the ROM are in the system/ and data/ directories in their correct locations:

Code:

$ [B]sha1sum `find system data -type f` | tee ROM-files.sha1[/B]

To check ROM state (on gTab):

Code:

gTablet$ [B]su[/B]
gTablet# [B]cd /[/B]
gTablet# [B]sha1sum -c system/etc/ROM-files.sha1 2>&1 | fgrep -v OK[/B]
gTablet#                            [I]No news is good news[/I]

raywaldo · Jul 19, 2012

Speeded up my GTab!

rajeevvp said:
Try these things to reduce lag:

In Settings > ROM Control (set on boot if you're happy with)
1. Reduce dalvik VM heap size for apps to 64M.
2. Reduce the free memory setting to 50MB.

In Settings > Developer options (need to set on each boot)
3. Reduce the no. of Background Processes to 1 or 2.
4. Check the Destroy Activities ... option.

Those last 2 really make a noticeable difference, but, you can, if you wish, skip 1) and 4) and still not impact performance all that much.

Thanks Rajeevvp! You did it again!!

I had given up on this ROM and decided to dump it. I just tried all four things and there is a NOTICEABLE improvement. I could not use the device previously, now it is very responsive.

Ray

[ROM - 1.2] BETA ICS 4.0.X - Team DRH (Update 07/02/12)

Senior Member

Member

Member

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts