yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] Lanchon:
it doesnt. the modem is another cpu, running an different closed-source OS that is not linux. the CPUs should be isolated.

EDIT: http://www.youtube.com/watch?v=TzR7R6fBr00
[General Omni Discussion] nex-54:
It looks, live i still have problems after patch.

On some big audio files(audio books) in some places(every time the same) i hear some sound and playback starts play a part from other place. After some seconds i hear same sound and playback returns play where it should be. It happens on all audio players the same way and place. But not on all audio books.
[General Omni Discussion] Lanchon:
if u dont need reboot after the bug to access storage again its not the bug. download the files to the pc and verify they are not corrupted. if they are, what emmc model and fwrev you have?
[General Omni Discussion] nex-54:
hmm...you are right. They become corrupted after copy to sd card. They are corrupted even after copy back to pc. I will try other sd card and internal storage.

Sorry, but i don't know, what does "emmc model" mean. I have CyanogenMod 11-20140916-SNAPSHOT-m10-i9100.

Before flashing to android 4.4 i have no such problems.
[General Omni Discussion] Twiq:
See my attachment (eMMC Chip type and REV, ignore the CID), it's taken with GotBrickbug app by chainfire, and of course there are lots of other alternative apps..
[General Omni Discussion] Lanchon:
the emmc is irrelevant. he didnt say in his first post but he was using an external sdcard. its not fusebug. its not wear leveling bug. he just has a corrupted or bad sdcard.
[General Omni Discussion] Lanchon:
FP corruption detector

a native executable loads all 32 "d" regs with a pattern (0xPPDDPPDDPPDDPPDD where PP is process id and DD the "d" reg number). then continually checks them until some are changed, outputs the differences and ends.

#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>

#include "vfp.h"

static inline void fill_reg(u64* reg, u16 val) {
typedef union {
u64 p64;
u16 p16[4];
} u;
*((u*) reg) = (u) { .p16 = { val, val, val, val } };
}

void main(int argc, char *argv[]) {
setbuf(stdout, NULL);
int p = 0;
if (argc == 2) p = atoi(argv[1]);
printf("p%i: start\n", p);
vfp_regs put;
for (int i = 0; i < VFP_REG_COUNT; i++) {
fill_reg(&put.d[i], (u16) (p << 8 | i));
//printf("p%i/d%i: %" PRIx64 "\n", p, i, put.d[i]);
}
vfp_load_regs(&put);
for (;;) {
vfp_regs get;
vfp_store_regs(&get);
bool end = false;
for (int i = 0; i < VFP_REG_COUNT; i++) {
if (put.d[i] != get.d[i]) {
printf("p%i/d%i: %" PRIx64 " -> %" PRIx64 "\n", p, i, put.d[i], get.d[i]);
end = true;
}
}
if (end) break;
}
printf("p%i: end\n", p);
}

this is bundled into an app that launches 4 of these processes (p1 to p4) and shows their output. there are 2 processes per core, so the kernel is going to be context-switching between them. the idea is that if corruption comes from some form context switch somehow, we well see the crosstalk between the processes in the values of the registers. if the corruption comes from ISRs or kernel threads, the data displayed will be foreign. if a hypothetical context switch bug is related to switch laziness and needs a full time-slice of no FPU activity to manifest itself, we wont see corruption. if the corruption needs a thread calling something like pread64, we wont see it either.

the app is a quick hack and wont terminate the processes correctly, you might need to reboot after running this app.

sources included.
[General Omni Discussion] Lanchon:
the above test can also be run via adb shell after install, the executable is in /data/data/lanchon.fpbug/lib/libfpbug.so (never mind the lib name its an executable).

guys, please run it and if anything is printed get a snapshot. may need another workload to trigger the bug. taring sdcard contents (via fuse) or even /system (no fuse) to /dev/null can be tried.
[General Omni Discussion] tusko5:
For how long do you think it should be executed? I have executed it for around 5 minutes without any output.
[General Omni Discussion] Lanchon:
are you usually affected by fusebug? can you reproduce the conditions? (MTP transfer, whatever app that causes it, etc)

try reading the sdcard (via fuse) while running the thing. adb shell to it, then:

cd /sdcard

tar -cv . >/dev/null
​

or bypassing fuse:

cd /system

