While it is tempting to use printk or pr_info when coding in order to trace function in the Linux kernel calls, it turns out that there os a; ready a utility to simplify that. Here are the steps I used to enable ftrace for mcpt-pcc and figuring out where a function call stack ended (in the middle of a debugging session where I had broken it)
Continue readingThe following command will print a stack trace whenever pcc_send_data is called.
sudo bpftrace -e 'f:pcc_send_data{print(kstack())}'Software Development flow is an elusive beast, easily frightened away. The easiest way to lose the flow is to have a long development cycle. Building the entire Linux Kernel takes time. If you are developing a single driver that can be built as a stand alone module, you do not want to have to rebuild the entire Kernel each time you make a change to that module. If that module crashes the machine when it runs into an error, you do not want to have to wait for that machine to reboot before digging in to the debugging process.
These two guidelines lead to a pattern of building on one machine and deploying on another. Here is one way to go about this process.
We regularly sync various git repos from upstream to our company speicfic Linux repository. However, sometimes when working on a development machine, I need a branch from stable that we have not synced yet. If I did a blobless clone from our repository, doing a fetch from stable is going to pull over lots of blobs that I do not need.
Instead, I want to fetch just a specific tag. I can do this by adding the tag to the fetch command, and it will pull over only those blobs
Cloning the Linux Kernel repository takes time. We don’t need every commit ever for our work. But we do need multiple branches. Here are some numbers for how long it takes to do various operations.
Continue readingIt took me a couple months to get back to my patch, and in the interim, I forgot everything about formatting a patch series to LKML. Here’s what I have remembered.
Continue readingdmidecode -t processor | grep Version
Version: Ampere(R) Altra(R) Processor
Version: Ampere(R) Altra(R) Processor
The Linux Kernel git repo has a spec file that builds the Kernel RPM. However, it does not build perf or any of the other userland tools. I want to build a perf RPM using the same code as is used to build the Kernel RPM.
Here are my debugging notes.
Continue readingHow can I create a binary kernel RPM that has patches that have not yet merged into the mainline kernel? One approach to building the Kernel RPM is to use the Makefile option provided with the Kernel. While we typically do this, it does not provide us with the user land tools like perf and its libraries used to test certain patches.
An alternative approach is to take the Fedora Kernel Source RPM that matches the targeted upstream Kernel version, and modify it to apply the set of patches. Here is a walk-through of the process I just got to succeed.
Before code goes up stream, it should be rigorously tested. In order to do so, we build Kernels based on the corresponding Fedora version, as Fedora tracks Linux Stable fairly closely. However, we want to be able to distinguish between a Kernel we build with one that comes from Fedora.
Continue reading