[G Tablet Q&A, Help & Troubleshooting] rajeevvp:
Your initial post, as I said; this one:

Moving the wlan driver into its proper location on HC is done to make sure the kernel gets the correct driver. It is not done in the hope that it will fix old corrupted drivers.

I see you're still pushing corrupted data as the cause of the user's very specific errors. OK, I'll give it one more try.

Let's restrict ourselves to loading and running of kernels from corrupted zip files which is what I said was highly improbable. And let's also restrict ourselves to plain zip files, not signed ones.

1. Zip files (in fact, all compressed archive files) have a whole-file CRC32 value stored somewhere in them. This is to protect against corrupted zip files. The decompressor reads the whole file, computes a 32-bit (if I remember this right) CRC then checks it against the one stored in the zip. If there is a mismatch, it doesn't start extraction. Common sense, right? OK, now CRCs are not guaranteed to catch all errors, but, they will catch most of the common ones (ie. errors in random locations in the file--the most common scenario). This is the first hurdle.

2. Assume a corrupted file manages to pass through that hurdle. For this, again, each zip file member inside the zip archive has its own individual CRC32. If this CRC doesn't match, the file is not extracted. This is the second hurdle.

3. Alright, through some freakishly improbable occurance file data is corrupted, but, still the CRC32 matches and the bad kernel is written out. Now what? If you look at the kernel zImage format, you will see that it starts with some executable code, then there is the decompressor and then the compressed kernel program. This compressed kernel has its own CRC (stronger or the same depending on the type of compressed kernel). The kernel decompressor will check this and simply not load the kernel if there are any mismatches. This is the third hurdle.

For all these 3 cases, even if the CRC checks out ok, but, the data is bad, this bad data is likely to choke the decompressor and halt or hang the decompression process.

4. OK, assume freakish chance again (now exceedingly freakish or some genius in cryptography cunningly crafting the exact bytes needed to pass muster) and say the bad kernel is loaded into memory (this part of the argument also applies to kernel modules). Chances are that random bit errors will land somewhere in the kernel code region (simply because they comprise the majority of the kernel) changing instructions there. And most likely result of this scenario? Kernel panics, lockups, reboots, etc. Not mmc probe timed out errors. If the error lands in the data portion of the kernel corrupting some critical variable, then maybe it is possible, but, only if it lands on just the right one--something like shortening a timeout variable. What is the probability of this happening?

How does this help our discussion? We were not addressing some random errors; we're talking about the causes leading to our very specific error message. If you want to figure out how some of those errors were caused, we'll again have to look at those specific errors, one by one, right?

If even after all the explanations I've given you still think it's a corrupted data error that can be "fixed" by giving the gtab an enema, then I abandon hope. It sure looks like it going in that direction.