yashsingh1/xdaforums huggingface dataset:
[Galaxy S 5 Original Android Development] ZaneZam:
well not known per se but expected because the higher the toolchain the more the code has to be "clean". and if u add more or even max optimizations then its even more important that the code "is done"

for a particuar toolchain. anyway my problem on the OP5 with 4.4 kernel sources is a gcc v6+ one i can't use higher than v5. or scaling stops working (literally stops), but which part of that rather complex

thingy? nice freetime-eating stuff ;)

yah "holy benchmark tools tell us the truth about our phone!" :) should we asked lord what he thinks about them? :D no no i stop here and now with the OT, don't wanna lose "my bonus" here *g*

but if we seriously would ask the lord then we might get the answer "stability test app" which "we" (i have to add me) use to use to stress the system. even tho i even was able to find a strange bug on the OP2

back then ONLY with atunuuuuttu so it even was useful for me one time ;) ehm yah i wanted to stop.... sry andi *g*
[Galaxy S 5 Original Android Development] Kennedy.Barreto:
I know I should have asked this before, but is it compatible with g900m?
[Galaxy S 5 Original Android Development] fipsy:
Hi Andi! I hope you don't have a crisis when you see me writing something here again. :D I have a problem with beta8: NFC cannot be activated anymore. It always stays off. But with beta7 (same LOS version) NFC can be switched on without any problems. I've tried it back and forth several times between the different kernel versions. Always the same effect. Can you confirm this?
[Galaxy S 5 Original Android Development] andip71:
I do not think so. But I have no idea as I do not own this phone.

Yes, can confirm this.

It seems the defconfig change LineageOS team did was not properly applied to my kernel. Will look into that.

Edit: Found it, will release beta9 today with NFC fixed.

Andi
[Galaxy S 5 Original Android Development] andip71:
Hi all,

quick update to fix the NFC issue for you:

Version 4.1-beta9

06.09.2017

Fix: NFC is now working again

Enjoy

Andi
[Galaxy S 5 Original Android Development] Dayhood:
[MENTION=659208]LordBu[/MENTION]effla

Thanks for this good work

Gesendet von meinem SM-G900F mit Tapatalk
[Galaxy S 5 Original Android Development] Kennedy.Barreto:
worked for the g900m variant
[Galaxy S 5 Original Android Development] fipsy:
Great, great! Thank you very much! At the moment I'm using LOS kernel which I don't like that much. It lags and even produces spontaneous reboots. Your kernel is much faster in overall performance - don't ask me why. But it is definitley.

I will link your message to the LOS thread because there have been other users complaining about NFC issues...
[Galaxy S 5 Original Android Development] kelsony:
Hello, does this kernel work for klteduos with custom rom nougat? I'm sorry if I'm posting in the wrong place.
[Galaxy S 5 Original Android Development] andip71:
No, it does not. Duos are different hardware than g900f.

Andi
[Galaxy S 5 Original Android Development] finotti:
With the latest LOS ROM (20170906) and kernel (4.1-beta9), UMS mode is not working. Unfortunately I hadn't updated it in a long time, so I am not sure when it first broke.

I understand that the kernel is maintenance only, so I understand if the developer prefers not to waste time in trying to fix it. I thought I should report it just in case...

EDIT: I thought maybe I should give mode info: using Linux, when I used to enter UMS mode, I would get a notification to mount the external storage as external drive. Now it appears as a CD-ROM and fails to mount. I can give more details if needed.
[Galaxy S 5 Original Android Development] fbs:
it is strange that I have to use "-mfloat-abi=soft" instead of "hard" or "softfp" for it to work

this means all the floating point operations would be emulated via software instead of using the chipset's FPU set?!
[Galaxy S 5 Original Android Development] andip71:
I can answer that straight away after looking into it for 10 minutes.

The LineageOS kernel rebase done on 31.07.2017 broke it in the official kernel sources. It was working before on stock LineageOS too, now it is broken there.

So it is an official LineageOS kernel problem with the usb/gadget driver support.

I see if bringing back the previous driver before the big rebase was done helps.

EDIT: It helps... will put that in my next kernel update expected tomorrow.

Just fyi - with beta6 of my kernel, which did not have this rebase in, all is still working fine (just in case you need it urgently now).

