I was looking at it a Linux v7.2 boot that was taking longer than expected, so I sampled a random spot which turned out to be hit xxh64_update. It was crock full of like this:

lbu t6, a5, 0000000000000000
lbu t5, a5, 0000000000000001
lbu t4, a5, 0000000000000002
lbu t3, a5, 0000000000000003
lbu a2, a5, 0000000000000004
lbu s3, a5, 0000000000000005
lbu s2, a5, 0000000000000006
lbu a1, a5, 0000000000000007
sb t6, s0, 00000000ffffff88
sb t5, s0, 00000000ffffff89
sb t4, s0, 00000000ffffff8a
sb t3, s0, 00000000ffffff8b
sb a2, s0, 00000000ffffff8c
sb s3, s0, 00000000ffffff8d
sb s2, s0, 00000000ffffff8e
sb a1, s0, 00000000ffffff8f
ld a1, s0, 00000000ffffff88

which is like the worst way to do unaligned loads, especially when the platform handles it.

Much digging later, this is a Linux (v7.2) bug. Grossly, you have to turn on "nonportable efficient unaligned" (Why is this "nonportable"? RISC-V requires unaligned support!)
CONFIG_NONPORTABLE=y
CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y
but, here's the bug, it doesn't work, because:

"...

The default tune is rocket. rocket, sifive-3-series, and sifive-5-series all set slow_unaligned_access = true; thead-c906 and size set it false. arch/riscv/Makefile never sets -mtune at all, so under GCC, CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y is largely decorative for by-pieces expansions — it flips the Kconfig selects and passes a flag that the tune model then vetoes. That's a legitimate upstream bug worth reporting to linux-riscv; I'd be surprised if it's intentional."

The workaround:

make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv KCFLAGS="-mtune=generic-ooo"

Now Im using nobara linux with kde but terminal design is so bad how can i change this

I have used many Linux distros in my time from user friendly distributions like Linux Mint to more complicated distributions like Void Linux. I discovered that there was a huge gap in Linux distros between performance and stability. I personally experienced this when i used both Ubuntu and CachyOS recently. So i thought, why not try to get the performance of CachyOS on Ubuntu, so this is what i came up with.

The result is my customized Ubuntu build with my custom kernel called UbunchyOS. I've been using it for a little over 2 weeks now, and in my experience, it works like a charm and is stable on my machine.

Base: Linux 7.1.4

Scheduler: BORE (Burst-Oriented Response Enhancer)

Local version: -ubunchyos-bore-borinquen-edition

Patch: 0001-bore-cachy.patch

Main goal: CachyOS-level or close to CachyOS-level performance on Ubuntu-based distros

NOTE: I have used Ai to guide me and teach me how to make a Linux kernel because this is my first Linux kernel. This is currently a experiment and project for my own use, currently im not sure if I plan on maintaining or developing it further.

I am studying this OS material and got a little bit confused on which APIs are the kernel APIs. Are they the system calls talked about above or other ones specific to the core kernel code mentioned below?

Hello everyone, suppose a process is running with PID 23654, and the OS creates a specific folder for it in the/proc directory. At the moment, how can I change resources such as the network namespace or the cpuset? The final goal I want is to change the network of a running process; suppose I use eth0 and the root namespace; then I create a namespace like ns1 with a specific interface and resource, then move the running process to this namespace to continue the process in an isolated network.

There is a pen input bug on some HP laptops, which has been reported. Of course, this is low priority. However, I would love to try to kindly ask for a fix, since it can't be that hard. (I don't have the time myself to look into this, otherwise I would love to do so.)

Essentially, the pen pointer is lagging, because for some reason the communication between pen and screen is in the lower (35-ish) Hz range instead of 260-ish Hz.

I somehow believe that fixing this should not really be a big deal. (I can be wrong, though.)

The bug has been reported here.

220854 – ELAN2514 04F3:442A stylus laggy with "incomplete report (67/5631)" errors on HP OmniBook X Flip
https://bugzilla.kernel.org/show_bug.cgi?id=220854

Bug #2142384 “ELAN2514:00 (04F3:4428) stylus report rate extreme...” : Bugs : linux package : Ubuntu
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142384

Any idea to whom I could pop a message in order to look into this.

Many thanks.

What is the fastest and most efficient way. Thanks for future answers.

Is there documentation that will tell me what these options are?

Hello! I am writing on a note to ask if anybody has found a suitable linu kernel for this device and/or and official!

I am also writing that i was somehow able to extract the linux kernell building config file directly form the device and i have compiled it using bazel on the android-kernel (linux): https://github.com/Android-ASOP-for-Lenovo-Tab-K11/android_kernel_lenovo_tb330xu

I am trying to get started with Linux kernel/device-driver development, but the Linux Foundation LFD430 (Developing Linux Device Drivers) course is very expensive to buy. so I am thinking of using its course outline as a roadmap and studying the material on my own.

I have a decent programming and Linux background, but I do not have much experience, and I am very new to kernel and driver development.

So I wanted some advice from the experts who work in this area

How would you get started with learning things, and what resources would you follow, etc.?

I would appreciate recommendations for good books, free courses, labs, YouTube channels, documentation, affordable courses, or practical projects that could roughly follow the LFD430 syllabus.

Also, if you think following the LFD430 outline is not a good way to learn from scratch, then I would love to hear what you would recommend instead.

Thanks!