tar -cv . >/dev/null
​
[General Omni Discussion] Lanchon:
hey [MENTION=5054150]GidiK[/MENTION], had a chance to try the bug catcher? make it catch something, we need your creative testing! :)
[General Omni Discussion] GidiK:
No corruption detected at all. I tried with the app and with starting the executable four times, the latter I let running for around an hour. The load of the four threads on our poor old cpu is so high, that it's not really possible to do anything else at the same time; at least not on screen. I tried running the tar processes, dumping both sdcard0 and sdcard1 to /dev/null at the same time, and these finished ok. I used an Omni nightly and your apk/executable.

When the load gets too high, by trying to do some stuff on screen as well, the system goes into a soft restart: bootanimation, but the adb shell processes remain running.

I guess we do need some pread64 as well...

Meanwhile, another test I did is with my Tab 7.7. This has stock Samsung JB 4.1.2, is an smdk4210 and uses fuse as well. The latter I hadn't realized, but because this is a /data/media device unlike the SII, it uses fuse to provide sdcard0. When I run the tar test it finished all 10 runs without a problem.
[General Omni Discussion] Lanchon:
thanks so much!! yes, /data/media uses fuse, but it is a different fuse file system implementation. but unless the FP bug manifests itself somehow in the platform (that kernel might not be affected) then testing there is not indicative of anything (if the test comes out negative, as it did).

my app is not killing the processes correctly, so maybe you opened it a couple of times in a given reboot and you had much more than 4 processes running.

if possible, id like to ask that you repeat the app test:

1) running the app just once, and while it's in the foreground adb shell tar /system (instead of the /sdcard). this will probably not trigger the bug, but just to be sure.

we also need another round of testing to figure out whether power management is involved. assuming that on standard CM or omni (sdcard not patched) taring the /sdcard kills the fuse process predictably (please tell me if not), please test this:

1) verify that adb shell tar kills fuse.

2) in developer options configure the screen to never turn off while plugged in, then repeat the adb tar test. if the bug is not triggered, we have a strong indication that PM is involved.

3) only if 2) triggered the bug: with screen-on-forever still enabled, run my detector app (once), and while it's in the foreground repeat the adb tar test. if the bug is not triggered, we have a strong indication that the CPU must sleep for the bug to happen.

i'm sorry to have to ask you to test. no one else seems interested in doing it :(
[General Omni Discussion] ajislav:
Hi Lanchon,

I was not able to trigger the bug while running your app and tar -cv . >/dev/null on /sdcard which took about 6 mins on my device

OTOH, I don't really experience the bug in general... Is there any reliable way to trigger it?

note: device connected to charged, wireless ADB, CM11+your trim kernel

ajislav

p.s. thanks for all your trim and fuse efforts
[General Omni Discussion] Lanchon:
thanks!

i dont know, dont have the device. i hear that (without my patch) you just tar sdcard and that will do it. dont know if display must be off, device must be off charge, or other details though.
[General Omni Discussion] Rapepini:
Thanks for the fix! Does it work on m11 snapshot build?
[General Omni Discussion] NeoTrantor:
Seems the fix didn't make it into M11. I think some more testing is required. I hope M12 will have the fix :)
[General Omni Discussion] zeitferne:
Actually, it is more of a clever workaround than a real fix. The root cause of the problem (why does the sdcard daemon receive bad values in the d8 floating point register?) is still unknown and may affect other apps and subsystems too.
[General Omni Discussion] NeoTrantor:
sen oupdein

Sure, but I doubt there will be a real fix at all.
[General Omni Discussion] GidiK:
Tarring /system as well as /mnt/media_rw/sdcard*/ is not showing any problems.

I verified that running tar c storage/sdcard1/TWRP still predictably hangs. It started to get less reproducible lately, but today it was completely repeatable. So, with screen off, usb connected, running tar over fuse freezes every single time; in the same circumstances running tar on the same files but circumventing fuse, it never freezes. Note that as I said before I don't claim that this is the same problem that started this thread, but it is a problem. Notably, for me it is the program that uses fuse (in this case tar) that freezes due to unexpected events, not sdcard/fuse itself. And it's this effect that disappears by changing compiler options, changing struct sizes, etc, of the sdcard (fuse) program.

