I am facing problem with interrupt in guest OS runing in qemu-2.3.0.
I am loading windriver (Linux kernel-2.6.34.12-grsec) in -nographic mode in Qemu emulator on Ubuntu 14.04 host.
Host details:
>$ uname -a
>$ Linux my-qemu-host 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
my command line is:
>$ qemu-system-x86_64 -enable-kvm -nographic -k en-us -kernel ${KERNEL} -cpu kvm64 -smp 4 -m 1G ${NETCFG} -gdb tcp::1234 -append "console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=${NFSROOT}" -hda /home/hda
I am getting following logs in /var/log/kern.log
kernel: serial8250: too much work for irq4
I searched to get rid of this but so many people are suggesting to increase PASS_LIMIT in /serial/8250.c file. this workaround is just avoiding error messages in kern.log file.
Any one having idea how to stop or slow down interrupt frequency?
What exactly are you running i.e. what sort of build? It appears that some hefty serial work is going on (which is expected with embedded).
I just googled how to disable the kernel module for the serial8250 to see if that would help and happened upon this:
http://www.spinics.net/lists/linux-serial/msg12360.html
Another thought, seeing as windriver (if it's this: http://www.windriver.com/products/linux/) then I wouldn't be shocked if a "serial console" is automatically enabled. This too could drive s/w interrupt watchdogs to blacklist them as the can spam quite a bit of info depending on what they're set to output.
Sorry, it's just totally a random guess, but I'm going by pure experience with embedded serial device fun (MIPS) and (ARM) past experiences with generic distros
Related
I was trying to write a "hello world" x86_64 OS with GNU-EFI according to an article:https://wiki.osdev.org/GNU-EFI, but I ran into some problem.
When I boot the img using following command
sudo qemu-system-x86_64 -drive file=$(BUILD_DIR)/$(OSNAME).img -m 256M -cpu qemu64 \
-drive if=pflash,format=raw,unit=0,file="$(OVMF_DIR)/OVMF_CODE.fd",readonly=on \
-drive if=pflash,format=raw,unit=1,file="$(OVMF_DIR)/OVMF_VARS.fd" \
-net none
Qemu hangs after printing Found bootloader on fs0:
I can't find out what cause it.
I suspect I made some mistakes in the Makefile.
Heres the code repo:https://github.com/xubury/myos for reproduce.
BTW, you may need to specify path to gnu-efi and ovmf in the Makefile.
I ran the code under OS: Arch Linux x86_64 and Kernel: 5.11.1-arch1-1
Many thanks in advance!
So, apparently the problem goes away when I put -lgnuefi -lefi at the end of the linkage. But I don't know excatly why. Also, the gnu-efi function should be called using uefi_call_warpper for some ABI compatibility issues.
I've built a kernel and root file system for the AT91SAM9260 with the following buildroot menu selections on "Filesystem Settings":
And the kernel build settings including the at91_dt_defconfig option.
buildroot's output folders contained the following images:
rootfs.cpio rootfs.ext2 rootfs.tar zImage
I've tried to boot using qemu with the following commands:
qemu-system-arm -machine virt -kernel zImage -initrd rootfs.cpio -hda rootfs.ext2 -append "console=ttyS0,115200 root=/dev/sda" -serial stdio
Which resulted in a blank qemu screen.
What am I doing wrong? Is it a qemu operation or buildroot configuration problem?
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful. This is because (unlike x86 systems), every embedded Arm board and SoC is different to every other one, with different devices, devices and RAM at different addresses, and so on. The QEMU "virt" board is not an AT91SAM9260, and will not run a kernel that is built for that SoC.
You can either:
build a kernel that is intended to run on the 'virt' board, and run it
write device models and an SoC model for QEMU for the SoC you're interested in (beware that this is a large amount of work; it's about as much effort as porting the Linux kernel and writing device drivers for the hardware would be; it also requires either having or learning quite a lot about QEMU's internals)
I am newbie in Linux kernel and I'm trying to debug it with gdb via QEMU. My problem is gdb doesn't stop after break start_kernel. More details is below.
My host system is ArchLinux 5.0.10-arch1-1-ARCH x86_64.
Qemu is QEMU emulator version 4.0.0
gdb is GNU gdb (GDB) 8.2.1.
Debugged kernel is linux-4.20.12
I have done following steps:
Compile kernel with
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
# CONFIG_DEBUG_INFO_REDUCED is not set
Try to run LFS-8.4 system with it kernel via QEMU
qemu-system-x86_64 lfs-8.4-08052019.raw
System starts good.
Run this system with stop CPU and gdbserver options via QEMU
qemu-system-x86_64 lfs-8.4-08052019.raw -S -s
Start gdb
$ gdb
Load symbols
(gdb) file /mnt/lfs/sources/linux-4.20.12/vmlinux
Reading symbols from /mnt/lfs/sources/linux-4.20.12/vmlinux...done.
Connect to QEMU
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x000000000000fff0 in cpu_hw_events ()
Set break point
(gdb) break start_kernel
Breakpoint 1 at 0xffffffff82761ab5: file init/main.c, line 538.
(I have tried hardware break point hbreak, but result is the same)
Continue
(gdb) c
Continuing.
Further system loads login prompt without any breaks and gdb doesn't show any new messages.
What I do wrong?
UPD: starting QEMU with embed -kernel facility give the same result
qemu-system-x86_64 -kernel /mnt/lfs/sources/linux-4.20.12/arch/x86/boot/bzImage -append 'root=/dev/sda3' -drive file=lfs-8.4-08052019.raw -S -s
UPD2: I have tried to start QEMU without -S key and run target remote localhost:1234 in gdb immediately. QEMU have stopped loading at
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting kernel.
When I type s in gdb it says
(gdb) s
Cannot find bounds of current function
I suspect that debug symbols in vmlinux isn't related to bzImage. Maybe they was made wrong, but I don't how to make them another way.
UPD3: I have built kernel 2.6 in LFS-8.4 chroot environment. System isn't loaded, but kernel is successfully debugged by method described above! So, I think that it is problem of new kernels. Maybe I should switch off/on something in my 4.20.12 kernel, but I don't know what is exactly. For my purpose (reading Robert Love "Linux Kernel Development") kernel version 2.6 is enough.
You need to pass nokaslr to kernel cmdline.
qemu-system-x86_64 -kernel /mnt/lfs/sources/linux-4.20.12/arch/x86/boot/bzImage -append 'root=/dev/sda3 nokaslr' -drive file=lfs-8.4-08052019.raw -S -s
I am debugging the Linux Kernel (latest version) using GDB and QEMU.
I have set DEBUG_INFO to yes in the configuration file.
Here is how I call QEMU:
$> qemu-system-x86_64 -snapshot -m 4G -serial stdio -kernel ~/Documents/kernel/arch/x86_64/boot/bzImage -initrd ~/D\
ocuments/kernel/initrd/initrd_x86_64.gz -append "root=/dev/sda1 ignore_loglevel" -s
And GDB of course:
$> gdb vmlinux
Then inside gdb:
(gdb)> target remote :1234
So nothing amazing.
It stops QEMU. I set my breakpoints, which seems to work as usual, and I type "continue". The QEMU execution resumes.
But then, even if my function is reached (I see the kernel message printk I set inside the function), gdb does not stop.
$> qemu-system-x86_64 --version
QEMU emulator version 2.12.0 (Debian 1:2.12+dfsg-3)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
And
$> gdb --version
GNU gdb (Debian 8.1-4) 8.1
I don't know what to try next.
Any help would be appreciated.
PS: for information, I am writing a keylogger as a Linux driver. So I am registering a new keyboard notifier, and this is the keyboard notifier that is failing.
PS2: I also tried what they recommend here stack overflow question about setting hardware breakpoints instead, but it did not change anything, same problem.
Thank you.
Julien
I compiled my custom kernel with different configs and images like u,zImages. But when I try to run qemu with my image, qemu showing only black screen.
Also I looked at this post but it didn't help me.
EDIT
I just tried to compile kernel with these commands.
make ARCH=arm distclean
make ARCH=arm integrator_defconfig
make ARCH=arm menuconfig
NOTE: I used default menuconfig.
make ARCH=arm CROSS_COMPILE=arm-none-eabi- zImage
qemu-system-arm -M integratorcp -kernel arch/arm/boot/zImage
And last i tried this command;
qemu-system-arm -M integratorcp -kernel arch/arm/boot/zImage -append 'console=ttyAMA0 earlyprintk=ttyAMA0' -serial stdio
NOTE: when i try to use -dtb, qemu giving to me "Unable to copy device tree in memory." error.
"QEMU does nothing with a black screen" almost always means "QEMU is running fine, but the guest code crashed or stopped early in the boot process without sending any output". Almost certainly either your kernel is misconfigured, or your QEMU command line is wrong. You don't give enough information to say which. You need to tell us at least:
what the kernel is you're running and what machine you've configured it for
what the QEMU command line you're using is
Given your updated question with a command line, some suggestions:
tell your guest to use the serial port (use the QEMU option -append 'console=ttyAMA0' to set the guest kernel command line)
either check the serial output view in the GUI, or send it to stdout with -nographic or -serial stdio
enable any earlyprintk or earlycon options in the guest config that you can and on the guest command line, so if the guest fails early you have more chance to catch it
pass the device tree for the kernel with -dtb integratorcp.dtb (use the one from your kernel tree; you'll probably have to tell the kernel makefiles to build it for you)
PS: integratorcp is an absolutely ancient development board -- why do you want to use it?