Ideas for SDcard/mount issues in Viewsonic source

---

Since we had such an excellent turn-out in the ideas for lag-on-wake thread, resulting in a team effort to get the kernel bug identified and fixed, I figured we could do the same for the SD Card issues in the Viewsonic source code that result in some apps disappearing or being unable to install unless you unmount the internal SD card area before installation.

Rothnic does have a request into Viewsonic, since they seem to have addressed this issue between their two kernel builds but they neglected to release the patch for it.

But... that could take several days or several weeks to trickle through the bureaucratic food chain. I suspect this is a small change if we can isolate the area.

What I tried so far:

Just the dumb-obvious. There are three mmc drivers directories in the VS patch, mmc, mmc_orig, and mmc-new. The only one getting built is the mmc directory. I diffed the mmc and mmc-new files, and tried building the mmc-new driver instead, but didn't observe any difference in behavior with respect to the mounting issues (i.e. error -18 when I try to install Angry Birds from market). The diff between these driver file sets is quite small, and limited to a few files.

What I suspect:

There is an "install to SD card" option built-in to some apps. I suspect that the apps affected by this may be the ones that enable this option. Perhaps something to do with the loopback device Android tries to create on the SD card for external app storage (http://android-developers.blogspot.c...d-details.html)?

Why this relates to the kernel:

Well, the issue doesn't occur with the latest kernel build from Tap N Tap and does with our kernels. There are user-space workarounds (unmounting SD card) and some of that may be workable into our ROMs, but I'd like to get a kernel that is a drop-in replacement for the stock kernels.

Consider the following patch which just enables some "stuff" in the kernel.

http://nv-tegra.nvidia.com/gitweb/?p...406709b34480d6

For me clicking on the link you included yields a page not found...

Originally Posted by rcgabriel

Since we had such an excellent turn-out in the ideas for lag-on-wake thread, resulting in a team effort to get the kernel bug identified and fixed, I figured we could do the same for the SD Card issues in the Viewsonic source code that result in some apps disappearing or being unable to install unless you unmount the internal SD card area before installation.


There is an "install to SD card" option built-in to some apps. I suspect that the apps affected by this may be the ones that enable this option. Perhaps something to do with the loopback device Android tries to create on the SD card for external app storage (http://android-developers.blogspot.c...details.html)?

Originally Posted by rcgabriel

some apps disappearing or being unable to install unless you unmount the internal SD card area before installation.

Is it possible to unmount the internal SD card area while running the OS? I've used the mount / unmount options in CWM, but have not found a way to unmount /sdcard inside the OS. Wouldn't this be like cutting off the branch you are standing on? I'm currently running TnT Lite 3.1.2. Thanks.

Just a thought, but how does a standard android system's mounting structure run? Isn't it something to the tune of some other root folder than /sdcard, and when an sdcard is inserted that gets mounted to /sdcard? Is there a reason we don't have our roms mounting in this way, and would this not improve compatibility with the android system and apps as a whole?

If the issue is that people would then have to have an sdcard for a lot of things, perhaps we put those to /sdcard2 and partition a gig or two slice of the internal storage to mount at /sdcard so the internal storage can abide both concerns..

Am I way off in just thinking the systems mounting structure might be better served to mirror a standard android system? Does it already and I'm just being dingy?

Originally Posted by vsc

Consider the following patch which just enables some "stuff" in the kernel.

http://nv-tegra.nvidia.com/gitweb/?p...406709b34480d6

For me clicking on the link you included yields a page not found...

Fixed that link, but yeah, that looks like a very promising patch, and it's just config file changes....

The question is whether the CONFIG_BLK_DEV and CONFIG_BLK_DEV_LOOP stuff is also dependent on other patches to the mmc driver or other kernel files.....

EDIT: I cherrypicked the relevant-seeming config file changed from that patch, rebuilt the kernel, and am testing it.

BINGO! Angry birds installs again without having to remount. More coming...


See config_patch attached for the specific changes I made. For kernel devs, just unzip this into your arch/arm/configs dir and patch -p0 < config_patch.

I figured...

The thing that I don't know is why does TnTLite not have issues. But this can't hurt. Post your config so we are working with the same configuration and I'll give it a try with TnTLite.

Originally Posted by rcgabriel

Fixed that link, but yeah, that looks like a very promising patch, and it's just config file changes....

The question is whether the CONFIG_BLK_DEV and CONFIG_BLK_DEV_LOOP stuff is also dependent on other patches to the mmc driver or other kernel files.....

EDIT: I cherrypicked the relevant-seeming config file changed from that patch, rebuilt the kernel, and am testing it.

BINGO! Angry birds installs again without having to remount. More coming...

Originally Posted by vsc

I figured...

The thing that I don't know is why does TnTLite not have issues. But this can't hurt. Post your config so we are working with the same configuration and I'll give it a try with TnTLite.

Config uploaded above. I included the crypto stuff because I believe the loopback block device that Android uses requires it, but everything may work without it. Not certain.

I think the crypto stuff is required.

Originally Posted by rcgabriel

Config uploaded above. I included the crypto stuff because I believe the loopback block device that Android uses requires it, but everything may work without it. Not certain.

Very nice find guys.

Have now integrated this into my kernels posted in the lag-on-wake issue thread.