Error: edac skx ecc is disabled on imc 0 on ubuntu 20.04 - ubuntu-20.04

I have an ubuntu workstation with intel i9 and Nvidia Graphics Card. While running a Gromacs MD simulation my system crashed and when I start it again, instead of showing ubuntu login, the display shows an error: edac skx ecc is disabled on imc 0.

Finally, I figured out this. Actually, I have two GPU's in my system and xconfig file mentioned the wrong GPU ID for display. I have connected display port to the GPU ID 0 whereas the xconfig file selected the GPU ID 1. I restored xconfig file by replacing the xorg.conf from the original Nvidia xconfig backup file.
Go to tty mode and type following commands
cp /etc/X11/xorg.conf.nvidia-xconfig-original /etc/X11/xorg.conf
reboot

Related

Custom built kernel fails to install correctly - Centos7

I am attempting to build and install multiple kernels on my machine, all of the exact same release (4.19.10, found here) but with different preemption models (for benchmarking). I was successful with initial vanilla kernel build and install, but all subsequent installs have not been bootable.
I am building the kernels as rpm packages. Again all are the exact same except for 2 changes in make menuconfig:
General Setup >> Local version - append to kernel release - Here I add a string to indicate preemption model, such as -lld for low-latency desktop
General Setup >> Preemption Model - Here I select the preemption model
All of them (with and without CONFIG_RT_PREEMPT patch) build fine with no errors.
I am installing with rpm -ivh kernel-4.19.10_lld-1.x86_64.rpm, which appears successful until it reaches 100% and hangs. Eventually I kill the install with ctrl+c and check what is running with top and can see grub2-editenv is still running.
From here, a few different things can happen but it all ends up the same. Reboot usually hangs, a 2nd reboot either brings me to grub command line or back to the command line with Welcome to emergency mode!.
I can add the new kernel to grub with grub2-mkconfig -o /boot/grub2/grub.cfg, which has no issues. But regardless of selecting the boot image from the grub command line directly or adding it to grub and selecting it during boot, I get the same text:
error: invalid magic number.
error: you need to load the kernel first
I recognize that there might not be enough info here to identify my issue, but I was hoping to at least get some direction and answer a few questions:
Is utilizing General Setup >> Local version - append to kernel release sufficient enough to make these kernels unique so that they may be installed along side one another?
Are these symptoms indicative of a bad build, incorrectly configured rpm spec, or just a bad grub configuration?
Thanks
Update: I was able to upgrade my kernel with rpm -Uvh kernel-4.19.10_lld-1.x86_64.rpm successfully and have it correctly boot, although I could not do that with one of the other kernels. Not sure what that indicates, but I'm thinking the issue is probably trying to install the same kernel versions in parallel and the builds themselves are probably OK.
Update 2:
I ditched the rpm solution and tried just make modules_install and make install. Installs no issues, but then running grub2-mkconfig hangs. Booting hangs at black screen, rebooting takes me to grub command line. Then manually loading the kernel does not give any errors but booting ends up with a kernel panic right after the hardware is identified. Message is Kernel Panic - not syncing: VFS: Unable to mount.
Probably related - I built the first (working) kernel on a VM (intel i7 hardware), but have been building the others on an intel atom e3950 chipset. I'm thinking that might be the issue because the menuconfig ends up different. I dont think I've had a healthy build on that chipset yet.

Basic linux kernel development and testing environment using qemu

I want to learn about the linux kernel and this is why I wanted a simple but powerful enough way test kernel changes that I do.
I used the info on this page https://mgalgs.github.io/2015/05/16/how-to-build-a-custom-linux-kernel-for-qemu-2015-edition.html to start.
So now I can start a qemu session with the kernel I choose and also have busybox utilities.
The part I cannot understand is how do I transfer a kernel module .ko on this virtual machine as to load it in my modified kernel ? I tried also transfering a c program by incorporating it in the initramfs but when I try to run the program I receive the following error message:
"/bin/sh: ./proc1: not found" .
Should I use a virtual hdd image ? If so how do I create and use one ? How do I transfer files from host os to the virtual hdd ?
Thnaks in advance.
The created virtual hdd was not discovered because I didn't use mdev -s in the init file.
After that I could mount the sda in qemu session.
The c program that could not be ran I solved by compiling it with the -static flag.

Ubuntu 16.4 installation unknown error

