Bugs - Revision history

Thuth: Update some old information

2021-08-02T13:18:15Z

Update some old information

← Older revision		Revision as of 09:18, 2 August 2021
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

Speculatrix: cosmetic changes only

2015-07-14T15:18:38Z

cosmetic changes only

← Older revision		Revision as of 11:18, 14 July 2015
Line 57:		Line 57:


	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 67:


	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 =

Bsd: added categories

2015-05-31T13:42:58Z

added categories

← Older revision		Revision as of 09:42, 31 May 2015
Line 72:		Line 72:

	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]]

AviKivity: add trace link

2011-03-09T15:28:15Z

add trace link

← Older revision		Revision as of 11:28, 9 March 2011
Line 68:		Line 68:

	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 asthere 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 [[Tracing\|trace]] of what's going on.

Iggy: cleanup links

2010-05-21T16:24:57Z

cleanup links

← Older revision		Revision as of 12:24, 21 May 2010
Line 1:		Line 1:
	=Bugs=		=Bugs=

	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 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.

	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.

Iggy: remove extra brackets around tracker links

2010-05-21T16:23:40Z

remove extra brackets around tracker links

← Older revision		Revision as of 12:23, 21 May 2010
Line 1:		Line 1:
	=Bugs=		=Bugs=

	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 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.

	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.

Iggy: Change to using Qemu and the kernel's trackers instead of the sourceforge one... also some white space cleanups

2010-05-21T16:22:14Z

Change to using Qemu and the kernel's trackers instead of the sourceforge one... also some white space cleanups

← Older revision		Revision as of 12:22, 21 May 2010
Line 1:		Line 1:
	=Bugs=		=Bugs=

	~~You can submit bug reports either through~~ the ~~sourceforge~~ [~~http~~://~~sourceforge~~.~~net~~/~~tracker/?atid=893831&group_id=180599&func=browse~~ bug tracker] ~~or directly~~ to ~~the~~ [~~mailto~~:kvm@vger.kernel.org mailing list] (no need to ~~subscribe~~). ~~Bugs submitted through~~ the bug tracker ~~show up on the list as well~~.		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.

			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 [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker].

	== Submitting a bug report ==		== Submitting a bug report ==
Line 7:		Line 13:
	When submitting a bug report, make sure to provide the following information:		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.		* 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'.		* What kvm version you are using. If you're using git directly, provide the output of 'git describe'.
	* ~~the~~ host kernel version
	* ~~what~~ host kernel arch you are using (i386 or x86_64)		* The host 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		* What host kernel arch you are using (i386 or x86_64)
	* ~~whether~~ the problem goes away if using the <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.
	* ~~whether~~ the problem also appears with the <code>-no-kvm</code> switch.		* 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 <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.

			* Whether the problem also appears with the <code>-no-kvm</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 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.

MarkusArmbruster: Fix markup

2009-07-09T21:10:30Z

Fix markup

← Older revision		Revision as of 17:10, 9 July 2009
Line 1:		Line 1:
	=Bugs=		=Bugs=

	You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto: kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well.		You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto:kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well.

	== Submitting a bug report ==		== Submitting a bug report ==

Mtosatti at 21:05, 13 April 2009

2009-04-13T21:05:51Z

← Older revision		Revision as of 17:05, 13 April 2009
Line 19:		Line 19:

	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-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

			(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 ==		== Getting a serial console from the guest ==

Jeremy.perry@redhat.com at 14:17, 11 March 2009

2009-03-11T14:17:38Z

← Older revision		Revision as of 10:17, 11 March 2009
Line 1:		Line 1:
			=Bugs=

	You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto: kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well.		You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto: kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well.