Linux Kernel Testing Results by Linaro - Jan 23rd 2019 Edition - General Topics

One of the things that we do at Linaro is testing Linux Kernels to look for kernel regressions. Ideally we want a world where those that make use of Long Term Support Kernels (LTS) are able to depend on and trust the stream of fixes that are being provided such that they end up on devices.
Mobile phone companies, Linux Distros, embedded Linux deployments, etc all generally like the idea of installing one major version of Linux (e.g. 4.9) and sticking with it for the lifetime of their product.
This, and following stories tell how week to week testing of Linux kernels is going, what we’ve found, or better, not found as the kernel versions tick by.
We test using two host user spaces, open embedded and Android.
Open Embedded
2019–01–21
4.9.152, 4.14.95, 4.20.4
Reported crashes in v4.20.3–15-g5592f5bf010b which were intentional ‘canaries’ (the canary successfully died)
Reported no regressions in <24h
4.19.17
Reported no regressions in <48h
Bug Status — 57 open bugs
2019–01–22: Anders Roxell sent allmodconfig patches 1 2
2019–01–18: Naresh Kamboju reported kselftest bpf test_netcnt failure re: bug 4245
2019–01–16: Daniel Díaz sent 4 kselftest patches upstream that are being carried in OE
Android
Android 9 / P — 4.4, 4.9, 4.14, 4.19 on HiKey
4.14.94 — no regressions
4.19.16 — Note USB OTG regression and potential eMMC issue documented in the bugs section
4.4.170 — no regressions
4.9.150 — no regressions
Android 8.1–4.4 on HiKey, Android 8.1, 4.14 on X15
4.14.94 / X15 no regressions
4.4.170 / HiKey no regressions
Android 9/P + automerged latest version of LTS 4.4, 4.9, 4.14, 4.19 + HiKey + Latest LTP
This new combination is a work in progress to pull in latest LTP from AOSP-master, as well as using the combination of Android Common + HiKey Linaro (auto merged). It triggers automatically when Android Common is updated right after a new LTS release is merged. This combo thus gives everyone great visibility to test results nearly immediately after an new LTS is available.
We have initial data but are not sharing them as part of this report yet.
AOSP-master tracking with 4.4, 4.9, 4.14, 4.19 on HiKey
These builds are being reworked / repackaged so we’ll have data to report next week.
Bugs
18 — +2 WtW
New: 4258 OTG with 4.19.17 (and prior) not flipping modes to allow USB keyboards etc
New: 4259 4.19.17 eMMC issue?

Related

Stagefright security fix, without sources

Hi all,
Today I'm pleased to announce a fix for stagefright's security flaws, which doesn't require to disable stagefright, and doesn't require stagefright sources either.
The sources, including a detailed README is available at:
https://github.com/archos-sa/security-binary/tree/master/stagefright-ANDROID-20139950
The purpose of this contribution is to propose a systematic approach able to quickly to re-generate firmwares that addresses the 2015 libstagefright CVEs by relying on binary patching method.
This method is relevant when dealing with platforms for which the source code has not been released publicly.
This proposed process is illustrated with 2015 libstagefright CVEs but can be further extended to capture other upcoming security fixes.
Surprisingly these fixes do not pass the Zimperium vulnerability test apk because this apk directly checks libstagefright.so without going through Mediaserver.
Obviously this is not intended for Cyanogenmod type of ROMd that most likely already implement proper fixes in their source code.
Included in the git tree are some prebuilts files, targetting AOSP 4.2, 4.4, and MTK baseline 4.2 and 4.4.
This has been tested on Nexus 4 4.4 (aosp4.4 prebuilt), a spreadtrum 4.4 device (aosp 4.4 prebuilt), several mtk 4.2 and 4.4 devices (mtk4.2 and mtk4.4 prebuilts). I believe it should work as-is on Qualcomm-baseline 4.4 as well (aosp4.4 prebuilt).

3.4.110 [F2FS] 1jz-kernel

