I am trying to learn about IPSec layer in Linux kernel using Trace 32 ICD. For that I am trying to trace packet flow from user land to Ethernet driver. Problem I'm facing is that Trace32 is not able to display inline functions in stackframe output and therefore are jumps in my flow.
I am just wondering if :
a) there is a way to disable inline feature for kernel function (or in any program) in GCC.
b) there is a way to add support for inline functions in Trace32 ICD tool.
In case answer for both a & b is no then I would like to know if there exits a workaround to my problem.
My linux version: Linux (bts) 3.0.1-rt11-svn9237 #2 PREEMPT RT Fri Dec 21 09:58:42 IST 2012 armv7l GNU/Linux
My GCC version: arm-none-linux-gnueabi-gcc-4.3.3
Related
What version of Go are you using (go version)?
go version 1.15
Does this issue reproduce with the latest release?
No
What operating system and processor architecture are you using (go env)?
Linux 5.4.54-1.0.0.std7c.el7.2.x86_64 #1 SMP Mon Nov 16 10:02:20 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
What did you see instead?
Below is a screenshot of the abnormal machine
What did you do?
The memory usage is too high, but there is no memory leak by analyzing the heap file of pprof.
The reason for this conclusion is:
My service is deployed on k8s, and there are other same services. The pprof file analysis results are similar to this problematic one (linux kernel version is 4.9.2-3.0.0.std7b.el7.5.x86_64 cmd/cgo: fails with gcc 4.4.1 #1 SMP Thu Apr 26 17:33:02 CST 2018 x86_64 x86_64 x86_64 GNU/Linux).
I refer to the MADV_FREE problem in the link below. By analyzing the LazyFree of the /proc/1/smaps file, I found that it is all 0, and all machines are linux kernel 4.5 or above. Logically, the same problem will occur, but it does not No. runtime: default to MADV_DONTNEED on Linux #42330
gotrace records are normal
What did you expect to see?
Why is the memory usage of this service high? What impact does Linux kernel version 5 and above have on golang memory management?
enter image description here
enter image description here
enter image description here
It's not related to the kernel version.
Go 1.15 used MADV_FREE by default to release memory. This memory was released very lazily by the kernel resulting in larger RSS until the memory was actually needed elsewhere. Hence RSS didn't reflect anything close to the Go programs actual usage.
Go 1.16+ defaults to using MADV_DONTNEED, which results in memory being released much more promptly by the kernel.
See https://go.dev/doc/go1.16#runtime for more details.
You can use the GODEBUG=madvdontneed=1 environment variable on Go 1.15, or preferably upgrade to a supported version of Go (eg, Go 1.19). Go 1.20 will be released soon, so that would be a good target too.
I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I have it partially running, but it crashes intermittently on printf's. Can anyone tell me if there's a way to make printf() SMP safe? printf appears to use termios which uses rtems_mutex_init() and rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm also new to this so I'm not sure).
Thanks!
So I've been gifted 2x gen 1 Galileos that I want to try to do something with before I throw them in the garbage.
It's my understanding that they wont run most i386 kernels from most distros as they need to be Pentium II compile flags.
So this guy shared his kernel configs https://twitter.com/kerneldave/status/1359178557570732032 and I have compiled the kernels using a standard GCC stack on ubuntu.
I cannot get the resulting kernel to boot. After Grub loads the kernel there is no activity on the console (via the serial cable)
Will mainline kernels work on Gen 1?
Does it need to be compiled with some special toolchain or will gcc be fine?
Any special boot params need to be used, APIC/ACPI, console options?
Thanks
I have multiple questions regarding debugging a Raspberry pi 3 from a linux x64 host using gdb-multiarch, as well as writing bare metal programs in general. We are currently facing a problem where our code appears to not be loaded into memory. When we begin debugging in GDB we start at address 0. 3 instructions down we jump into 0x10000. If I modify my linker script to put the Raspberry pi into either address I get the same result, we jump into 0x10000 and our code isn't loaded there. Instead we get this
We noticed also that GDB is using 32 bit register names here when we're supposed to be debugging 64 bit code.
Again a recap of what we're using:
QEMU with versatile-pb machine.
An aarch64 GCC cross-compiler.
GDB-multiarch.
We've tried on two different hosts: Ubuntu 16.04 x64 Host running in virtualbox. Mint x64 running natively.
We also tried the arm-none-eabi toolchain but were running into problems not having our code compiled as 64 bit.
Help is much appreciated! Thanks!
You don't give your command line, but "versatile-pb" is a 32-bit only board type, so trying to run 64-bit code on it is going to misbehave in confusing ways. You need to tell QEMU to emulate a 64-bit capable board that matches what your bare-metal code is expecting to run on.
In QEMU 2.12 there will be a "raspi3" QEMU board which may be helpful for you; you'd need to try building the latest 2.12 release candidate tarball at the moment if you wanted to experiment with that (2.12 release isn't due for another couple of weeks). Otherwise you could use the "virt" board if you made sure your bare metal code was built to be able to run on that board.
I found my WD MyPassport Wireless is running Buildroot Linaro linux with busybox; It doesn't have aptitude package manager. I don't know much about busybox; I came to know the commands provided by the busybox are called defined functions. How can I install Transmission BitTorrent client? I came across something called patch that i think provides Transmission function for the Buildroot busybox
http://buildroot-busybox.2317881.n4.nabble.com/PATCH-introducing-transmission-bittorrent-client-td7898.html
Is this the thing that does the thing? If so, how to go forward?
# uname -a
Linux Mammoth 3.2.0 #1 Tue Sep 8 14:42:47 CST 2015 armv7l GNU/Linux
You're confusing many things here. First "Buildroot Linaro" doesn't mean anything. Buildroot (http://buildroot.org) is an open-source project that provides an embedded Linux build system, Linaro (http://linaro.org) is a non-profit organization that enhances the support of the ARM architecture in the Linux eco-system. The main interaction between the two is that Buildroot can use a Linaro toolchain as the cross-compiler.
Indeed, there is nothing like "aptitude" on a Buildroot generated system, because we don't support binary packages. See http://buildroot.org/downloads/manual/manual.html#faq-no-binary-packages for details.
Finally, you're confusing Buildroot and Busybox. Busybox is a userspace application that provides a lightweight implementation of many basic Linux utilities. It is one of the 1600+ userspace packages provided by Buildroot.
Busybox definitely doesn't provide a Bittorent client. However, Buildroot indeed has a package for transmission.
So if you want to move forward, you need to get the source of the Buildroot that WD used to generate the firmware to your device, modify this Buildroot to add transmission, then re-build the filesystem using Buildrot, and finally flash it on your device.