When I keep the screen on, the same test didn't run into problems. I repeated several times. Then I retested with screen off and it hang almost immediately.

Just to be complete I tested with screen on and your program running, and again there were no problems.

I also tested with starting with screen on, then turning the screen off with the power button. It failed almost as soon as a did this, but that could have been a coincidence.

This was all with adb over usb (with Omni nightly), so the device was officially charging and therefore shouldn't go to sleep. But screen off/on seemed to have a clear influence (today). I believe Chainfire found out the same with OpenDelta a while ago, if I remember correctly.
[General Omni Discussion] Lanchon:
yes, there have been no changes to CM's sdcard.c since february.

---------- Post added at 02:52 PM ---------- Previous post was at 02:31 PM ----------

thank you so much for testing. it seems power management is a necessary ingredient, which complicates testing considerably. i don't think i can make progress without a device, there's too much to test. if i could, next i would test:

-my fpbug.c (4 concurrent process, manually or using app) alone with screen off

-my fpbug (4 processes) with screen off while tarring /system or /mnt/media_rw/sdcard0

(i know these tars dont kill fuse; of course, fuse is not involved. but they do trigger hardware actions that seem to be part of the bug trigger.)

-if both tests above come out negative, next would be moving the file reading inside fpbug.c
[General Omni Discussion] zeitferne:
Maybe it would also be interesting to try the Performance CPU governor. And, just a shot in the dark, does the pattern of "cpu1 turnning off!" (followed by "IRQ112 no longer affine to CPU1") messages in /proc/kmsg change when keeping the screen on vs. letting it turn off?

EDIT: I have found some time to test this myself, and the pattern of "cpu1 turnning off!" messages does not change. I also found that the "stay awake" option seems not to work for me, the screen goes off anyway (yes my phone was plugged in). However, by manually keeping the screen on, I too was able to keep the sdcard daemon from screwing up. Setting the performance CPU governor also does not keep cpu1 from turning off, and neither does it change anything other about the bug.
[General Omni Discussion] Entropy512:
Is that 7.7 a wifi-only device?

Also, keep in mind that I've mentioned a few times - I'm fairly certain this issue is, somehow, related to a mismerge of 4210 support into the 4412 kernel. That's why it would be useful if someone with more time than I have tried to get the old smdk4210 kernel up to the bare minimum requirements for 4.4 (main change would likely need to be the Mali drivers I think) and see if this problem affects the device when using that source tree.
[General Omni Discussion] Entropy512:
Hmm... I know in some cases, it's been possible to force-disable hotplugging, either never plugging in the second core, or never plugging it out.

I do have some time to try whipping up some test kernels that disable hotplugging to see if it changes anything. Maybe later this week...

Screen-on vs. screen-off has been known for quite some time... That was the origin of OpenDelta's "keep screen on" patch.
[General Omni Discussion] zeitferne:
Is there more information burried in this now quite long thread? All I know is that the d8 fpu register of a sdcard daemon thread is corrupted during pread64 (i hope it has been ruled out that it happens between pread64 and fuse_reply). Since the time after which the issue occurs seems not to follow any pattern, it is speculated that an interrupt occuring at a particluar time during pread64 causes the problem.

The problem goes away when…

The buffer passed to pread64 is aligned to the begin of a memory page, or when some particular other changes to the struct fuse_handler are made. (IMHO quite interesting) (discussion starts here)

The screen is kept on.

The filesystem is something other than FAT32 (exFAT and ext4 were tested); it is speculated (?) that this is caused by the different timings of pread64 on these filesystems.

Enabling ARM_ERRATA_761320; but with bad side effects. (Only tested by GidiK).

While this does not fix the problem:

Using the performance CPU governor.

Overwriting the kernel's entire arch folder with Samsung JB i9100 sources (w/o changing configuration or deleting files).

Changing the hotplug policy to legacy, as it was in the Samsung sources.

Removing the SIM-Card or going into flight mode.

The d8 corruption also seems to affect only programs that call pread64 themselves: Running lanchons FPBug test while reproducing the sdcard bug did not affect the test .