This is a build of Ziyan and friend's 3.4 kernel(against their will), optimized for release. Absolutely no debugging features allowed.
Ipv6 and complex adb functions broken.
Graphical Stuttering fixed.
Ubertc4.9.4 (Until I setup 6.0)
Latest F2FS sources. This F2FS is newer than everyone elses. Kanged from KHAON.
Brought up from 3.4.67 to 3.4.110.
Selinux disabled.
Optimized to all hell. Ofast probably regressed performance below that of O2 but Ofast makes people smile so whatever. It's smooth is all I have to say.
Works with any rom.
Mod Edit
Rolling release kernel, no versions. To report bugs tell me the hash, date, or build # of the kernel you have issues with.
Want a feature? Tell me to include it. I'm too lazy to do it? Fork my source and build it then post a link to your sources and I'll include it in the OP if it's good. This project is driven by and for the community.
Sources: Mod Edit
Brought to you by Ziyan, htcdreamon, sheffzor, khaon, eliminater74, coderzs, and me lgrootnoob. Linus Torvalds is a dong, yo.
Thread closed.
Please respect the code originator's polite request in future.

[KERNEL-SOURCE][STABLE] Stable Kernel Source For LYF Wind 3 (LS-5502) :)

INTRODUCTION:​
The kernel is a computer program at the core of a computer's operating system with complete control over everything in the system. It is an integral part of any operating system. It is the "portion of the operating system code that is always resident in memory". It facilitates interactions between hardware and software components. On most systems, it is one of the first programs loaded on startup (after the bootloader). It handles the rest of startup as well as input/output requests from software, translating them into data-processing instructions for the central processing unit. It handles memory and peripherals like keyboards, monitors, printers, and speakers. In Android It is very important.​
STORY:​
As 'LYF' OEM has not released kernel source for the phone and never will. After many repeated tries to contact the OEM to release the Kernel Source, it seems they did not respond at all. After many refusals from the OEM, we decided to make the kernel source on our own.
And Here we are with the kernel.
Total Credits goes to shahnawaz_sheikh :angel:
What Works?​
boot
mtp/usb
RIL
Notification LED - Fixed On 7th July
Flashlight - Fixed On 17th July
Sensors
Touchscreen - Fixed On 4th June by shahnawaz_sheikh
Display
Audio
Camera - Can't Fix Due to Unique Lens Used
And Everything! :laugh:
Nutshell: This is a stable Kernel source for the phone and everything works!.
CREDITS:​
First Of All to everyone
Many Many Thanks To @shahnawaz_sheikh :angel:
My Brother @YashrajYadav | Yassuz
My Guidance @TipzTeam
My Mentor Mohd Faraz | androiabledroid
Me OfCourse
And EveryOne
NOTE:​
This is the pure work of Me(@The_God_Speed) and the people mentioned above. If you may somehow uses this Please give them proper credits. ​
LINK:​
Check Github :good:
Many Updates Coming. Make sure to follow on XDA and Telegram. ​
Support Group:​ Telegram
Version Info:​ Stable
Architecture:​ Both [arm + arm64]
Have Fun!!!
And
Once
Again
THANKS!
Reserved!
Nice!
Updated!
Just updated the kernel source of brach cm-14.1 ?
INFO:​
Arm64​1. lineage-17.1 kernel = can boot roms from lollipop to all the way up to Android 10
Arm​1. lineage17.1 kernel = can boot roms from Oreo to Android 10
2. cm-14.1 kernel = can boot roms from lollipop to nougat.
All the things mentioned above are well tested by me ??

[GCC][Toolchain] Eva GCC | Calling all kernel devs!

