I'm on a Yocto Linux distribution and I need to set the sysctl tunable kernel.panic_on_rcu_stall to 1. The problem is when I list the elements inside /proc/sys/kernel I have no panic_on_rcu_stall and if I try to set the option anyway I get the folowing error:
# sysctl -w kernel.panic_on_rcu_stall=1
sysctl: error: 'kernel.panic_on_rcu_stall' is an unknown key
I know that the key exist, we can see it on the Linux Kernel documentation, but it also specify that
Currently, these files might (depending on your configuration) show up in /proc/sys/kernel:
And this is all about, what the documentation means by your configuration and how to change it.
I'm using the 4.4.38+linaro Linux kernel.
Thanks in advance.
Thanks for your comments, Tsyvarev was right, after applying this patch to my kernel recipe in my Yocto project, the option kernel.panic_on_rcu_stall appeared in /proc/sys/kernel.
Related
I am running ubuntu 18.04, kernel 4.19.94-ti-r36, on a a beaglebone black. I am connected to ssh, and am trying to adjust the boot configuration of the GPIO pins. After boot, I am able to change and query individual GPIO configurations with the "config-pin" command, which is useful for experimentation. But I would like to change all the default GPIO configuration on boot, which this tool does not appear to do.
I found this tutorial on using a device overlay to achieve this here:
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
but I am missing the "bone_capemgr.8" directory. I googled this issue and was directed to this page, which says that device tree overlays are now deprecated, and to use u-boot overlays instead:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays.2C_which_got_loaded
I read through the article, and googled around, but I haven't found anything on how to actually use a u-boot overlay to change the configuration of the GPIO pins on boot.
Does anyone know how to do this, or know where I might find a good resource to this effect?
Thanks!
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
sudo apt install bb-cape-overlays
create a .dts file with the correct configuration
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
something to do with boot images (?)
Questions:
what does searching "in the kernel" mean? how would I do this?
for the actual .dts file, I looked around and found this as a starting point:
https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts My plan is to modify/extend lines 29-33 to change the boot configuration of all relevant pins. The second hex number is the pin mode I'm trying to change; that makes sense. The first hex number looks like it somehow corresponds to pin number, but I'm not sure how? for example, 0x078-->P9.12,0x184-->P9.24, etc.
when/where does making an image come into play? what about making two different partitions? I didn't follow that part
to use the uboot-overlays, which is a given for most concepts with GPIO pins on the BBB, one would have to install bb.org-overlays which are found here, https://github.com/beagleboard/bb.org-overlays, and to understand Device-Tree Specifications.
https://github.com/beagleboard/BeagleBoard-DeviceTrees will help you, too.
The Device Tree specification can be found here: https://www.devicetree.org/
In the kernel, you can search the docs. and kernel for specific, already-made device tree ideas and files.
Also, it is as simple as creating your dts file, compiling it, and putting it in the correct space on the BeagleBone Black in /boot/uEnv.txt.
For instance, if I had a specific .dtbo that I compiled from my .dts file(s), I would simply put it in the /boot/uEnv.txt file under this heading...
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays should explain the ideas I am listing.
Oh! Also, when creating your image, one would have to create the two partitions, one for booting and the other for the actual OS/filesystem.
Once this is completed, one would have to install the file uEnv.txt in the /boot dir. by simply making the file in a text editor, saving it, and placing it in the system before compilation via make menuconfig or whatever you are using to install the boot partition and OS partition.
If you need exact placements of the files in the kernel to search under for the .dts, .dtb, and .dtbo files, ask away. I have had complications with this before and lacking understanding, I have been a drift. Luckily, there is a long list of ideas but one needs to make them accessible in the correct order.
Also: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black are some ideas on how to start the image factory of making things available for the BeagleBone Black.
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
git clone https://github.com/beagleboard/bb.org-overlays
create a .dts file with the correct configuration
Your configuration of the .dts file works too...(supposedly as I have not seen it).
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
Not this idea. Although, compiling using the device-tree-compiler is an option, I say use their build script w/ their Makefile.
So, try ./install.sh
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/your_newly_added_file.dtbo
...
Also and excuse me if this does not work, you can try with the BeagleBoard-DeviceTrees link I provided.
In that one, you would simply place the correct file, your .dts file, in the /src/arm/ directory, and go back to the BeagleBoard-DeviceTrees/ dir. to perform the make command.
It will perform all the necessary .dts to .dtb to .dtbo file operations.
This is the /boot/uEnv.txt file I have currently...
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-r59
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
See where the file states #dtb=? That is section where the .dtb needs to be located and uncommented by removing the hash symbol.
Also, under that particular section of the file, there are u_boot-overlay sections. You can now add your .dtbo files in those particular slots.
How can one add more delegates to ImageMagick? I'm on gentoo (so, emerge), and while I see a plethora of links to different issues, I've not found any general how-to's:
This points to the source of the delegate libraries here
This points to the need to install underlying image libraries (e.g. libpng), and seems to generally be a repository for everyone's ImageMagick "no decode delegate" questions.
This sort of points back to a second person's issue in the first bullet, though it makes use of a ./configure command that I don't see in my ImageMagick directory
And finally, this might be the answer I need, though the syntax is garbled such that I cannot tell what the intended command is.
In particular, none of these explain what exactly one must do with the delegate libraries here, if they do indeed need to be installed manually. Anyway, my delegates are currently listed (via convert -list configure|grep -i delegate) as bzlib, mpeg, and zlib. I've installed media-libs/libpng, media-libs/tiff, and media-libs/libjpeg-turbo. I didn't grab media-libs/jasper, as it's not clear whether it is necessary. Removing and then installing ImageMagick anew after this (sudo emerge -cav media-gfx/imagemagick then sudo emerge -v media-gfx/imagemagick) didn't change any of my delegates.
Short Answer
A number of these can be handled by setting the USE flags on the imagemagick package. Some use flags can be found by looking at the package's entry on packages.gentoo.org. For a definitive list, check the ebuild on your machine or use tools such as equery.
Details
Portage, gentoo's package manager, is actually just a list of steps needed to build a package from source. USE flags allow you to customize that process. In this case, it changes which packages are built as dependencies.
Steps
One way to set the USE flags is to create a file in /etc/portage/package.use and write the package name on it's own line followed by all the use flag you would like to set. (eg. =media-gfx/imagemagick-7.0.8.8 png would set the png flag for version 7.0.8.8.
Once the USE flags are set, re-emerge the package to build with the new settings (eg. emerge --ask --verbose =media-gfx/imagemagick-7.0.8.8)
For more details on USE flags, read https://wiki.gentoo.org/wiki/USE_flag
I have built, installed my custom kernel. I need to prove that the new kernel is built and running. I have tried exploring /var/log/ for the log messages. I searched Xorg.log and dmesg.log and boot.log files for getting information about my newly built kernel, but I am unable to find the logs for the same. Can anyone let me know how and where I can find the logs for my new kernel. I am using ubuntu.
Thanks.
#user2559758 you need to go into General Settings tab and select the older kernel version as the default Kernel. (there is a drop down menu, choose your old kernel as default kernel). Now save your changes (top left corner). exit grub loader. reboot. Once the reboot happens, cp /var/log/dmseg ~/oldlog. Again run grub-customizer switch to General Settings (2nd tab) choose new kernel version, save, reboot. Now you can copy cp /var/log/dmesg ~/newlog . Now do diff oldlog newlog
Let me know if you have issues. If the answer is still unclear, please send the screenshot of General Settings tab. Also give the name of new and old kernel version names and I will be able to assist you better.
You can get the kernel version by running uname -a. If you built your new kernel with a unique version name (I don't recall off hand where the setting is in the kernel configuration), it'll be obvious which kernel you're running.
In my boot options of my installed CentOS on VBox, I have the followings that really mess me up to figure out how to eliminate those that doesn't work anymore, e.g the first one which is reported as unavailability of kernel root to boot. I can only choose the last one to boot the system.
> CentOS(2.6.32-200.17.1.e16.x86_64)
> CentOS(2.6.32-200.17.1.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64)
> CentOS(2.6.32-200.4.1.e16.x86_64)
> CentOS(2.6.32-200.e16.x86_64)
Where are these stored once I boot the system with the last option ? What if I would like to delete (completely) one of them ? I don't know what the xxx.debug's are there for ?
Thank you for any help
On most distros today the boot manager is GRUB. The configuration of boot menu is usually stored in /boot/grub in a file called menu.lst or grub.cfg depending on GRUB version and distro. In that file, you can comment out sets of lines corresponding to the OS you don't want in the menu - syntax should be pretty intuitive.
On some distros the file is generated by a set of scripts, in this case a comment at the top say you shouldn't edit that file directly. For example in Debian, the scripts which generate the configuration reside in /etc/grub.d/ and they do all sorts of auto-probing for available OS's. In this case one needs to either modify the script or to remove the OS images which are automatically appended to the menu. The exact way to do this cleanly may vary depending on your setup - perhaps some of these boot images can be removed using a package manager which would be more elegant than just removing files manually.
Either way, be careful, since removing the wrong file related to booting may make it impossible to boot your OS or even to start GRUB at all if you're extremely unlucky.
If I find an option in .config that I would like to enable or disable. Is there a quick way to find it in menuconfig menu?
i.e. I don't want CONFIG_STRICT_DEVMEM to be set. I had to guess where I can find it in the make menuconfig sub-menu. Is there a programmatic way or a faster way to find the sub-menu, rather than "guess"?
If I remember correctly, you can just hit
/DEVMEMEnter
and you'll be taken there? Look for the 'search'/'find' option. If my memory serves me well, it will even tell you about required dependencies
You can use the key / while in menuconfig to research a particular string. This will give you a list of matching configuration option and their path.
You can also use a gui instead of the ncurse menuconfig by typing make xconfig.
Another way to do the lookup would be to use the find command like that:
find /path/to/kernel/sources -name Kconfig -exec grep -Hn config_pattern {} \;
.config is a text file. As such, the easiest way to directly modify an option is to simply place y, m, or n as required. make oldconfig can subsequently be used if this leaves the configuration in an inconsistent state.