Andi
[Galaxy S 5 Original Android Development] fipsy:
Somehow it seems to me that the Lineage team has pretty much lost track of the project. Especially at the end of July. Since then, there have been a number of significant errors in LOS.
[Galaxy S 5 Original Android Development] KazuDante:
i think it might be because the focus has shifted over 8.0
[Galaxy S 5 Original Android Development] finotti:
Thanks, again, for the outstanding support!
[Galaxy S 5 Original Android Development] fipsy:
You may be right, but we all want ONE stable, working system, rather than two that have mistakes! And if there is no boeffla kernel anymore, I will gladly do without Oreo. Especially since Android P is already before the release. Will it be Pancake?
[Galaxy S 5 Original Android Development] KazuDante:
true.
[Galaxy S 5 Original Android Development] andip71:
Hi all,

update is out again.

Version 4.1-beta10

13.09.2017

Update: Updated with latest official LineageOS kernel commits as of 13.09.17, 15.00 CET

Fix: UMS mode should be working now after reverting some official LineageOS changes which broke it

Enjoy

Andi
[Galaxy S 5 Original Android Development] kemdroid:
Thanks Andy! Is your kernel compatible with Cr droid?
[Galaxy S 5 Original Android Development] andip71:
Maybe yes, maybe not.

I am not following other custom roms, I am not trying them.

My kernel is compatible with LineageOS, everything else is something you need to find out yourself. Or someone else can jump in and comment...

Andi
[Galaxy S 5 Original Android Development] kemdroid:
Thanks much! Noted.
[Galaxy S 5 Original Android Development] vd69:
Yes it is

Νους
[Galaxy S 5 Original Android Development] Dayhood:
GoodMorning, the New kernel work. Thanks Andi.

Gesendet von meinem SM-G900F mit Tapatalk
[Galaxy S 5 Original Android Development] andip71:
Ok folks, time has come: I am starting to a small 10-days holiday break now. Visiting Oktoberfest in Munich and roaming around with my friends from Florida in the Berlin area.

This means: No update on kernels an app in the next days. Whatever happens in the world, I am away from home and could not do anything.

Please also note, support from myself will be reduced to a bare minimum per nature. I try to read from time to time in the forums, but I will not have the chance for any detailed answers.

CU all again Monday the week after next.

Have a great time

Andi
[Galaxy S 5 Original Android Development] fipsy:
Hi Andi! I wish you a nice holiday and good recreation!

After your return there is already something to do: In beta10 an error has crept in, which leads to the fact that erroneously "am_low_memory" conditions are constantly recognized, although the memory is not low at all. This causes a series of tasks to be terminated. Also look here: https://xdaforums.com/showpost.php?p=73801959&postcount=8172
[Galaxy S 5 Original Android Development] Dayhood:
Ja schönen Urlaub

SM-G900F@RR-OS
[Galaxy S 5 Original Android Development] ttocs99:
Enjoy ya trip fella bring us a pint back haha
[Galaxy S 5 Original Android Development] fbs:
ERROR: modpost: Found 12 section mismatch(es).

To see full details build your kernel with:

'make CONFIG_DEBUG_SECTION_MISMATCH=y'

To build the kernel despite the mismatches, build with:

'make CONFIG_NO_ERROR_ON_MISMATCH=y'

(NOTE: This is not recommended)

should I really ignore it ?

it seems to be refering to warnings like this:

CC lib/parser.o

Warning (reg_format): "reg" property in /soc/i2c@f9967000/isa1200@48 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)

Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/i2c@f9967000/isa1200@48

Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/i2c@f9967000/isa1200@48

Warning (reg_format): "reg" property in /soc/i2c@f9967000/isa1200@48 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)

Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/i2c@f9967000/isa1200@48

Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/i2c@f9967000/isa1200@48
[Galaxy S 5 Original Android Development] andip71:
I assume it is not "a new error" creeped in, I assume it is more my latest kernel being too old.

As I was on vacations, I did not update it of course last week, and there were a couple of kernel code changes done by LinageOS.

I would expect this to be fixed once I merge the latest changes in. Not before Wednesday...

No, you should not ignore this. Such a build would most probably not even boot.

