yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] Lanchon:
thanks!

i had reports of emmc bugs that shouldn't be there in the 4210 family, and on closer look they were misreported. i've read of people stating they hadn't wiped on unsafe kernels, but then it turned out they had. people swearing they were using such kernel and they weren't. etc..

i've also had reports or read of 4210 emmcs failing for no apparent reason. no erasing or trimming done whatsoever. also pendrives, ssds and any flash memory in general, i've seen them all failing. i've also had a galaxy nexus's emmc lock into read-only mode for no reason, it was running stock. (even-debug booting the processor via USB lead nowhere, had to discard the motherboard.)

these flash devices fail sometimes, and those extremely rare reports of failure you mention in all probability must have had nothing to do with brickbug or trimming, or any reproducible action. just bad modules.

in my view the cost of *not* trimming is too high: these devices become unusable and they have to be retired. trimming brings a second life to them. some early adopters of my kernels were ready to throw them in the trash anyway so they tried a last resort, and ended up very happy with usable devices. i've had 500+ downloads of my october kernels, and of course not a single problem.

yes, im aware of the secure boot in 4210, why otter can be booted, why maguro can be booted, etc. JTAG was supercharged to debug processors and such but it's first and foremost a boundary scan standard. with the exynos halted, you can use JTAG to take over its pins and output whatever you want through them. you could use this (slow) method to talk to the emmc: reset it and write the bootloader.

(of course for damaged devices that still boot to recovery, one could use a software only solution to reset and write in a single dangerous step (unless the emmc requires a power cycle). for all i know nobody tried this. (yes i know, has to work first time or else... :) ))

actually all CM 10.1 releases (10.1.3 and its RCs) are based on the 4412 kernel, the switch happened months before...

https://github.com/CyanogenMod/andr...mmit/55ab60ce5c14f229d303ef97c2c163e59bfcd08f

last release on 4210 is cm-9.1.0-galaxys2. you've forgotten your own work lol!
[General Omni Discussion] rogersb11:
Awesome!! Thanks for the reply. I forked and start the bringing up the my current s2 smdk4412 source and I'll pay extra attention to GPU

Actually, I could be wrong, but that appears to be for 10.1.3 which would still be after straight 10.1. Also I don't use your "trim" method and my kernel hasn't produced these issues. Note I am on the I777 but that shouldn't matter. Rock solid. Only issue is the damn battery dropage on reboot when under 70%. I know there's a fix in the jeboo kernel i believe but I never really dug into it
[General Omni Discussion] nex-54:
Does this fix works on cyanogenmod cm-11-20141115-SNAPSHOT-M12-i9100.zip? Do M12 have this issue?
[General Omni Discussion] Acid0057:
Yes m12 has this problem and yes the fix will work on it.

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] Lanchon:
i don't get what you are trying to say. 10.1.3 runs on 4412 kernel:

https://github.com/CyanogenMod/android_device_samsung_i9100/blob/cm-10.1.3/BoardConfig.mk#L28

there are no releases between 9.1.0 and 10.1.3
[General Omni Discussion] Entropy512:
Nightlies

IIRC, the smdk4412 merge happened near the end of the 10.1 cycle, during the peak of the Focal fiasco
[General Omni Discussion] zeitferne:
Here's the commit: i9100: switch to smdk4412 kernel (authored on 21 May 2013).

According to Github, this is contained in the tags cm-10.1.3-RC2, cm-10.1.3-RC1 and cm-10.1.3.

HTH
[General Omni Discussion] KiraNoas:
Music Bug fixed in AOSP NeatROM v8.0st (4.4.4) [MENTION=4141005]Lanchon[/MENTION] , thanks a lot!
[General Omni Discussion] Lanchon:
lol i posted that a few messages back :)
[General Omni Discussion] zeitferne:
Whoops, sorry! :o I guess I should stick more to the "read before you post" principle. It's even on the same page…
[General Omni Discussion] :
Can i use your fix for galaxy note n7000 KK.

GT-N7000...
[General Omni Discussion] Lanchon:
yes, on all 4210-based devices.
[General Omni Discussion] :
[MENTION=4141005]Lanchon[/MENTION]

Wow that was quick answer. Thanks for your effort.

Edit: Fix works quite OK. I made some rough copy tests no hang and copy speed is more than OK. Problem disappeared well done mate. It was the scariest nightmare of KK for 4210 devices.

