qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] kvm segfaulting


From: Paolo Bonzini
Subject: Re: [Qemu-devel] kvm segfaulting
Date: Wed, 13 Feb 2013 14:39:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 13/02/2013 13:55, Stefan Priebe - Profihost AG ha scritto:
> Hi,
> Am 13.02.2013 12:36, schrieb Paolo Bonzini:
>> Il 13/02/2013 10:07, Stefan Priebe - Profihost AG ha scritto:
>>>>>>>
>>>>>>> commit 47a150a4bbb06e45ef439a8222e9f46a7c4cca3f
>>> ...
>>>>> You can certainly try reverting it, but this patch is fixing a real bug.
>>> Will try that. Yes but even if it fixes a bug and raises another one
>>> (kvm segfault) which is the worst one. It should be fixed.
>>
>> The KVM segfault is exposing a potential consistency problem.  What is
>> worse is not obvious.  Also, it is happening at reset time if this is
>> the culprit.  Reset usually happens at places where no data loss is caused.
>>
>> Can you find out what the VM was doing when it segfaulted?  (Or even,
>> can you place the corefile and kvm executable somewhere where I can
>> download it?)
> 
> Yes it was doing an fstrim -v / which resulted in:
> 
> [45648.453698] end_request: I/O error, dev sda, sector 9066952

Ok, very helpful.  One thing is to find why this failed.  This can
come later though.

First of all, please run "cat /sys/block/*/device/scsi_disk/*/provisioning_mode"
in a VM with a similar configuration as the one that crashed last.

Second, I attach another patch.

Third, if possible please compile QEMU with --enable-trace-backend=simple,
and run it with

  -trace events='bdrv_aio_discard
scsi_req_cancel
',file=qemu.$$.trace

This can give some clues.  The files should remain quite small,
so you can enable it on all VMs safely.

> Sadly not as i don't have acore dump. The kvm processes are started
> through variuos Daemons and there seems no way to activate core dumps
> for an already running process and i don't know which VM will crash next.

Probably the next that invokes fstrim. :)

>> If not, do your VMs reset themselves
>> often for example?
> No

Ok, good to know.

>> Can you reproduce it on non-rbd storage?
> I don't have another storage type. ;-(

No problem.

Paolo

Attachment: unmap.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]