Andi
[Galaxy S 5 Original Android Development] fipsy:
The error occurred immediately after updating to the "new" beta10 on September 14th with Lineage 2017-09-13. I've been using beta9 since September 15th now and the issue doesn't occur on either Lineage 2017-09-13 or 2017-09-20. So the very old kernels don't have this issue, but beta10 has.
[Galaxy S 5 Original Android Development] andip71:
Maybe... still has something to do with kernel repos not in sync, as there were no other changes between 9 and 10 that would explain that.

We will see on Wednesday I guess.

BTW - I am not receiving any am_low... message in logcat here on beta10 with nightly of 13th Sept.

How often and in which frequency should that come?

Andi
[Galaxy S 5 Original Android Development] fbs:
But it boots and everything works, but laggy as hell..

Can you tell me where I git clone the latest los 14.1 kernel? I would love to do a "diff".. Im oldskool lol
[Galaxy S 5 Original Android Development] andip71:
https://github.com/LineageOS/android_kernel_samsung_msm8974
[Galaxy S 5 Original Android Development] andip71:
I merged all latest official LineageOS changes into a test build before I release the official version in 2 days.

If you want, you can try the attached test version and report back if your issue is still there (md5 is 04a86edc200fea4d2a3381e935b0af54).

I could not see one single entry in the Logcat so far on my side, not with beta10 even. Mysterious.

Andi
[Galaxy S 5 Original Android Development] fipsy:
I perform many backup tasks at night between 3 and 6 am, scheduled when the display is off (Titanium, Nandoid, SMS, etc.). All these tasks were always terminated after a short time with am_low_memory. During the day, I then reproduced the whole thing again by means of an extensive synchronization with FolderSync App. It was repeatedly reproducible and did not occur immediately after I reinstalled beta9.

---------- Post added at 05:20 PM ---------- Previous post was at 05:16 PM ----------

Thank you very much for your effort! I will install this version, make some testing and let it run for the next night. I'll report back tomorrow and see if everything's okay.
[Galaxy S 5 Original Android Development] andip71:
Dont know. I just had two foldersync jobs running fine during screen off.

Plus I do not see this log entry.

I can only revert the ums mode changes as well I did between beta9 and 10.

This makes zero sense, but who knows...

Test2 kernel with these changes reverted is attached.

If that does not help, I cannot do anything further. Then one of the official Los changes between beta9 and beta10 broke it for you. But this is in Los kernel too then.

Too bad I cannot replicate that at all, so I cannot dig into something. But maybe you are a special case why this issue exists at all.

Andi
[Galaxy S 5 Original Android Development] fipsy:
Yes, you can! :D

NO MORE am_low_memory with test2! FolderSync runs perfect with display off. :highfive: The last change did it!

I did the tests under exactly the same conditions: flashed the kernel with TWRP, restarted the system, started a synchronization with FolderSync, switched off the display and waited 5 minutes. There are no problems with beta9 and beta10-test2. Not one single am_low_memory in logcat. (By the way: I suspect there have been others who had this problem, because I received 4 or 5 "Thanks" for my contributions to this issue. However, it's a pity that UMS now doesn't work anymore.)
[Galaxy S 5 Original Android Development] andip71:
Well, interesting... Weird.

And there might be still some chance to have ums working in future also. I will try to do some analysis tomorrow.

Stay tuned for maybe one more test kernel.

Andi
[Galaxy S 5 Original Android Development] andip71:
Ok, I now reverted back the UMS changes as big block and only put selected code changes in which were required to make UMS mode working again.

If you could give the attached test3 kernel a try, it would be great to get feedback on it (MD5 is 5e291a28b8decbe98bafdbd8f409bb4d).

When it works, this will be in the next official beta. If it does not work, UMS mode will finally be history sadly.

Thanks

Andi
[Galaxy S 5 Original Android Development] fipsy:
Will try it this afternoon and give feedback then.
[Galaxy S 5 Original Android Development] andip71:
Thanks, this is great. As I then can decide what to do tomorrow when the planned release takes place.