GT-N7000...
[General Omni Discussion] JamesMayer:
I have important news about this bug, but cannot post the links here yet - do not have 10 posts posted.
[General Omni Discussion] :
LOL :) XDA is big community just hang out with latest messages you find some interesting threads you can share your opinions or ask things so quickly you will fill your quota then you head up here and share your important news.

GT-N7000...
[General Omni Discussion] JamesMayer:
I hope you can read the links below, I do not have 10 posts posted to post normal links.

[MENTION=4141005]Lanchon[/MENTION] did you try the fix in the mailing list? Namely the one mentioned in spinics.net/lists/arm-kernel/msg368495.html

It says to do:

"

Check arch/arm/vfp/vfphw.S:84 in your kernel tree for

"""

ldr r3, [sp, #S_PSR] @ Neither lazy restore nor FP exceptions

and r3, r3, #MODE_MASK @ are supported in kernel mode

teq r3, #USR_MODE

bne vfp_kmode_exception @ Returns through lr

"""

I went ahead and used:

git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/vfp/vfphw.S?id=refs/tags/v3.18-rc6

to apply those 4 lines and the necessary includes to:

github.com/CyanogenMod/android_kernel_samsung_smdk4412/blob/cm-11.0/arch/arm/vfp/vfphw.S

it compiles but I have no device available for testing. This should be a fix for our longstanding issue.
[General Omni Discussion] Lanchon:
you are quoting my conversation from arm linux.

first, thats a fail-fast method to detect kernel code (including ISRs) that touch the FPU when the FPU is disabled. there seems to be no kernel code that touches the FPU other than VFP support code and context switch, which are tested to death. the problem is elsewhere, it seems not be code but hardware configuration and possibly malfunction.

as i stated in a reply to that post you link:

http://www.spinics.net/lists/arm-kernel/msg368916.html

i found that commit merged into Dorimanx kernel. it has been there for over a year. "fusebug" happens using dorimanx (the usual bug, not a kernel stop) as confirmed by earlier reports on this thread.

the check doesn't trigger because there is no kernel code that touches the FPU, but the bug happens all the same. sorry, you're barking up the wrong tree.
[General Omni Discussion] notabenem:
willing to test

I have a phone, maybe 2. I think I also happen to have a very old nandroid-backup of a stock-android FW (full with old SW). But I any case I have some JB FWs I considered rather stable.

What I can do is install your test app(s) and test on both firmwares (maybe even in parallel). The second phone is rather problematic: BaseBand version often does not show up, no calls can be made. I initially thought it is an eMMC memory wear / corruption.

PS: I do not (yet) have a LInux distro installed to compile kernels.
[General Omni Discussion] :
[MENTION=1901893]notabenem[/MENTION]

Wow rather than a phone firstly we have to decrypt your request its like a puzzle.

GT-N7000...
[General Omni Discussion] Lanchon:
thanks! i moved away from this few months ago because no one would test. dont use that app, with what i know now, i dont expect it to cause an event the way it is now. i had ideas but mostly dont remember now. i may get into this again if i ever get one of those phones. otherwise its too problematic. thanks again!
[General Omni Discussion] notabenem:
[MENTION=4239218]Dekuki[/MENTION]: apparently not one of my brightest moments :)

I had hoped that there would be at least a test-app that would reliably reproduce the problem. Since Lanchon was willing to look into this, but did not have a phone, I merely offered to test on two different phones and different firmwares (stock android JB & KitKat OmniRom). The objective was to confirm or reject Entropy512's hypothesis that pre-JB kernels were also affected.

With the information on hand that Lanchon figured (it's an FP corruption), I have also come across the following thread: https://bugzilla.mozilla.org/show_bug.cgi?id=755568

Apparently the guys developing FirefoxOS encountered this problem 2 years ago AND properly identified it as an VFP corruption, but they did not manage to find the root cause of it either (just got it confirmed today by Juan Gomez - author of Comment #32 in the linked bug). Their solution was to apply the workaround - softfp. Based on the date, I guess they had a kernel that was normally used for Android 4.0 or 4.1 (to be confirmed).

Had we known about their encounter, we could have saved many-many research hours. Too bad none of the teams managed to fix it. For the sake of my own S2, I still hope it's not a lost cause yet, though I am well aware that chances are very slim.
[General Omni Discussion] Lanchon:
this is an awesome discovery! i will read the whole thing when i have the time, thanks!

btw, i think that for the time being, the best bet to have a really stable 4210 device is to build android as if the device didnt have an FPU: kernel must trap and emulate FPU instructions, system must be compiled softtp, and softfp libraries for gcc must be linked.
[General Omni Discussion] Lanchon:
i skimmed over the firefox os bug, and found two pieces of valuable information.

1) so far we don't know whether the bug has been present all along in all kernels, and old androids were simple enough so that it mostly didnt manifest, or whether the bug was introduced by the removal of certain vital quirk fix from the kernel at some point, probably when the 4210 kernel was abandoned in favor of the 4412 integrated kernel.

and the reason we don't know is: a) we don't have a test app to reproduce the problem in all platforms, and b) we can't run kitkat on the 4210 kernel. and so we remain in the dark. but check this out:

