Bugs: Difference between revisions

From KVM
(add trace link)
(Update some old information)
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
Kernel side KVM bugs should be file to the [https://bugzilla.kernel.org/ kernel's bug tracker].
Kernel side KVM bugs should be file to the [https://bugzilla.kernel.org/ kernel's bug tracker].


Userspace bugs should be filed to [https://bugs.launchpad.net/qemu Qemu's launchpad tracker]. If you think they are qemu-kvm specific (i.e. upstream qemu is not affected), you should mark them clearly as being qemu-kvm specific.
Userspace (QEMU) bugs should be filed to [https://gitlab.com/qemu-project/qemu/-/issues QEMU's issue tracker].


If in doubt, email (kvm@vger.kernel.org) the mailing list first (no need to register) and you will be directed where to file the bug if necessary.
If in doubt, email (kvm@vger.kernel.org) the mailing list first (no need to register) and you will be directed where to file the bug if necessary.
Line 14: Line 14:


* What cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210).  See /proc/cpuinfo if you're not sure.                                                                                           
* What cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210).  See /proc/cpuinfo if you're not sure.                                                                                           
* What kvm version you are using.  If you're using git directly, provide the output of 'git describe'.


* The host kernel version
* The host kernel version. If you're using git directly, provide the output of 'git describe'.
        
        
* What host kernel arch you are using (i386 or x86_64)
* What host kernel arch you are using (aarch64, s390x, ppc64, i386 or x86_64)


* What guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version
* What guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version
                       
 
* The qemu command line you are using to start the guest
* The qemu command line you are using to start the guest


* Whether the problem goes away if using the <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.
* Whether the problem goes away if using the <code>-machine kernel_irqchip=off</code> QEMU switch.
                              
                              
* Whether the problem also appears with the <code>-no-kvm</code> switch.
* Whether the problem also appears with the <code>-accel tcg</code> switch.


Please use the latest release version of kvm at the time you submit the bug.  Even if you use kvm from a distribution (Ubuntu starting from Feisty or Fedora starting from 7), it is important to use the latest sources.
Please use the latest release version of the Linux kernel at the time you submit the bug.  Even if you use kvm from a distribution, it is important to use the latest sources.


In case qemu-kvm exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with
In case QEMU exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with


(gdb) info threads
(gdb) info threads
Line 57: Line 56:




If after a crash, there is still no output in the serial.log file and the guest kernel was configured touse a serial console; chances are that the crash was too early in the process to have the console initialized and then the following kernel command line should be used additionally (only to be used as a last resort as it interacts badly with the console boot parameter)
If after a crash, there is still no output in the serial.log file and the guest kernel was configured to use a serial console; chances are that the crash was too early in the process to have the console initialized, so then the following kernel command parameters should be added (but only use as a last resort as it interacts badly with the console boot parameter)
  earlyprintk=serial,ttyS0,115200
  earlyprintk=serial,ttyS0,115200


Line 67: Line 66:




if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot asthere will be no output in the SDL console and you won't be able to interact with it through the keyboard.
if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot as there will be no output in the SDL console and you won't be able to interact with it through the keyboard.


= Tracing =
= Tracing =


When debugging kvm, it is often convenient to get a [[Tracing|trace]] of what's going on.
When debugging kvm, it is often convenient to get a [[Tracing|trace]] of what's going on.
[[Category:Docs]][[Category:HowTo]][[Category:Debugging]]

Latest revision as of 08:18, 2 August 2021

Bugs

Kernel side KVM bugs should be file to the kernel's bug tracker.

Userspace (QEMU) bugs should be filed to QEMU's issue tracker.

If in doubt, email (kvm@vger.kernel.org) the mailing list first (no need to register) and you will be directed where to file the bug if necessary.

Historical bug reports can be found in the sourceforge bug tracker.

Submitting a bug report

When submitting a bug report, make sure to provide the following information:

  • What cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210). See /proc/cpuinfo if you're not sure.
  • The host kernel version. If you're using git directly, provide the output of 'git describe'.
  • What host kernel arch you are using (aarch64, s390x, ppc64, i386 or x86_64)
  • What guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version
  • The qemu command line you are using to start the guest
  • Whether the problem goes away if using the -machine kernel_irqchip=off QEMU switch.
  • Whether the problem also appears with the -accel tcg switch.

Please use the latest release version of the Linux kernel at the time you submit the bug. Even if you use kvm from a distribution, it is important to use the latest sources.

In case QEMU exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with

(gdb) info threads

And for every thread present do:

(gdb) thread n

(gdb) bt

Attach the output to the bug report.

Getting a serial console from the guest

If a guest crashes on boot, it is sometimes useful to have its console output. This can be done using qemu's -serial option to emulate a serial port: 

qemu-system-x86_64 -serial file:serial.log


Depending on the guest OS you will need to do some additional changes to instruct it to use the serial port as a console as shown below :

Linux

Change the guest kernel's command line (in the GRUB or LILO menu) to include the string 

console=ttyS0,115200


If after a crash, there is still no output in the serial.log file and the guest kernel was configured to use a serial console; chances are that the crash was too early in the process to have the console initialized, so then the following kernel command parameters should be added (but only use as a last resort as it interacts badly with the console boot parameter) 

earlyprintk=serial,ttyS0,115200


OpenSolaris

Change the guest kernel's entry in the GRUB menu to include the string 

-B console=ttya


if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot as there will be no output in the SDL console and you won't be able to interact with it through the keyboard.

Tracing

When debugging kvm, it is often convenient to get a trace of what's going on.

Retrieved from "https://linux-kvm.org/index.php?title=Bugs&oldid=174022"