Again FWIW:
No recurrence of the SCSI abort notices since increasing the timeout,
but still getting guest userspace lockups. Guest kernel logs show RCU
"detected stalls" messages and triggering NMIs across the CPUs. These
consistently indicate CPU 2 sitting in the CFS scheduler via the timer
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 595af1a..f712db5 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -543,6 +543,33 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
> return virtscsi_tmf(vscsi, cmd);
> }
>
> +st
On 02/04/2016 04:03 PM, Paolo Bonzini wrote:
>> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
>> index 595af1a..f712db5 100644
>> --- a/drivers/scsi/virtio_scsi.c
>> +++ b/drivers/scsi/virtio_scsi.c
>> @@ -543,6 +543,33 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
>>
On 02/04/2016 02:41 PM, Jim Minter wrote:
> FWIW, I've now done:
>
> echo 300 >/sys/block/sda/device/timeout
>
> Not entirely sure whether it would help or not, but so far I haven't
> had a recurrence.
>
Can you try with the attached patch?
Should work as well, but you shouldn't need to tweak an
FWIW, I've now done:
echo 300 >/sys/block/sda/device/timeout
Not entirely sure whether it would help or not, but so far I haven't had
a recurrence.
Cheers,
Jim
--
Jim Minter
Principal Solution Architect, Red Hat UK
e: jmin...@redhat.com
m: +44 (0)7906 098697
cal:
https://www.google.com/cal
On 04/02/2016 07:59, Hannes Reinecke wrote:
> On 02/04/2016 12:19 AM, Paolo Bonzini wrote:
>>
>>
>> On 03/02/2016 22:46, Jim Minter wrote:
>>> I am hitting the following VM lockup issue running a VM with latest
>>> RHEL7 kernel on a host also running latest RHEL7 kernel. FWIW I'm using
>>> virti
On 02/04/2016 01:23 PM, Paolo Bonzini wrote:
On 04/02/2016 00:34, Jim Minter wrote:
I was worried there was
some way in which the contention could cause an abort and perhaps thence
the lockup (which does not seem to recover when the host load goes down).
I don't know... It's not the most teste
On 04/02/2016 00:34, Jim Minter wrote:
> I was worried there was
> some way in which the contention could cause an abort and perhaps thence
> the lockup (which does not seem to recover when the host load goes down).
I don't know... It's not the most tested code, but it is not very
complicated ei
On 02/04/2016 12:19 AM, Paolo Bonzini wrote:
>
>
> On 03/02/2016 22:46, Jim Minter wrote:
>> I am hitting the following VM lockup issue running a VM with latest
>> RHEL7 kernel on a host also running latest RHEL7 kernel. FWIW I'm using
>> virtio-scsi because I want to use discard=unmap. I ran t
Hi again, thanks for replying,
On 03/02/16 23:19, Paolo Bonzini wrote:
On 03/02/2016 22:46, Jim Minter wrote:
I am hitting the following VM lockup issue running a VM with latest
RHEL7 kernel on a host also running latest RHEL7 kernel. FWIW I'm using
virtio-scsi because I want to use discard=un
On 03/02/2016 22:46, Jim Minter wrote:
> I am hitting the following VM lockup issue running a VM with latest
> RHEL7 kernel on a host also running latest RHEL7 kernel. FWIW I'm using
> virtio-scsi because I want to use discard=unmap. I ran the VM as follows:
>
> /usr/libexec/qemu-kvm -nodefaul
Hello,
I am hitting the following VM lockup issue running a VM with latest
RHEL7 kernel on a host also running latest RHEL7 kernel. FWIW I'm using
virtio-scsi because I want to use discard=unmap. I ran the VM as follows:
/usr/libexec/qemu-kvm -nodefaults \
-cpu host \
-smp 4 \
-m 8192
12 matches
Mail list logo