Andi
[Galaxy S 5 Original Android Development] fipsy:
Please be patient for a while. I need to do some more extensive tests that take time. Basically, the am_low_memory error does not occur in test3. But I noticed something else: My previous tests were done with fully synchronized folders, so that no large amounts of data were transferred, but only the files in 7 folders were checked. This worked perfectly for test2 and test3. But now I have also synchronized data with test3. For example, 5 GB of data from a Nandroid backup to my FTP server. This is no longer possible with test3. After just about 10 MB, a crash occurs. With beta9, however, 5 GB can be transferred without any problems. I've reproduced it twice now. Now I want to try it again with the beta10-test2 version. I haven't done that yet. Unfortunately, however, it appears that the problems have only been partially solved, but not completely. I'll get back to you later.
[Galaxy S 5 Original Android Development] andip71:
It could also be, this is now caused by new kernel commits that are in my kernel but not yet in the rom.

Only tomorrows LineageOS nightly will reflect the same kernel commits than my test kernels already have.

Anyways, waiting for your feedback. And my decision is already clear - I will take test3 as tomorrows kernel.

Andi
[Galaxy S 5 Original Android Development] fipsy:
A curious situation: If the bug occurs with test2, these are "good news" because they support your thesis. And that's how it is: The problem also occurs with test2! So I will install LOS 2017-09-27 tomorrow and try it with beta10-test3 and see if the 5 GB synchronization will work. If this is the case, I will use the beta11 kernel, otherwise I will probably have to stay with beta9.

By the way, UMS works very well with test3. I had never tried this before, always only used MTP. While test2 displays the SD card as a "SAMSUNG File-Stor Gadget USB Device" and integrates it as an empty CD-ROM drive, test3 integrates the "SAMSUNG File-Stor Gadget USB Device" as a full-fledged drive (mass storage device).

Another additional question: Did you already integrate the new kernel commits in test1? Because with test1, the problem also occurs when copying.
[Galaxy S 5 Original Android Development] andip71:
Well, then it even might be some new bug introduced by LineageOS team.

Then I would ask you to run LinageOS with stock kernel on todays nightly for a while. I am pretty sure this will be the case there too, when it occurs with my kernel. I did zero to memory handling myself in the kernel.

Andi
[Galaxy S 5 Original Android Development] fipsy:
Thank you for the hints! I just have a medical problem in the family and therefore can't do more tests for a few days.
[Galaxy S 5 Original Android Development] andip71:
That does not sound good.

Take care of your family, this is much more important than any smartphone stuff.

Speedy recovery.

Andi
[Galaxy S 5 Original Android Development] andip71:
Hi all,

maintenance update is out:

Version 4.1-beta11

27.09.2017

Update: Updated with latest official LineageOS kernel commits as of 27.09.17, 08.00 CET

Change: UMS mode code changes reverted and redone in much cleaner way

Enjoy

Andi
[Galaxy S 5 Original Android Development] ariel5zal:
Thanks
[Galaxy S 5 Original Android Development] fbs:
"Lowmemory killer is sitting in the staging tree since 2008 without any serious interest for fixing issues brought up by the MM folks. The main objection is that the implementation is basically broken by design:

- it hooks into slab shrinker API which is not suitable for this purpose. lowmem_count implementation just shows this nicely.

There is no scaling based on the memory pressure and no feedback to the generic shrinker infrastructure.

Moreover lowmem_scan is called way too often for the heavy work it performs.

- it is not reclaim context aware - no NUMA and/or memcg awareness."
[Galaxy S 5 Original Android Development] 10goto10:
Just want to report that memory management is better with beta11 than with the stock 27/09 kernel, without touching any settings (!!) Praise the Lord :)

I mean, having the music player closing on you while you are using another app (not even a browser!) just reminded me of the days when I had an Android device with 256M RAM... :(

Thankfully beta11 improves this! (I hesitate to say 'fixed', as I barely used it for an hour, but things seems to be running as it should.)

I just hope that the Lineage dev's last builds of 14.1 would be in a decent state. The last few months of the CM13 builds has severe regressions, the CM>Lineage transition certainly didn't help. I know that they're doing this work out of passion, for free, so, yeah.
[Galaxy S 5 Original Android Development] fbs:
sorry to tell you but Lord didn't change anything about memory management.. :P

I just think the java framework or the kernel itself has memory leaks.. because each day the phone is slower..

btw I've compiled beta11 with some memory-related modifications (mostly I've disable a lot of stuff). It feels faster here but haven't tested much to say it's stable
[Galaxy S 5 Original Android Development] 10goto10:
I don't think it's from the Java userland... Changes I perceived might be placebo but as long as it works, I'll take it :)