I am facing this problem, please see this image:
You should try by changing the language to English from Bengali.
The following instructions went well for me:
How to install Ubunto 16.4 TLS on a fresh PC (amd64)?
Insert a USB key, larger than 2GB
Format the USB with FAT32: Spotlight --> Disk Utility --> ms-FAT + GUID
Mount the ISO file to the USB key with unetbootin app
Boot the target PC from the USB key, in UEFI mode
Lunch "Install Ubunto" with adding the following boot-keys (next to quiet splash): pci=noaer pci pcie_aspm=off
Complete the installation --> choose "Erase disk and install" (fresh) and choose to update everything during installation
When installation complete, reboot and then add the additional boot-keys (step 5 above) to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub
sudo update-grub
Good luck,
Shahar

Rebuilding exisiting linux kernel on hardware(microzed zynq)

I have xillinux OS (based on ubunutu 12.04.LTS) installed on my hardware (ZYNQ FPGA Board). I have done some hardware reconfiguration and I need to rebuild my kernel after editing the config-3.12.0-xillinux-1.3 file. My question is how do I rebuild the existing kernel on the hardware after making changes to the config file
http://www.wiki.xilinx.com/Uartlite+Driver
This is the page above that I am referring to where they say that:
To enable the uartlite driver in the linux kernel you either have to integrate it or build it as kernel module (.ko). You can enable it with:
make menuconfig
---> Device Drivers ---> Character devices ---> Serial drivers ---> Xilinx uartlite serial port support
make menuconfig - I have to enter this command on the OS running on my hardware in the /root/boot/.config folder to enable it ?
What does , ---> Device Drivers ---> Character devices ---> Serial drivers ---> Xilinx uartlite serial port support THIS MEAN ? I have to change directory ?
The other option as per the link posted above is to add certain lines as below to the config file, for which I would use the nano editor and then save it with ctrl+X and then Y.
# integrate into the kernel
CONFIG_SERIAL_UARTLITE=y
# build as loadable module
CONFIG_SERIAL_UARTLITE=m
But they say that, "After that you of course have to rebuild the kernel and deploy it to your Zynq device."
Where zynq is the hardware I am running my OS on. What commands do I have to use to rebuild the existing kernel on my hardware after making changes to the .config file ?
So, after rebuilding the kernel with the changes above, I just reboot to observer the changes ?
EDIT:
I was referring to this link, http://www.thegeekstuff.com/2013/06/...-linux-kernel/
So, in order to compile the exisiting kernel on the hadrware and build it, I edit the .config file using nano in /boot folder and save it.
Then, I type "make" in the same folder as config.
Then, I type "make modules" in the same folder
Then I type make modules_install Then I type make install
Then I reboot the system to see the new kernel installed.
Is this the right way of doing it ?
Is this how you recompiled and rebuilt it ?
Currently in my boot directory, there are 4 files.
One config file and 3 .dts files. After rebuilding the kernel, this might change ?

Setting up two-machine kernel debugging via firewire

The instructions found at Setting Up Kernel Debugging are what I used to get to this point. On the machine running the kext I want to debug, I do see the message "Connected to remote debugger". On the machine I am running gdb on, I do see:
(gdb) kdp-reattach localhost
Connected.
The problem is that 'showallkmods' returns an empty list and none of the other similar commands appear to be working:
(gdb) showallkmods
kmod address size id refs version name
(gdb) showalltasks
task vm_map ipc_space #acts pid process io_policy wq_state command
Invalid type combination in equality test.
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) showallkmods
kmod address size id refs version name
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) showbootargs
Invalid cast.
I am running 10.6.8 and am using kernel_debug_kit_10.6.8_10k540.dmg
I am not sure what other details one might need to diagnose what has gone wrong, but if you want to ask questions in the comments, I can certainly attempt to provide additional details.
The error "Invalid type combination in equality test." indicates to me that gdb might be expecting a different CPU architecture than the kernel you're connecting to is running. The 10.6 kernel exists in both 32-bit and 64-bit variants, and by default it's determined by the hardware which one gets loaded. gdb normally defaults to x86_64 if your CPU supports it (true of all Intel Macs except the very early Core Duo based ones) so if you're connecting to a 32-bit kernel (the default on most Macs released before 2011) you need to pass the -arch i386 argument when starting gdb. You can check the current kernel CPU architecture by running the uname -a command.
Update: on OSX Mountain Lion, the kernel always runs in 64-bit (x86_64) mode. On OSX Lion, the kernel defaults to 64-bit mode on Macs which are capable of running Mountain Lion and in 32-bit mode otherwise.

Resources