https://bugzilla.mozilla.org/show_bug.cgi?id=755568#c34

> I'm trying to compile Gecko with another toolchain and see what happens but

> in the meantime it would be interesting to see the dump of a TimerThread.o

> compiled with the old toolchain in the old build system (the one used in

> GINGERBREAD), cause in GB this problem didn't exists.

>​

Interestingly, I put the same fennec on SGS2 gingerbread firmware, and the problem didn't show up. The same binary built with the same toolchain, and on stock ICS fw we have incorrect double arithmetics, but not on stock gingerbread fw! It doesn't look like the problem is in the toolchain.
​

i can't be completely sure of what they mean by stock GB and stock ICS in this context, but since fennec is just firefox for android, it looks like the bug is present even on sammy's ICS but not GB. yes, the bug being on stock ICS looks bad. Entropy can tell us, maybe that means that the 4210 kernel is probably also affected!

2) on the other hand, this bug is clearly linked to some power save mode. my test app will never detect it unless we add something that stalls the processor in the middle of the load fp/check fp cycle and turn the display off. in the real sdcard.c, it's waiting for the eMMC results. but a simple short sleep might be enough for my app. in any case, i've suspected for a long time that the problem will just go away if a certain power save mechanism is disabled in the kernel, but which? (i've asked for info on the mechanisms on the arm linux list if anyone is curious.) now we have a place to start, check this comment:

https://bugzilla.mozilla.org/show_bug.cgi?id=755568#c8

maybe someone with a device wants to continue from here...
[General Omni Discussion] notabenem:
To complete the facts, here's the confirmation related to the kernels from Gomez:

One more thing: the Firefox devs did not manage to create a reliable test case either, unfortunately.
[General Omni Discussion] Lanchon:
i suppose it wouldnt be difficult: make my test add sleep between fp load/check, you can read (uncached) data from the eMMC but a sleep would probably be enough, tune the number of simultaneous processes, turn off the display while testing, and voilà.
[General Omni Discussion] notabenem:
EDIT: disregard this, Lanchon's suggestion is probably going to be sufficient.

A couple of ideas for the test:

Create 2 services:

1. the first just stores values in FPU registry, sleeps and then continues (and maybe calls pread64?? but this must not be needed, i guess)

2. the second will force the phone into sleep, and, at the same time register an alarm to be woken up (this requires root). Not sure if the 'PowerManagement.goToSleep()' method is still available / accessible. Maybe only via reflection.

http://stackoverflow.com/questions/3417308/force-an-android-phone-to-sleep-in-order-to-test

---------- Post added at 10:02 PM ---------- Previous post was at 09:45 PM ----------

based on the info in comment #8 of the firefox board, I am interested to see, if the problem can be narrowed down to process contexts being moved between CPU. That is, if I disable the second CPU, maybe the issue will vanish. Will report back.
[General Omni Discussion] Entropy512:
I haven't had time to fully digest everything recently posted, BUT based on what I've read/you guys have posted:

It appears that this bug has existed since ICS on the Exynos 4210 devices. e.g. the smdk4210 kernel is likely to be affected too. It just was far less likely to occur/get noticed until KitKat moved internal storage to the fuse daemon - because corruption of those registers as used by the sdcard daemon causes instant catastrophic failure (whole damn thing hangs). Also some people have indicated this might even affect Touchwizz.

Also, it sounds like this may be hotplug related based on https://bugzilla.mozilla.org/show_bug.cgi?id=755568#c8 . So interesting test cases:

Force CPU1 (second core) off and see if the issue goes away.

Force CPU1 (second core) on and see if issue goes away (I think someone might already have done this? Not sure)

That will narrow down whether the issue is related to hotplugging, or threads migrating between cores already online.
[General Omni Discussion] notabenem:
I am having a bit of a trouble to disable the second CPU. Using

echo "0" > /sys/devices/system/cpu/cpu1/online

does not really help, because the governor always re-enables it

Any suggestions how to disable a CPU for good?

Edit: not sure if my test (copy a 6GB file to my SD card) is a good test case: it breaks always at the very same position, and after reconnecting the USB cable to the phone the copy can be repeated. I don't have to restart the phone.

Edit2: OK, my problem was that the Internal storage is FAT32 and thus can only accomodate 4GB files - but the fact that it silently times out after crossing the 5GB boundary for the file, is a bit unexpected. So it seems I can't reproduce the issue at all.
[General Omni Discussion] zeitferne:
I wonder if this IRQ112 is related. I had digged a bit around there once but don't wanted to spam the forum because really I could not confirm that it was related; According to /proc/interrupts it's mct_tick1_irq . It's normally set to run only on CPU1 (that's why the "no longer affine" message is shown in the kernel log) but when this CPU is shut down, it is forced to run on CPU0. If one watches /proc/interrupts it is quite rare that it is actually triggered there (the CPU0 column of the interrupt currently shows 0 on my phone booted about 20 minutes ago, the CPU1 column is not visible, IDK why probably because it is disabled?).

