When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount /dev/sdb /mnt
# dd if=/dev/zero
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount
On 07/25/2012 11:44 AM, Paolo Bonzini wrote:
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is
Il 25/07/2012 11:22, Boaz Harrosh ha scritto:
for_each_sg(table-sgl, sg_elem, table-nents, i)
-sg_set_buf(sg[idx++], sg_virt(sg_elem),
sg_elem-length);
+sg_set_page(sg[idx++], sg_page(sg_elem),
sg_elem-length,
+
On Wed, Jul 25, 2012 at 04:00:19PM +0800, Wang Sen wrote:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
#
Hi,
We have done some analysis on this issue. From our analysis we observed that,
this issue is reproducible on kernel 3.1.10 onwards but in 3.0.36 this issue is
not reproducible. So, we have taken the mpt2sas code from 3.1.10 kernel and
compiled and run it on 3.0.36 kernel. Here this issue is
On Wed, Jul 25, 2012 at 10:44:14AM +0200, Paolo Bonzini wrote:
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of
the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
crash.
# sudo mkfs.ext4
2012/7/25 Paolo Bonzini pbonz...@redhat.com:
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is
2012/7/25 Rolf Eike Beer eike-ker...@sf-tec.de:
Am 25.07.2012 10:29, schrieb Wang Sen:
When using the commands below to write some data to a virtio-scsi LUN of
the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu
will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is
2012/7/25 Stefan Hajnoczi stefa...@linux.vnet.ibm.com:
On Wed, Jul 25, 2012 at 10:44:14AM +0200, Paolo Bonzini wrote:
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of
the
QEMU guest(32-bit) with 1G physical memory(qemu -m
On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
On Tue, Jul 24, 2012 at 01:26:20AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
As requested by Anthony, here is a
On 07/17/2012 11:11 AM, James Bottomley wrote:
On Tue, 2012-07-17 at 10:54 +0200, Paolo Bonzini wrote:
Il 17/07/2012 10:40, James Bottomley ha scritto:
It's not specific to virtio-scsi, in fact I expect that virtio-scsi will
be almost always used with non-removable disks.
However, QEMU's
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount /dev/sdb /mnt
# dd if=/dev/zero
On Wed, 2012-07-25 at 20:13 +0800, Wang Sen wrote:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo
On 07/25/2012 12:41 PM, Paolo Bonzini wrote:
Il 25/07/2012 11:22, Boaz Harrosh ha scritto:
for_each_sg(table-sgl, sg_elem, table-nents, i)
-sg_set_buf(sg[idx++], sg_virt(sg_elem),
sg_elem-length);
+sg_set_page(sg[idx++], sg_page(sg_elem),
On 07/25/2012 02:44 PM, Sen Wang wrote:
2012/7/25 Paolo Bonzini pbonz...@redhat.com:
Il 25/07/2012 10:29, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
crash.
On 07/25/2012 03:34 PM, Paolo Bonzini wrote:
Il 25/07/2012 14:13, Wang Sen ha scritto:
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is
Il 25/07/2012 14:34, Boaz Harrosh ha scritto:
for_each_sg(table-sgl, sg_elem, table-nents, i)
- sg_set_buf(sg[idx++], sg_virt(sg_elem),
sg_elem-length);
+ sg_set_page(sg[idx++], sg_page(sg_elem),
sg_elem-length,
+ sg_elem-offset);
On 07/24/2012 11:45 PM, Nicholas A. Bellinger wrote:
diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
index e942df9..3d5378f 100644
--- a/drivers/vhost/tcm_vhost.h
+++ b/drivers/vhost/tcm_vhost.h
@@ -80,7 +80,17 @@ struct tcm_vhost_tport {
#include linux/vhost.h
On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
Except here the destination array has to be given to virtio, which
doesn't (yet) understand chaining. I'm using for_each_sg rather than a
simple memcpy exactly because I want to flatten the input scatterlist
onto consecutive scatterlist entries,
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
Except here the destination array has to be given to virtio, which
doesn't (yet) understand chaining. I'm using for_each_sg rather than a
simple memcpy exactly because I want to flatten the input
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
In SCSI land most LLDs should support chaining just by virtu of using the
for_each_sg macro. That all it takes. Your code above does support it.
Yes, it supports it but still has to undo them before passing to virtio.
What my LLD does is add a
On Sun, 2012-07-22 at 10:31 -0700, Tejun Heo wrote:
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
Now I'm not sure this isn't taping over another bug. Which leads me to
my question: What is the correct behavior?
#1 Issuing a separate spin-up command (START
On 07/25/2012 04:36 PM, Paolo Bonzini wrote:
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
Except here the destination array has to be given to virtio, which
doesn't (yet) understand chaining. I'm using for_each_sg rather than a
simple memcpy
Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
I did test the patch with value-assignment.
Still you should use the sg_set_page()!!
1. It is not allowed to directly manipulate sg entries. One should always
use the proper accessor. Even if open coding does work and is not a bug
Il 25/07/2012 17:09, Paolo Bonzini ha scritto:
Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
I did test the patch with value-assignment.
Still you should use the sg_set_page()!!
1. It is not allowed to directly manipulate sg entries. One should always
use the proper accessor. Even if
Hello
I have a setup with a 12 daisy chained EXP3000 enclosures connected to
a server such that each of the disks are accessible via two paths
through multiple sas expanders. The server has 2 dual ported HBAs. I'm
running 2.6.32 kernel variant based on RHEL 6.0. I have seen this on
2.6.31 as
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working around those is one of major roles of drivers,
so I think
Il 25/07/2012 17:28, Boaz Harrosh ha scritto:
1) what I get is a scsi_cmnd which contains an N-element scatterlist.
2) virtio-scsi has to build the packet that is passed to the hardware
(it does not matter that the hardware is virtual). This packet (per
virtio-scsi spec) has an N+1-element
The following v3.4-rc1 commit unmasked an existing bug in
scsi_io_completion's SG_IO error handling:
47ac56d [SCSI] scsi_error: classify some ILLEGAL_REQUEST sense as a permanent
TARGET_ERROR
Given that certain ILLEGAL_REQUEST are now properly categorized as
TARGET_ERROR the host_byte is being
On 07/10/2012 12:06 AM, Dan Williams wrote:
libsas and ipr pass flags to ata_host_init that are meant for the port.
ata_host flags:
ATA_HOST_SIMPLEX= (1 0), /* Host is simplex, one DMA
channel per host only */
ATA_HOST_STARTED= (1 1), /* Host
On Wed, 2012-07-25 at 10:17 -0700, Tejun Heo wrote:
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working
On 07/09/2012 11:06 PM, Dan Williams wrote:
libsas and ipr pass flags to ata_host_init that are meant for the port.
ata_host flags:
ATA_HOST_SIMPLEX= (1 0), /* Host is simplex, one DMA
channel per host only */
ATA_HOST_STARTED= (1 1), /* Host started
On Tue, 24 July 2012 09:01:41 +0400, James Bottomley wrote:
On Mon, 2012-07-23 at 15:24 -0400, Jörn Engel wrote:
On Mon, 23 July 2012 23:45:55 +0400, James Bottomley wrote:
Have you checked this with the patches in scsi-misc? There's a series
of patches in there that alters the way
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream
Oh, I forgot to point out the merge commit, making my HEAD more recent
than might be
On 07/25/2012 11:06 PM, Paolo Bonzini wrote:
Il 25/07/2012 21:16, Boaz Harrosh ha scritto:
The picture confused me. It looked like the first element is the
virtio_scsi_cmd_req
not an sgilist-element that points to the struct's buffer.
In that case then yes your plan of making a
On Wed, 2012-07-25 at 16:10 +0300, Avi Kivity wrote:
On 07/24/2012 11:45 PM, Nicholas A. Bellinger wrote:
diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
index e942df9..3d5378f 100644
--- a/drivers/vhost/tcm_vhost.h
+++ b/drivers/vhost/tcm_vhost.h
@@ -80,7
On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
On Tue, Jul 24, 2012 at 01:26:20AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream
(text copied from the upstream-linus tag)
Notable changes:
* Updating libata to directly bind with ACPI /
On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik j...@garzik.org wrote:
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream
Oh, I forgot to
On 07/25/2012 06:06 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik j...@garzik.org wrote:
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik jgar...@pobox.com wrote:
Even so, separately, it still needed that post-merge compile fix.
And that's yet another example of how *NOT* to do things.
If the merge has errors like that, then they should be fixed up in the merge.
Please. Don't do
On Wed, Jul 25, 2012 at 02:14:50PM -0700, Nicholas A. Bellinger wrote:
On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
On Tue, Jul 24, 2012 at
Tejun Heo tj at kernel.org writes:
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
Now I'm not sure this isn't taping over another bug. Which leads me to
my question: What is the correct behavior?
#1 Issuing a separate spin-up command (START UNIT?) prior to
On 07/25/2012 06:31 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik jgar...@pobox.com wrote:
Even so, separately, it still needed that post-merge compile fix.
And that's yet another example of how *NOT* to do things.
If the merge has errors like that, then they should
Hello James,
Am 25.07.2012 21:55, schrieb James Bottomley:
It looks like a hack like this might be needed.
James
SNIP
I don't yet understand all the code but I'm following your discussion
with Tejun: I've set up a minimal vm running gentoo with a mpt2sas
driven controller in passthrough
On 07/25/2012 07:30 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik jgar...@pobox.com wrote:
What is the right course in when a post-merge change is needed?
Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole
On Wed, 2012-07-25 at 23:35 +0100, Stefan Hajnoczi wrote:
On Wed, Jul 25, 2012 at 02:14:50PM -0700, Nicholas A. Bellinger wrote:
On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
On Mon, 2012-07-23 at 18:56
On 07/26/2012 05:38 AM, Jeff Garzik wrote:
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM power management).
Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next
for
On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:
On 07/26/2012 05:38 AM, Jeff Garzik wrote:
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM power management).
Touches ACPI
On Wed, 2012-07-25 at 23:08 +, Skirvin, Jeffrey D wrote:
James, is there any update available about the pull of the driver changes that
Dan mentioned? Please let me know if there is anything we need to do to
assist.
Oh, oops. When I had to rebase the branches to accommodate Linus' fix
On 07/26/2012 01:05 PM, James Bottomley wrote:
On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:
On 07/26/2012 05:38 AM, Jeff Garzik wrote:
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM
52 matches
Mail list logo
