[General Omni Discussion] GidiK:
That's a shame. It was a long shot anyway. Thanks for testing!

You're right about the Kconfig thing; I should have changed the default as well.

The board does indeed have Cortex A9 cores, so the compile flag is nothing weird. What I thought was suspicious was that in no official released kernel sources for any exynos4 device (phones, tablets, dev board) I could find it being used. So I thought maybe they know something we don't...

There's no point in me removing the cortex-a9 flag from the ROM build, since I can't reproduce the problem anyway... And the kernel is currently running fine with the modification; subjectively it feels better already...

Edit: by the way, are you sure the rsync test reveals the same bug? I tried to do it your way, but I don't have rsync, so I used cp. I had the same experience: it went ahead fine and then it just got stuck and the cp used loads of cpu without anything real happening. However, here's the difference: the cp process was using the cpu's and not sdcard (fuse) as in the bug. Since you used the paths that go via fuse, you'd expect fuse to freeze up, not rsync/cp. Also, while frozen, I was able to access files on the card quite fine and even play music. And testing this long enough without breaking it off, I noticed that the cp operation eventually finished and even all files were accounted for. So, weird behaviour because it shouldn't get that slow, but not actually stuck like in this bug. I did the same test using the paths that bypass fuse (so cp was taking the role of fuse, proven by the fact that cp -a produced no chmod error messages), but the effect was the same: very slow but got there in the end. When you do the rsync test over the fuse-mounted paths, is it sdcard (fuse) that gets stuck or rsync?

I'm currently doing the same test on the official nightly. It is even slower... probably really stuck: 30 minutes in and just 15 files copied... of which one twice? I'm giving up...

---------- Post added at 11:21 PM ---------- Previous post was at 10:46 PM ----------

Agreed. But how?

I've used stock firmware for more than two years, from GB 2.3.4 to JB 4.1.2, and I've never run into this problem. Loads of others, but not this. I've also used Dori's kernel under JB for while and I don't think the problem happened either. It just happened occasionally under this kernel and under KK (because of fuse). So, if we would find a way to reproduce this, and want to test the stock kernel as well, we would have to run it under KK, or in some other way with fuse. Which I assume is impossible...

Or the problem could just be because my phone is really old now (3.5 years of abuse) and the memory chips start to wear down.

Thinking about it... there have been some stock firmwares with the media scanner issue. If during its scan after startup it encountered 'a bad file', it would heat up the cpu and drain the battery. This got fixed by wiping the sdcard, getting rid of the so-called 'bad file'. I've never seen anybody explaining what such a 'bad file' looked like... Maybe that was actually the media scanner getting in the same bother that fuse is getting into now? Does that make sense? I always assumed that was a different issue.