The IRQ is set up in arch/arm/mach-exynos/mct.c ("EXYNOS4 MCT(Multi-Core Timer) support" according to a comment at the top of the file). Might be worth it comparing Gingerbread sources. Or maybe only the CPU disabling/interrupt migrating is handled differently and causes this IRQ-foo to fail.
[General Omni Discussion] Entropy512:
If you're able to compile a kernel, you can modify the hotplug driver to force the CPU into either all-off or all-on states.

I forget the exact file, but https://gerrit.omnirom.org/#/c/4991/ should give you an idea where to start. (The hotplug governor for the 4210s is different, I forget which one it is...)
[General Omni Discussion] toroid:
between kernel 2.6.35 and 3.0.1, changes have been made to handling of IRQs during hotplug :

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/058742.html

Is it possible that this revealed a irq issue on the exynos?
[General Omni Discussion] zeitferne:
For what I know (which not much :)) that's a trace worth following! It seems (according to some googling) that this multicore timer routines should set the percpu_dev_id of the irqaction instead of the affinity (which it does here. The latter is just a hint that the kernel can ignore (and it does as the kernel log indicates). I will try to fiddle with this if I have time, but wouldn't mind if anyone more knowledgeable preempts me ;)

EDIT: Whoops, it seems that the per-cpu feature is only available since kernel 3.2. So I don't know how to lock the interrupt to a CPU, but from the comments in the code that's clearly what was intended but not achieved with the affinity setting. Maye one could just keep migrate_one_irq from breaking affinities (this seems to be the only interrupt that is affected by it anyway).

EDIT2: I disabled affinity breaking in migrate_one_irq with this diff but it seems not to have changed anything (about the bug or otherwise (apart from the different message)).
[General Omni Discussion] snow:
Maybe this can be useful (for irq.c): http://pastebin.com/nxXZRvP0 Compilation works in Dorimanx kernel without errors, didn't tested on S2. :)
[General Omni Discussion] zeitferne:
Bug disappears with CONFIG_HOTPLUG_CPU and PM_SLEEP_SMP disabled

I found another way to make the bug disappear: :victory: First I checked using make cyanogenmod_i9100_defconfig && make menuconfig that the disabling of CONFIG_HOTPLUG_CPU is not possible with menuconfig (and thus manually editing the config file would also have no effect) because it is selected by PM_SLEEP_SMP which, again, cannot be changed because it is hardcoded in kernel/power/Kconfig. So I simply changed it there and then was able to disable CONFIG_HOTPLUG_CPU with menuconfig. Trying to compile the kernel then failed because the pegasusq scheduler referenced a now disabled function, so I disabled CONFIG_CPU_FREQ_GOV_PEGASUSQ too (this time quick & dirty by manually editing cyanogenmod_i9100_defconfig). In the finally resulting configuration file make menuconfig has changed some other variables too, and there is much noise from reordering in the diff. However, my rsync test (copying 6GB of music from internal exFAT to external FAT32 sdcard) now runs through flawlessly with an upatched sdcard daemon!

