On 19.11.2012 18:20, Stefan Hajnoczi wrote:
On Thu, Nov 8, 2012 at 4:26 PM, Peter Lieven wrote:
Has anyone any other idea what the cause could be or where to start?
Hi Peter,
I suggested posting the source tree you are building. Since you have
applied patches yourself no one else is able to
On Thu, Nov 8, 2012 at 4:26 PM, Peter Lieven wrote:
> Has anyone any other idea what the cause could be or where to start?
Hi Peter,
I suggested posting the source tree you are building. Since you have
applied patches yourself no one else is able to follow along with the
gdb output or reproduce
Has anyone any other idea what the cause could be or where to start?
Peter
Am 31.10.2012 um 15:08 schrieb ronnie sahlberg:
> On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi wrote:
>> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
>> wrote:
>>> About half a year there was an issue where re
Am 31.10.2012 um 15:08 schrieb ronnie sahlberg:
> On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi wrote:
>> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
>> wrote:
>>> About half a year there was an issue where recent kernels had added
>>> support to start using new scsi opcodes, but the
On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi wrote:
> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
> wrote:
>> About half a year there was an issue where recent kernels had added
>> support to start using new scsi opcodes, but the qemu functions that
>> determine "which transfer direct
On Tue, Oct 30, 2012 at 8:37 PM, Peter Lieven wrote:
> Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
>> Please also post the exact qemu-kvm version you are using. I can see
>> it's based on qemu-kvm-1.2.0 but are there any patches applied (e.g.
>> distro packages may carry patches so the full pac
On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
wrote:
> About half a year there was an issue where recent kernels had added
> support to start using new scsi opcodes, but the qemu functions that
> determine "which transfer direction is used for this opcode" had not
> yet been updated, so that
But older distros/kernels work fine?
Can you take a network trace?
About half a year there was an issue where recent kernels had added
support to start using new scsi opcodes, but the qemu functions that
determine "which transfer direction is used for this opcode" had not
yet been updated, so th
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven wrote:
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virt
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven wrote:
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virt
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven wrote:
> On 30.10.2012 09:32, Stefan Hajnoczi wrote:
>>
>> On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
>>>
>>> Hi,
>>
>> Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
>> different virtio device type from virtoi-
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
Sounds pedantic but I
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
> Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
Sounds pedantic but I want to make sure this gets chalked up agains
13 matches
Mail list logo