We also know that the problem exists in the dorimanx and gustavo kernels for i9100/S2 but not in the same kernel configured for and run on the S3.
[General Omni Discussion] Twiq:
I've asked [MENTION=1670821]cybernetus[/MENTION] to enable the errata on dorimanx (10.44v006), it plays nicely with [MENTION=4141005]Lanchon[/MENTION]'s sdcard binary btw
[General Omni Discussion] Entropy512:
The screen-on/off stuff was way back in the beginning. This issue was affecting OpenDelta, and the workaround for OD was to always keep the screen on during an update on these devices. Not sure WHY this occurs, unless possibly vsync interrupts are altering the timing of other interrupts...

Changing the hotplug policy may not alter things much, as it changes hotplug timing/conditions, but doesn't outright disable it. I'm curious what happens if the device is forced into a given core configuration. (Although screen on vs. off shouldn't affect this.)

What's tough is that just altering timing can significantly alter the frequency of the bug. I know Chainfire found that it was very difficult to reproduce the bug if he enabled debugging prints in the sdcard daemon. (Fortunately, others had more luck triggering stuff with various debugging enabled.)

Why would you ask someone to enable something known to cause issues?
[General Omni Discussion] zeitferne:
I don't know much about Android's power management, but I would expect that when the screen is off, this causes other subsystems to go into some sort of power saving mode too.
[General Omni Discussion] NeoTrantor:
Any news? :D
[General Omni Discussion] Lanchon:
a couple of weeks ago i dropped out of the hunt for this bug because i dont have a device and i needed to post tests for others to run instead, and there were not enough interested parties here, having to wait a week maybe for someone to test.

but ive been meaning to do write on what ive found, in case someone else wants to continue. i havent had time so far.
[General Omni Discussion] JamesMayer:
For anyone who wants to know more details, please see the mailing list thread posted by [MENTION=4141005]Lanchon[/MENTION], it contains a more detailed and concise starting point for finding a full fix than this xda tread.

vvvvvv.spinics.net/lists/arm-kernel/msg368417.html

^replace the "vvvvvv" with "www"

Is there any chance of landing the current workaround in the official cyanogenmod releases? Perhaps also including the TRIM kernel functionality.

Also, is this the last issue that is preventing the n7000 from having a cyanogenmod M-release? The cyanogenmod team is not replying to me, and I cannot find a list of known issues for the n7000 - especially since we are not allowed to post issues on JIRA for nightlies. It is very frustrating for me to not have a testing version that does not suffer from all the breakage from new untested functionality in nightlies. Perhaps someone can convince the cyanogenmod team to produce a monthly *untested* M-release for our device, called something like cm-11-20141008-SNAPSHOT-M11-UNTESTED-WILL-BRICK-YOUR-DEVICE-n7000.zip that is using the same sources as the other M-releases.

I cannot post on the developer forums due to too few posts posted by me - so on an unrelated note to this issue, why are we not using newer Mali drivers, like r4p1 for our Mali-400? In addition, what prevents us from using a newer kernel, such as 3.12, which might actually have a fix for our FP register corruption. At the very least, we should aim to upgrade our kernel to 3.0.101 since it has some security fixes compared to our 3.0.64.

Edit:

I have the n7000 and am willing to bring it up to have full official M-releases, but I first need to know why we are not having M-releases yet, I need to see a list of known issues, and reasons for why we cannot fix those issues. I am also willing to test things on this device.
[General Omni Discussion] Lanchon:
yes, i had few exchanges on the arm linux mailing list a while back. i intend to post what little came out of it.

dont mix trim with this. btw trim WILL NOT be included in CM anytime soon. you should try other kernels first. but IMO the TRIM bug present on some d710's hasnt been tested to be safe (though it should be) because owners havent cooperated. that is the remaining piece of the puzzle. until such time, i wont push for TRIM on any other kernel. but you are welcome to do it. thats the whole point of my project, that TRIM goes official.

a while back i entered a feature request for unsupported monthlies at CMs jira, proposing the sort of thing you are talking about. its a buildbot change so i cant implement it, and theres politics around it. so far ignored. google it and make some noise around it.

finally, this is an omni thread of the fp bug. please dont discuss CM or other issues here.
[General Omni Discussion] mkalic:
I love my N7000, it's amazing with kitkat, if it only weren't for this bug... I'm afraid it's to old for any serious developers to consider spending time on it. I guess I'll stick to Slimrom JB.
[General Omni Discussion] Entropy512:
The biggest thing blocking N7000 from CM release is no active maintainers. The primary CM maintainers for the device (myself and xplodwild) both are with Omni now - and neither of us touch our device more than once every 1-2 months these days.

There were a whole pile of issues - general poor performance, nonfunctional hwcomposer, various games would crash (although new Mali blobs might have fixed that). The N7000 should never have received M or stable CM10.1 builds - N7000 getting marked for "stable" CM10.1 even though it wasn't even remotely stable and neither maintainer OKed it (Cyngn wanted to "cook the books" as far as number of users of stable releases to make themselves look good to investors) was one of the final straws of many of the Omni team completely giving up on any possibility of remaining with CM.

And as far as TRIM - there's no way in hell you'll have any maintainer who has any clue what they're doing include that. Including that involves taking Samsung at their word that insecure erase is completely safe and only secure erase will trigger Superbrick. The problem is, Samsung have proven themselves to be pathological liars. Hell, they lied to my face when I met with them to discuss Superbrick in 2012. They claimed to me that the process for repairing damaged eMMCs failed frequently (over 50%) in their lab and left a completely unrepairable device by any means.

About 6 months later someone found a leaked eMMC datasheet and found a method for repairing Superbricked eMMCs if you can boot the device via another means. Multiple users have recovered Kindle Fires this way. Unfortunately, Samsung won't provide people the necessary components to boot the device via USB, so there's no way to repair Superbrick on the 4210 family. (The repair process completely wipes the chip including bootloader.)
[General Omni Discussion] Lanchon:
now that you mention it, ive always wondered... what is stopping us from resurrecting dead 4210 mobos by doing this: use JTAG to send commands directly to the emmc to do the emmc partition resize trick and reset the module, flash the bootloader over JTAG, boot, odin?
[General Omni Discussion] aagii0715:
Any soution?

Please help how solve this
[General Omni Discussion] zeitferne:
To fix the most visible effects of this bug (i.e. Music and file copy/MTP transfer hangs) you can flash Lanchon's fix. As he says, it should work on any Kit-Kat (4.4) based ROM, AFAIR the only thing it does is replacing the /system/bin/sdcard executable.
[General Omni Discussion] shar88:
Anyone else have their data stop working after long periods without reboots? About once a week my data goes out and I just reboot to get it back(I never tried toggling the data in settings). I wonder if this is also a symptom, albeit far less common, or just some other random thing.

I have a d710 with the music bug fix, works great :good:
[General Omni Discussion] Acid0057:
I'm on a GT-i9100M with cm11 m11 and the music bug fix. I'll randomly completely loose signal but a reboot fixes it too. Has happened twice in two months of 24/7 use on my phone.

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] dimoochka:
sup dude. just wanted to let you know that this worked for me as well. I'm on a galaxy s2 SGH-S959G running cyanidemod (http://xdaforums.com/galaxy-s2-att/development/rom-t2900424) - which I think is a modified CM11 i9100 ROM / kernel. Thanks for your hard work :D
[General Omni Discussion] rogersb11:
Just catching up on this. I assume you mean merging Sammy KK source into the smdk4412 aosp kernel? Just loads of work for old device. Which portions of the kernel are most likely to be helpful? I would be willing to merge my s2 source with my hybrid n2 source if it's not the entire kernel since my n2 aosp source is merged with Sammy as of last month. Dual boot kernel there so same zImage boots both Sammy and aosp of initramfs is just modified of course as you clearly know LOL. I'd like to help. I've never had this on my s2 kernel and USB speeds are actually really fast but I love my i777 and have no intention of giving up on it yet. Still building for it when I haven't used it as phone for almost 2 years. Just prefer not having to do a full full merge at this 4 year old junction if possible
[General Omni Discussion] Royaless:
The fix not working for me.

I just installed the latest OMNI ROM and after I flash "cm-11-M10-i9100-music-bug-fix.zip" the phone just get stuck at the "Samsung Galaxy S II GT-I9100" screen.

Someone had this problem? I'm really need to the phone for music.
[General Omni Discussion] mkalic:
Just use a custom 4.3 rom, 4.4 is noth worth it for all the bugs it has on the n7000. I need the phone as gps navigation and music player for my car, and with 4.4 it makes it basically useless for both, because of random reboots and the music bug.