The adverse effect is of course that now both CPUs are always enabled (meaning that the above basically implements what Entropy512 suggested) and, as the CPU-Z app indicates, always running both at the same frequency (as the other; the common frequency still varies between 200 and 1200MHz) which will lead to a higher power consumption.

A low hanging fruit would now be to check if just disabling PM_SLEEP_SMP and letting CONFIG_HOTPLUG_CPU enabled still gets rid of the bug (if the kernel compiles in that configuration at all), but I don't have more time for this now.

EDIT: Well I noticed a rather critical problem with this kernel configuration: When the sreen is off for a longer time without the phone doing anything (e.g. rsync via adb) , one cannot wake it up anymore. It's not completely off, however, as I had to press the "power" button for a longer time to force a reboot.
[General Omni Discussion] patrickph:
You can simple disable sec CPU on dorimanx profile with up_load=101, down_load=101.
[General Omni Discussion] Entropy512:
wtf? pegasusq shouldn't be enabled on i9100...

I'll try to take a quick look this weekend at a better way to disable hotplug than this.

Try disabling CONFIG_STAND_ALONE_POLICY - that'll disable the hotplug governor.
[General Omni Discussion] zeitferne:
It's not actualy enabled (aka default) but compiled in.
[General Omni Discussion] Entropy512:
Well that's what I meant - it shouldn't even be compiled in on 4210 devices...

You can tell how little attention that the original maintainers have been paying to the 4210s, which is why they're getting dropped with 5.0 - none of the original maintainers have the time to properly keep it going any more
[General Omni Discussion] Lanchon:
why is that?

---------- Post added at 12:15 AM ---------- Previous post was at 12:14 AM ----------

it seems i'll be getting a loaner i9100 around new year's... far too late for this party :(
[General Omni Discussion] Acid0057:
Never to late lanchon. The problem isn't entirely solved. Plus kitkat will still be around for a bit

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] zeitferne:
Disabling CONFIG_LOCAL_TIMERS gets rid of the bug!

Disabling CONFIG_EXYNOS_PM_HOTPLUG also fixes the bug by keeping CPU1 always on, but with the phone being able to wake up properly (I also disabled CONFIG_STAND_ALONE_POLICY as Entropy512 suggested but I think the CONFIG_EXYNOS_PM_HOTPLUG was the crucial part).

But far more interesting is what I found out next:

I restored the defconfig to the original version and tried disabling CONFIG_LOCAL_TIMERS because that gets rid of this IRQ112 that keeps showing up in the kernel log and guess what! Bug gone! When CPU1 is switched on, I now get the following in kmsg:

<4>[ 629.607479] c1 CPU1: Booted secondary processor
<4>[ 629.607503] c1 CPU1: Booted secondary processor
<6>[ 629.607571] c1 notifier_call_chain : NOTIFY BAD tick_notify
<6>[ 629.611238] c1 Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
<4>[ 629.611295] c1 Could not switch to high resolution mode on CPU 1
<6>[ 629.616308] c0 cpu1 on

The messages about not being able to enable the timers are new, the "IRQ112 no longer affine" messages are gone.

Googling around a bit indicates that the CONFIG_LOCAL_TIMER option and related code has been removed from newer kernels, because there is a API with equivalent/better functionality: [PATCHv3 00/10] Remove ARM local timer API

I will test my phone with this configuration for a while to see if I can spot any adverse effects.
[General Omni Discussion] notabenem:
assuming because it was meant for 4412? Interesting, because I am running it for months (on my i9100). Actually, for more than a year. What would be the adverse effects of it?

But if pegasusq is not recommended, probably NeoX is not suitable either (based on pegasusq). That would leave "hyper" as the next best, i guess?
[General Omni Discussion] Entropy512:
Yeah it was written specifically for 4412. In fact, turning it on while standalong hotplug is enabled is likely to do some WEIRD stuff as you have two different things trying to diddle with hotplugging at the same time.

As to the CONFIG_LOCAL_TIMERS - some of those messages imply that the negative effect might be reduced timer resolution, which could negatively impact governors that rely on accurate accounting of idle time (pretty much any governor with a sensible polling rate...)

Either way, it gets someone MUCH closer to root cause and a solution here! :)

Edit: My memory sort of recalls at one point having some annoying problem with the MCT in the past - but it was 2+ years ago and I forget the details.

ALSO:

https://github.com/omnirom/android_...b/android-4.4/arch/arm/mach-exynos/mct.c#L476 - MCT uses a different interrupt type on 4210 and 5250 than on 4x12.