I am using redmi note 8 (ginkgo) running on evolution x android 16 rom. I recently installed kali nethunter with custom kernel for my device, but the problem is that my nethunter app has a bluetooth arsenal option but it is throwing errors during installation. I also tried running hciconfig -a in terminal but I printed nothing so I checked my kernel version and it is '4.14.356-openla-rc1-Ikteach-g98dd6390243b-dirty'. The first solution that came into my mind was flashing kernel manually but I don't know any clear instructions and requirements required to meet.

I’ll continue developing my project with the positive feedback I received from the LKML during the RFC process.🤩

A few days ago I submitted an RFC to LKML for NSD (Neural Storage Driver) — a Linux kernel module that learns I/O access patterns (Markov chain + stride prediction) and prefetches data before it's requested, instead of relying on static heuristics. Benchmarks showed 18-19% wall-time reduction on SQLite scans and +22.6% sequential throughput improvement, validated with interleaved ON/OFF methodology.

The core idea: predict → prefetch → measure → adapt. Learn the workload's behavior, act ahead of the bottleneck, verify against real results, refine the strategy.

I came across OpenAI's writeup on GPT-5.6 Sol optimizing its own production GPU inference kernels (Triton/Gluon) and this stood out:

"Even when individual operations are fast, excess memory movement, synchronization, and inefficient data layouts can leave GPUs idle. To avoid this, GPT‑5.6 Sol found work that could be precomputed, avoided, or parallelized."

Different layer of the stack entirely (storage I/O vs. GPU compute), different scale (kernel module vs. frontier LLM serving infra), but structurally the same optimization family: identify where the resource sits idle waiting on unpredictability, front-load the work you can predict, measure against ground truth, iterate.

Not claiming any connection between the two projects — just find it validating that this "predictive resource utilization" pattern keeps showing up as the right lever to pull, from a hobbyist kernel module all the way up to frontier model serving infrastructure. Curious if others here have seen this principle recur in other unexpected corners of systems work.

NSD repo: github.com/nsdprojectdev/NSD

Hi everyone,

I've been working on a personal Linux kernel project called NSD (Neural Storage Driver) and recently sent the first RFC patch series to LKML. I'd like to share a brief overview and get feedback from the community.

What is NSD?

NSD is an adaptive in-kernel storage prefetch engine. Instead of relying only on static readahead behavior, it observes runtime I/O access patterns and attempts to predict future reads to improve cache efficiency and reduce storage latency.

Current goals

Runtime I/O pattern learning

Predictive prefetching

Low runtime overhead

Simple architecture that integrates with the Linux page cache path

Current characteristics

Very small memory footprint (around 224 KB of static memory)

Can be loaded and unloaded cleanly using insmod / rmmod during normal system operation

Designed to avoid impacting normal kernel behavior when inactive

The project is still in the RFC stage, so I'm primarily looking for architectural feedback rather than performance claims. I'm especially interested in comments about integration with the mm/page cache subsystem, maintainability, and whether this approach makes sense from a kernel design perspective.

Constructive criticism is very welcome.

Thanks!

https://github.com/nsdprojectdev/NSD

my u-boot fork

my linux fork

my qemu fork

Hi,

As the title states, I’m familiar with both Emacs and vim and need to pick one of the two. As I’m an overthinker, I have a hard time doing so. Obviously both have their strings and weaknesses

In the hope to finally choose one, I was wondering what are nowadays kernel developers using alongside tags, whether it is ctags, gtags cscope and etags ? More specifically, I would have liked to know how you are starting your working day don’t kernel work, wether it is the tags plugins you use, wether you keep a terminal open on another tab or within vim/emacs, wether you compile from it or not, … can be anything really

I’m not trying to start a war, I’m genuinely curious because I couldn’t find any general informations about that

Many thanks for sharing your workflow in advance!

Hi i'm new to kernels, i need to find intrinsic value (focal length, principal point, distortion coefficient) to utilize in finding extrinsic (cv2.solvePnP(K, dist..)) of my python code, since i wanna use factory intrinsic value of camera).

After some searching, i found that the camera's intrinsic value is sotred in EEPROM.

Also, i know that there is UVC standard cameras which they use v4l2 default linux kernel video driver, and there is non-UVC(Vendor Specific) cameras which is rawUSB thus need vendor SDK. (Correct me if im wrong).

What i tried is for UVC standard camera, going into 1) /sys/class/video4linux, 2) /dev/i2c, 3) v4l2-ctl -d /dev/video0 -all

but still didnt see intrinsic parameters.

Is there any way through USB to find intrisic value in both UVC and nonUVC cameras?

I want to learn in depth how to populate the routing table in the kernel and how to use it. Please give me the best place to check the kernel code and what resources to help me learn better

I'm currently studying hooking in Android apps, and I ended up diving into RASP. I had to spend some time understanding how it works and how apps detect whether they're running on an emulator, on a rooted device, or if hooks are being applied.

One thing I'm still wondering about,and I haven't been able to find a clear answer,is this: if KernelSU operates at the kernel level (unlike Magisk, which modifies userspace and adds things like /su), how can an app detect that KernelSU is present?

I've heard that KernelSU exposes some files under /proc or paths like /adb/ksu, but I'm not sure how that detection actually works.

I'm just getting deep into Android application security and RASP bypass techniques, so apologies if this is a bad question. :(

After 6.18 the performance went bad, in 6.18 it was not like that, i dont know what's causing it, bad this is present all the way up to 7.1

HilalOS v0.1-R2 boot log. UEFI, paging, PMM, heap, multitasking, FAT32, AHCI, NVMe, USB UHCI and Intel E1000 all initializing successfully. Plenty left to build, but progress is steady.