Introducing Eva GCC Toolchain
What is GCC?​
The GNU Compiler Collection (GCC) is an optimizing compiler produced by the GNU Project supporting various programming languages, hardware architectures and operating systems. The Free Software Foundation (FSF) distributes GCC as free software under the GNU General Public License (GNU GPL). Major corporate contributors to GCC include Red Hat, IBM, SUSE, ARM, Google and Intel. GCC is a key component of the GNU toolchain and the standard compiler for most projects related to GNU and the Linux kernel. With ~15 million lines of code in 2019, GCC is one of the biggest open source programs in existence. It has played an important role in the growth of free software, as both a tool and an example.
Source: Wikipedia
Click to expand...
Click to collapse
What is LLVM Clang?​
Clang is a compiler front end for the C, C++, Objective-C and Objective-C++ programming languages, as well as the OpenMP, OpenCL, RenderScript, CUDA and HIP frameworks. It uses the LLVM compiler infrastructure as its back end and has been part of the LLVM release cycle since LLVM 2.6.
It is designed to act as a drop-in replacement for the GNU Compiler Collection (GCC), supporting most of its compilation flags and unofficial language extensions. Its contributors include Apple, Microsoft, Google, ARM, Sony, Intel and Advanced Micro Devices (AMD). It is open-source software, with source code released under the University of Illinois/NCSA License, a permissive free software licence. Since v9.0.0, it was relicensed to the Apache License 2.0 with LLVM Exceptions.
Source: Wikipedia
Click to expand...
Click to collapse
Introduction​Android as a whole has now fully switched to LLVM Clang for both their Platform (AOSP) and Kernels. In fact Pixel Phones have been shipping with Clang built and optimised kernels since 2018! But are there any improvements with using clang over GCC. I'd say yes, because the GCC that AOSP used was ancient (GCC 4.9). Also LLVM Clang has proven to be faster in compilation than GCC. But is this speed worth the improvement in Kernels? Let's answer that question with EvaGCC Toolchain.
How is my toolchain different from Android GCC?​As I've mentioned earlier, AOSP GCC is ancient (version 4.9) in terms of the present stable GCC release (10.2.x). EvaGCC is compiled straight from the Master branch, making it a Bleeding Edge C Compiler. It is built with LTO and disabled a lot of feature bloat that are unneccesary for kernel building to yield a very small binary size. To list the features:
Bare Metal GCC (This does not depend on the standard libc)​
Built straight from the GNU GCC Master branch​
Built with LTO and O3 optimisations​
Disabled documentation (Smaller size of the toolchain)​
Disabled decimal float, libffi, libmudflap, libquadmath, libstdcxx-pch, native language support​
Statically linked GCC​
Integrated LLVM LLD (For faster linking, optional)​
Built twice weekly (Thanks to Github Actions!)​
Where can I find these toolchains?​Well you have two options, you can compile them yourself (by using my script) or you can download precompiled binaries!
To compile this toolchain by yourself (although I recommend that you use precompiled binaries, to avoid the hassle and time to compile the toolchain itself), to use my script to compile your toolchain, it has everything preconfigured for GCC setup and cloning. Although you'll have to setup your system for building GCC, you can refer to my README for system setup.
Note:
To obtain precompiled binaries (Highly recommended), head over to these links (according to your architechture and liking):
ARM Git Repository with Precompiled Binaries
ARM precompiled binaries in a compressed zip (direct download)
AARCH64 (ARM64) Git Repository with Precompiled Binaries
AARCH64 (ARM64) precompiled binaries in a compressed zip (direct download)
Note: If you're doing a git clone, use --depth=1 to avoid heavy transfers, because the repositories are bound get bigger with subsequent updates.
How do I use these toolchains for compiling my kernel​You can either append the toolchain dir into your PATH variable, or you can just pass it along with make with setting your CROSS_COMPILE argument. I usually use the latter one.
Since this is a bare metal compiler, the prefix differs from the normal AOSP or Linux GNU GCC. the prefix is:
Bash:
# Pass this to your CROSS_COMPILE argument if you have appended toolchain to your PATH
## for AARCH64 or ARM64
$ make CROSS_COMPILE=aarch64-elf- ... # "..." indicates rest of your args
## for ARM
$ make CROSS_COMPILE=arm-eabi- ...
# Passing to make when you haven't appended to PATH
## for AARCH64 or ARM64
$ make CROSS_COMPILE=<path to toolchain>/bin/aarch64-elf- ...
## for ARM
$ make CROSS_COMPILE=path to toolchain>/bin/arm-eabi- ...
Sources:
Everything here is OSS, including the script, my ci automation script.
GCC: https://gcc.gnu.org/git/?p=gcc.git or https://git.linaro.org/toolchain/gcc.git
Binutils: https://sourceware.org/git/binutils-gdb.git
GCC Build script: https://github.com/mvaisakh/gcc-build
LLVM (Used for LLD): https://github.com/llvm/llvm-project
GCC Version: 13.x
Binutils Version: 2.36.x
LLD Version: 16.x
Telegram Channel:
Eva GCC
Bleeding Edge Bare Metal GCC, primarily targeting Android kernels.
t.me
NOTE: According to SultanXDA, and I quote
GCC 10 updated its interprocedural optimizer's logic to have it make
more conservative inlining decisions, resulting in worse syscall and
hackbench performance compared to GCC 9.
Click to expand...
Click to collapse
This can be fixed with a patch that he himself provided:
gcc-inline-regressions-2.patch
GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
and if that did not work for you, try applying this patch
gcc-inline-regressions-2.patch
GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
Update 30-Jan-2021
GCC+LLD has been merged into the main branch of the build script. Now GCC+LLD would be updated twice every week (on Sundays and Thurdays). This wasn't done before as it was under testing, and so far it only fails under LTO kernel compilation (Due to lack of GCC Plugin for LLD and vice versa).
Update 07-April-2021
lld-integration trunk has been merged into gcc-master branch. For those who use LLD, should switch to gcc-master as the lld-integration branch is now deprecated and will be removed soon.
The size difference between the two isn't much (~86mb vs 125mb), so it makes sense to have a single branch for everything.
I recommend to use zipped archive toolchains or if you use git operations to clone toolchain binaries, I recommend using --depth=1 while cloning the toolchain to avoid huge binary size cloning.
Update 27-April-2021
GCC Version has been bumped to 12.x
Eva GCC now ships with
GCC: 12.x
LLD: 13.x
BinUtils: 2.36.x
Update 26-June-2021
Toolchain binaries have been stripped off of debugging and hence are much smaller than before, ~90MB shaved off!
Shallow clones shall be much faster than before!
Update 24-Nov-2021
LLD has been bumped to version 14.x
GCC is still on 12.x
Update 1-May-2022
GCC has been bumped to version 13.x
LLD is at 15.x
Pro Vaisakh
Yes yes super pro Vaisakh
Nice
It's kang time
Let me try great work
Oh pro iz here
Going to use it soon
god level pro work
Amazing job at collecting data and optimising the toolchain, looking forward to using this as default in my kernel builds!
Keep up the great work dude
great work sar, tysm!
A small update!
GCC+LLD has been merged into the main branch of the build script. Now GCC+LLD would be updated twice every week (on Sundays and Thurdays). This wasn't done before as it was under testing, and so far it only fails under LTO kernel compilation (Due to lack of GCC Plugin for LLD and vice versa).
If anyone faces any issues with the toolchain, please do let me know. I will try to investigate the issue and check accordingly if it's a toolchain issue or a kernel side issue.
Because being a cron built toolchain, it's necessary for people to report bugs as soon as possible.
I still monitor on my end, but it's always good to have a helping hand
Thanks @m_vaisakh,
Kernel 3.18.140 compiled with https://github.com/mvaisakh/gcc-arm64.git -b gcc-master works fine on Oreo. No errors thru whole process.
adeii said:
Thanks @m_vaisakh,
Kernel 3.18.140 compiled with https://github.com/mvaisakh/gcc-arm64.git -b gcc-master works fine on Oreo. No errors thru whole process.
Click to expand...
Click to collapse
How is the performance?
@nift4 also uses 3.18.140 and has it has improved everything in his case.
m_vaisakh said:
How is the performance?
@nift4 also uses 3.18.140 and has it has improved everything in his case.
Click to expand...
Click to collapse
*3.18.124 sadly
m_vaisakh said:
How is the performance?
Click to expand...
Click to collapse
Lets see what Antutu Benchmaker v8.4.5 said:
Same kernel source, same device, connected via USB, 10 minutes after boot:
With GCC 4.9: score 71192, HTML5 score: 13087
With EVA-GCC: ... 72392, HTML5: 14554 and kernel is smaller for 235520 bytes !
Update!
lld-integration trunk has been merged into gcc-master branch. For those who use LLD, should switch to gcc-master as the lld-integration branch is now deprecated and will be removed soon.
The size difference between the two isn't much (~86mb vs 125mb), so it makes sense to have a single branch for everything.
I recommend to use zipped archive toolchains or if you use git operations to clone toolchain binaries, I recommend using --depth=1 while cloning the toolchain to avoid huge binary size cloning.
Update!
GCC Version has been bumped to 12.x
Eva GCC now ships with
GCC: 12.x
LLD: 13.x
BinUtils: 2.36.x
m_vaisakh said:
Update!
GCC Version has been bumped to 12.x
Eva GCC now ships with
GCC: 12.x
LLD: 13.x
BinUtils: 2.36.x
Click to expand...
Click to collapse
Been using Eva GCC for over 3 months now and it's been very reliable