Can you elaborate on what changes you made on your custom build and what's your usage pattern like? Personally I prefer to have zram. I remembered the almost night-and-day difference when Steve merged zram into CM13. Apps today gobble RAM like it grows on trees or something ;)
[Galaxy S 5 Original Android Development] fbs:
what have been good in the past may be the evil today.. lol

what I've noticed is that doesn't matter how much swap or zram you have, the phone will end up consuming every bit of it. I tried to raise zram to 900MB, it used all of it in some minutes. Since this was implemented I think other mechanisms of lowering ram usage where broken, as it won't kill old apps, they will all stuck on your swap/zram forever.. and if you monitor this usage you'll see a *constant* swap-in - swap-out work, that will keep your cpu busy as every time zram is used it tries to compress stuff, and if you have ever used WinRAR, 7zip or WinZIP, you've learned that's not a fast process, even when using a light compression

zcache is another compressing stuff that will try to compress the CONTENT of the files your apps reads and stored them in RAM compressed. So just to access a simple file, it will try to compress and later will have to decompress.. the same observation from above (about how taxing this could be) is still valid

Every time your phone thinks it is low on memory, it will call "lowmemorykiller" like 200 times per second, and that uses a lot of cpu just to do nothing.. and I've seen this happening with ~600mb "free" ram. I don't know how/why it's always trying to shrink ram usage.. I think in the past it wasn't this way. So I just made "lowmemorykiller" a timely function. That means it will only look for apps to kill in a timely manner, not when the kernel aleatory thinks it needs more memory

edit: I have 77 TOTAL apps installed (including system ones). Only 3 games and some "social" apps. No anti-virus, no monitoring apps that will stay active forever. I always check my process list to see if any of them is overeating my ram and cpu.. nothing!
[Galaxy S 5 Original Android Development] andip71:
To cut a long story short:

Invest in a good new phone, that has at least 4 GB ram or more. Then you will never think about zRam, vnswap... whatever, anymore. It just works.

And then put the good old S5 to sleep forever, for good.

Andi
[Galaxy S 5 Original Android Development] fbs:
It would make perfect sense IF we were trying to user newer apps, with more RAM requirements, OR, if we were trying to install a lots of apps instead of a dozen, but that's not the case. And the hardware obviously didn't change. RAM and CPU won't degrade by age and becomes slower and slower..
[Galaxy S 5 Original Android Development] andip71:
More ram always makes sense. Ram is like day and night.

I have the comparison, having all sorts of devices here. The more ram the better.
[Galaxy S 5 Original Android Development] BLUEFOX74:
I need help from an experience developer I am a new developer and I'm still learning in the process several of my devices have been remotely linked to unknown individuals as such my systems are corrupted and everything I think I'm learning and if somehow being tampered with what would you suggest I do
[Galaxy S 5 Original Android Development] andip71:
Wow. A block of text without comma and periods. Maybe even multiple sentences in the block, don't know.

At least I did not understand a lot what you meant...

Andi
[Galaxy S 5 Original Android Development] fipsy:
[MENTION=516058]fbs[/MENTION]: Solved! Your kernel build really solved my problems! I took the system to a very heavy load while performing background backups and synchronizations. Everything went through without any faults, as it always did until September 20th. Although I have the feeling that the device is a little bit slower with this kernel than with the original Boeffla kernel.

Maybe we should try to find the trigger for the memory problems together and then *just* fix this one issue instead of switching off everything that might be problematic? Maybe you could also add some corresponding configuration switches to the config app? What do you think, Andi?

I also liked the feature that the size of the zRAM could be adjusted in the Boeffla Config App in the past. It could also be turned off completely. Is there a reason why this is not available for the current kernel of the S5?

Edit: This build is not a real solution to the problem because many apps now take a tremendous amount of time to launch. Titanium Backup normally takes 3-5 seconds to start, with this special kernel build it takes 30 seconds if it has not been loaded before. The same with HDR photos from Snap Camera. Creating a picture takes one minute. Otherwise about 5 seconds.