Hi all,
I found a way to reliably crash my host system:
1) Boot guest VM with init=/bin/bash
2) In guest VM: echo b /proc/sysrq-trigger
3) Try to reboot the guest - crashes the host during kernel initialization
When I checked the logs I first thought it would be a KSM issue:
Jul 10
On 07/10/2013 06:02 PM, Gleb Natapov wrote:
On Wed, Jul 10, 2013 at 04:16:46PM +0200, Bernd Schubert wrote:
Hi all,
I found a way to reliably crash my host system:
1) Boot guest VM with init=/bin/bash
2) In guest VM: echo b /proc/sysrq-trigger
3) Try to reboot the guest - crashes the host
On 07/03/2013 10:47 AM, Stefan Hajnoczi wrote:
On Tue, Jul 02, 2013 at 10:40:11AM -0400, Brian J. Murrell wrote:
I have a cluster of VMs setup with shared virtio-scsi disks. The
purpose of sharing a disk is that if a VM goes down, another can
pick up and mount the (ext4) filesystem on shared
On 08/12/2012 01:45 PM, Michael S. Tsirkin wrote:
On Mon, Jul 30, 2012 at 08:08:31PM +0200, Bernd Schubert wrote:
On 07/30/2012 07:33 PM, Bernd Schubert wrote:
Hello Stefan,
Stefan Hajnoczi stefanha at gmail.com writes:
On Wed, Jan 11, 2012 at 4:18 PM, Bernd Schubert
bernd.schubert
On 07/31/2012 12:23 PM, Stefan Hajnoczi wrote:
On Mon, Jul 30, 2012 at 7:08 PM, Bernd Schubert
I took a quick glance where skb_recv_done is registered at all and traced it
back to vp_find_vqs(). Looking into that function I noticed MSI and so tried
to boot with pci=nomsi. And indeed I
Hello Stefan,
Stefan Hajnoczi stefanha at gmail.com writes:
On Wed, Jan 11, 2012 at 4:18 PM, Bernd Schubert
bernd.schubert at itwm.fraunhofer.de wrote:
On 01/11/2012 05:04 PM, Stefan Hajnoczi wrote:
Try pinging the host's IP address from inside the guest. Run tcpdump
on the guest's tap
On 07/30/2012 07:33 PM, Bernd Schubert wrote:
Hello Stefan,
Stefan Hajnoczi stefanha at gmail.com writes:
On Wed, Jan 11, 2012 at 4:18 PM, Bernd Schubert
bernd.schubert at itwm.fraunhofer.de wrote:
On 01/11/2012 05:04 PM, Stefan Hajnoczi wrote:
Try pinging the host's IP address from inside
No idea what is going on, but recent kernels lock up here after
transferring some amount of data. So far I only know that 2.6.32 is the
last working kernel I have tested and 3.0 is the first non-working
version I tested.
How to reproduce:
vm1: iperf -c vm2
vm2: iperf -s vm1
After some time
On 01/11/2012 04:24 PM, Bernd Schubert wrote:
No idea what is going on, but recent kernels lock up here after
transferring some amount of data. So far I only know that 2.6.32 is the
last working kernel I have tested and 3.0 is the first non-working
version I tested.
Sorry forgot to tell
Hello Stefan,
thanks for your help!
On 01/11/2012 05:04 PM, Stefan Hajnoczi wrote:
On Wed, Jan 11, 2012 at 3:24 PM, Bernd Schubert
bernd.schub...@itwm.fraunhofer.de wrote:
Any idea what is going on or how to debug it?
Here are a couple of ideas that would yield more information:
Since
On Thursday 26 June 2008, Gerd Hoffmann wrote:
You mean with CONFIG_KVM_CLOCK=n it boots fine, I suppose.
You should upgrade the guest kernel to the git tree, kvm clock changes
break compatibility with older kernels.
For completeness: older -rc kernels only, mixing -rc8 with 2.6.25 and
Avi Kivity wrote:
Linus, please pull from the repo and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
kvm-updates-2.6.26
I just pulled from Linus and now it stalls to boot at
[0.616031] pnp: PnP ACPI init
[0.628031] ACPI: bus type pnp registered
[
On Wednesday 25 June 2008, Marcelo Tosatti wrote:
On Wed, Jun 25, 2008 at 06:13:05PM +0200, Bernd Schubert wrote:
Avi Kivity wrote:
Linus, please pull from the repo and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
kvm-updates-2.6.26
I just pulled from
On Wednesday 25 June 2008, Marcelo Tosatti wrote:
On Wed, Jun 25, 2008 at 08:54:44PM +0200, Bernd Schubert wrote:
On Wednesday 25 June 2008, Marcelo Tosatti wrote:
On Wed, Jun 25, 2008 at 06:13:05PM +0200, Bernd Schubert wrote:
Avi Kivity wrote:
Linus, please pull from the repo
On Wednesday 25 June 2008, Marcelo Tosatti wrote:
On Wed, Jun 25, 2008 at 04:17:23PM -0300, Marcelo Tosatti wrote:
Just found out, it is CONFIG_KVM_CLOCK. With CONFIG_KVM_CLOCK=y it does
boot fine.
You mean with CONFIG_KVM_CLOCK=n it boots fine, I suppose.
You should upgrade the
15 matches
Mail list logo