[Dev] Error after merging newer CAF tag

Hello people! I have an MSM8960 Android device called VEGA S5, it's a normal MSM8960 phone that came with Android 4.1.2 (actually, upgraded to. release with android 4.0.3) and Linux 3.4.0.
I had been trying to merge the newer CAF tag to develop newer android roms. There is a phone with similar spec, and that device runs an unofficial LineageOS 18. The phone is Sony Tsubasa, so on the device side I'm trying to use tsubasa's device trees with some (a lot of) edits and that seems to work quite well.
The manufacturer kernel is in CAF tag M8960AAAAANLYA1741J . I applied the manufacturer changes on top of this tag. (https://github.com/HexagonWin/vs5lineagekerneltemp/commit/4a141d0b8257d244e24aba0aa14afa8756db4ffa)
Oh, and the kernel repo is here : https://github.com/HexagonWin/vs5lineagekerneltemp.git
After it, I merged the CAF tag LNX.LA.2.7-01110-8960.0. This is kitkat.
After I merged it, I was able to fix most of the build errors I get. I couldn't solve some of the camera parts, so I just temporarily disabled the camera stuffs, from the makefile and things.
However, i wasn't able to fix this error here : https://pastebin.com/BFGYUBCx
It says that functions like "msm_rotator_buf_sync" are undeclared on drivers/char/msm_rotator.c and many other files.
I tried grepping on the kernel tree, found out that all of those stuffs are already declared in "include/linux/sync.h"!
And "include/linux/sync.h" header file is also mentioned on .c files like drivers/char/msm_rotator.c .
Why would this error be happening? I don't know C well, but I see that all of those are being declared correctly.
I also tried comparing to similar phone's kernels, like htc-msm8960 and sony-msm8x60, but I see that the parts with error is all similar with those phone's kernel...
Thanks
+++ I also merged CAF tag LA.AF.1.1-01410-8064.0 later, this is android lollipop (5) tag. I first merged it on my test repository, but after I saw that nothing changed with the issue I have currently, I just commited the thing to github.
+++ The similar devices I'm keep seeing things from are
- Sony Xperia V (sony-tsubasa) and other "mint" family sony devices
- HTC Evo 4G LTE (htc-jewel) and other msm8960 based htc devices
- LG Optimus LTE II (lg-d1lsk) this phone has unofficial cm11 ported

Categories

Resources